01-云原生
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 微服务架构风格是一种将一个单一应用程序开发 为一组小型服务的方法， 每个服务运行在自己 的进程中， 服务间通信采用轻量级通信机制 （通常用HTTP 资源API)。这些服务围绕业务能力 构建并且可通过全自动部署机制独立部署。这些 服务共用一个最小型的集中式的管理， 服务可 用不同的语言开发，使用不同的数据存储技术。
-----Martin Fowler
微服务架构
微服务架构的特点
• 每个微服务可独立运行在自己的进程里。 • 一系列独立运行的微服务共同构建起整个系统。 • 每个服务为独立的业务开发，一个微服务只关注
某个特定的功能，例如订单管理、用户管理等。 • 微服务之间通过一些轻量的通信机制进行通信，
例如通过RESTful API 进行调用。 • 可以使用不同的语言与数据存储技术。 • 全自动的部署机制。
• 服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、 实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部 署CPU密集型服务，在EC2内存优实例上部署内存数据库服务。
微服务架构的缺点和挑战
• 微服务强调了服务大小，但实际上这并没有一个 统一的标准。
• 服务的分布式特点带来的复杂性 • 分区的数据库体系和分布式事务 • 对测试也带来了很大的挑战。传统的单体WEB应
• 单体架构（Monolithic） 所有的功能打包在一个 WAR包里，基本没有外 部依赖（除了容器）， 部署在一个J2EE容器 （Tomcat，JBoss， WebLogic）里，包含了 DAO，Service，UI等所有 逻辑。
微服务架构（Micro-Service Archeticture）
云原生概念
云原生定义
• Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
用只需测试单一的REST API即可，而对微服务进 行测试，需要启动它依赖的所有其他服务。这种 复杂性不可低估。 • 跨多个服务的更改
• 以上问题和挑战可 大体概括为：
• API Gateway • 服务间调用 • 服务发现 • 服务容错 • 服务部署 • 数据调用
微服务的设计原则
• 单一职责原则：单一职责原则指的是一个单元（类、方法 或者服务等） 只应关注整个系统功能中单独、有界限的一 部分。
• 动态管理：通过集中式的编排调度系统来动态的 管理和调度。
• 面向微服务：明确服务间的依赖，互相解耦
云原生包含了一组应用的模式，用于帮助企业快 速，持续，可靠，规模化地交付业务软件。云原 生由微服务架构，DevOps 和以容器为代表的敏捷 基础架构组成
云原生所需要的能力和特征
容器化封装
• Docker让开发工程师可以将他们的应用和依赖封 装到一个可移植的容器中。
• 微服务粒度：微服务的粒度是难点，也常常是争论的焦点。 应当使用合理的粒度划分微服务，而不是一昧地把服务做 小。
多样化的云原生应用开发
技术选型
环境构建
• Idea intellij • Github • Maven
• Aliyun repositories
• http://maven.aliyun.com/nexus/#viewrepositories;public~browsestorage
• 这些技术能够构建容错性好、易于管理和便于观察的松耦合 系统。结合可靠的自动化手段，云原生技术可以使开发者轻 松地对系统进行频繁并可预测的重大变更。
CLOUD NATIVE LANDSCAPE
CNCF给出云原生的三大特征
• 容器化封装：以容器为基础，提高整体开发水平， 形成代码和组件重用，简化云原生应用程序的维 护。在容器中运行应用程序和进程，并作为应用 程序部署的独立单元，实现高水平资源隔离。
微服务的优点
• 解决了复杂性问题。将单体应用分解为一组可管理的模块或服务， 服务之间定义了明确的RPC或消息驱动的API边界。提高了开发速度， 简化了维护。
• 服务都可以独立开发。只要符合服务API契约，开发人员可以自由选 择开发技术。更新或重构服务，会对整体应用造成太大影响。
• 微服务架构可以使每个微服务独立部署、升级、运维。更改可以在 测试通过后立即部署。使CI／CD成为可能。
• 云原生技术帮助公司和机构在公有云、私有云和混合云等新 型动态环境中，构建和运行可弹性扩展的应用。云原生的代 表技术包括容器、服务网格、微服务、不可变基础设施和声 明式API。
• These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
• 服务自治原则：服务自治是指每个微服务应具备独立的业 务能力、依赖与运行环境。服务是独立的业务单元，应该 与其他服务高度解耦。每个微服务从开发、测试、构建、 部署，都应当可以独立运行， 不应该依赖其他的服务。
• 轻量级通信机制： 微服务之间应该通过轻量级的通信机制 进行交互。轻量级的通信机制应具备两点： 体量轻；跨语 言、跨平台的。微服务架构中，常用的协议有REST 、 AMQP 、STOMP 、MQTT 等。
ห้องสมุดไป่ตู้
• Aliyun 云服务器或虚拟机 • Maven • Git • Docker
• Docker创建软件程序可移植的轻量容器，让其可 以在任何安装了Docker的机器上运行，而不用关 心底层操作系统。
• Docker优势：
• 隔离应用依赖 • 创建应用镜像并进行复制 • 创建容易分发的即启即用的应用 • 允许实例简单、快速地扩展 • 测试应用并随后销毁它们
微服务架构
• 单体架构
-----Martin Fowler
微服务架构
微服务架构的特点
• 每个微服务可独立运行在自己的进程里。 • 一系列独立运行的微服务共同构建起整个系统。 • 每个服务为独立的业务开发，一个微服务只关注
某个特定的功能，例如订单管理、用户管理等。 • 微服务之间通过一些轻量的通信机制进行通信，
例如通过RESTful API 进行调用。 • 可以使用不同的语言与数据存储技术。 • 全自动的部署机制。
• 服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、 实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部 署CPU密集型服务，在EC2内存优实例上部署内存数据库服务。
微服务架构的缺点和挑战
• 微服务强调了服务大小，但实际上这并没有一个 统一的标准。
• 服务的分布式特点带来的复杂性 • 分区的数据库体系和分布式事务 • 对测试也带来了很大的挑战。传统的单体WEB应
• 单体架构（Monolithic） 所有的功能打包在一个 WAR包里，基本没有外 部依赖（除了容器）， 部署在一个J2EE容器 （Tomcat，JBoss， WebLogic）里，包含了 DAO，Service，UI等所有 逻辑。
微服务架构（Micro-Service Archeticture）
云原生概念
云原生定义
• Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
用只需测试单一的REST API即可，而对微服务进 行测试，需要启动它依赖的所有其他服务。这种 复杂性不可低估。 • 跨多个服务的更改
• 以上问题和挑战可 大体概括为：
• API Gateway • 服务间调用 • 服务发现 • 服务容错 • 服务部署 • 数据调用
微服务的设计原则
• 单一职责原则：单一职责原则指的是一个单元（类、方法 或者服务等） 只应关注整个系统功能中单独、有界限的一 部分。
• 动态管理：通过集中式的编排调度系统来动态的 管理和调度。
• 面向微服务：明确服务间的依赖，互相解耦
云原生包含了一组应用的模式，用于帮助企业快 速，持续，可靠，规模化地交付业务软件。云原 生由微服务架构，DevOps 和以容器为代表的敏捷 基础架构组成
云原生所需要的能力和特征
容器化封装
• Docker让开发工程师可以将他们的应用和依赖封 装到一个可移植的容器中。
• 微服务粒度：微服务的粒度是难点，也常常是争论的焦点。 应当使用合理的粒度划分微服务，而不是一昧地把服务做 小。
多样化的云原生应用开发
技术选型
环境构建
• Idea intellij • Github • Maven
• Aliyun repositories
• http://maven.aliyun.com/nexus/#viewrepositories;public~browsestorage
• 这些技术能够构建容错性好、易于管理和便于观察的松耦合 系统。结合可靠的自动化手段，云原生技术可以使开发者轻 松地对系统进行频繁并可预测的重大变更。
CLOUD NATIVE LANDSCAPE
CNCF给出云原生的三大特征
• 容器化封装：以容器为基础，提高整体开发水平， 形成代码和组件重用，简化云原生应用程序的维 护。在容器中运行应用程序和进程，并作为应用 程序部署的独立单元，实现高水平资源隔离。
微服务的优点
• 解决了复杂性问题。将单体应用分解为一组可管理的模块或服务， 服务之间定义了明确的RPC或消息驱动的API边界。提高了开发速度， 简化了维护。
• 服务都可以独立开发。只要符合服务API契约，开发人员可以自由选 择开发技术。更新或重构服务，会对整体应用造成太大影响。
• 微服务架构可以使每个微服务独立部署、升级、运维。更改可以在 测试通过后立即部署。使CI／CD成为可能。
• 云原生技术帮助公司和机构在公有云、私有云和混合云等新 型动态环境中，构建和运行可弹性扩展的应用。云原生的代 表技术包括容器、服务网格、微服务、不可变基础设施和声 明式API。
• These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
• 服务自治原则：服务自治是指每个微服务应具备独立的业 务能力、依赖与运行环境。服务是独立的业务单元，应该 与其他服务高度解耦。每个微服务从开发、测试、构建、 部署，都应当可以独立运行， 不应该依赖其他的服务。
• 轻量级通信机制： 微服务之间应该通过轻量级的通信机制 进行交互。轻量级的通信机制应具备两点： 体量轻；跨语 言、跨平台的。微服务架构中，常用的协议有REST 、 AMQP 、STOMP 、MQTT 等。
ห้องสมุดไป่ตู้
• Aliyun 云服务器或虚拟机 • Maven • Git • Docker
• Docker创建软件程序可移植的轻量容器，让其可 以在任何安装了Docker的机器上运行，而不用关 心底层操作系统。
• Docker优势：
• 隔离应用依赖 • 创建应用镜像并进行复制 • 创建容易分发的即启即用的应用 • 允许实例简单、快速地扩展 • 测试应用并随后销毁它们
微服务架构
• 单体架构