服务网格基础

一 程序架构

1.1 架构的形式与特点

• 以文档和代码呈现：架构既包含设计过程，也包括设计的产物，可以是各类设计文档、设计图，也可是一些技术验证代码、 Demo或其它相关的程序；文档是设计的载体，而代码是系统功能实现的载体；
• 架构服务于业务：即架构的首要功能是服务于业务功能，因此，架构设计需要一定的前瞻性来容纳业务的变动；
• 架构影响团队的组织形式：业务的拆分方法和技术框架的选择必然会影响研发团队的组织形式，反过来，研发组织的结构和成熟度也会对最终所采取的技术架构产生重要的影响；
• 架构存在于每一个系统：每一个已经实现并运行的系统，必然是特定架构设计的载体；
• 每个架构都有特定的架构风格；
• 架构需要不断地发展演进；

1.2 架构风格

• 典型的企业级应用系统或互联网应用大多都是通过Web提供一组业务服务能力 ，包括以下内容：

• 运行于服务器端，以后端编程语言构建的业务逻辑处理部分；
• 用于存储业务数据的关系数据库或其它类型的存储系统；
• 提供给用户操作的、运行于浏览器或APP中具有UI的业务逻辑展示和输入部分；

• 根据软件系统在运行期的表现风格和部署结构，大体可以将其粗略地划分为两类；

• 单体架构：整个系统的所有功能单元整体部署到同一进程（所有代码可以打包成一个或多个文件）

• 进一步细分：简单单体模式、 MVC模式、前后端分离模式、组件模式和类库模式等；

• 分布式架构：整个系统的功能单元分散到不同的进程，然后由多个进程共同提供不同的业务能力；

• 面向服务的架构（SOA）
• 微服务架构 （MSA）

1.3 面向服务的架构（SOA）

• SOA是建设企业IT生态系统的架构指导思想中的一种，它把服务视作基本的业务功能单元，由平台中立性的接口契约定义； SOA目前的实现方式有两种：分布式服务化和集中式管理；

• 分布式服务化：常见的实现有Dubbo、 Finagle和ICE等；
• 集中式管理：以ESB为基础支撑技术，较流行的商业实现有WMB (IBM)、 OSB (Oracle），开源实现有Mule、 ServiceMix和OpenESB等；

• SOA的两大基石 ；

• RPC：远程过程调用，是一种通用目的系统通信手段，它把被调用者称为服务提供者(Provider)，把调用者称为服务消费者（Consumer），并将对象转换为便于网络传输的二进制或文本数据的过程称为序列化  （Serialization） ；

• 常见的RPC技术有Cobra、 RMI、 WebService、 JSON-RPC、 XML-RPC、 Thrift、 Protocol Buffer和gRPC等；
• 按照调用方式，可分为四种模式： RR（Request-Response）、 Oneway（单向调用）、 Future（异步）和Callback（回调）；

• MQ： N个系统之间互相通信时，利用MQ可以进行系统间解耦，并借助于失败策略、重试等机制完成错误处理；

• 点对点模式
• 发布订阅模式

1.4 传统分布式中间件（ESB）

• 早期的SOA系统的服务间通信多采用“点对点”模型，服务调用和集成逻辑也通常嵌入到了应用程序中实现；

• 适合服务数量较少的系统，简单、高效 ；
• 服务数量增多到一定程度时，连接路径和复杂度急剧增加，为应对这种治理挑战而引入了ESB

• ESB提供服务间的连接、转换和中介功能 ；

• 将企业内部系统和各种服务连接到服务总线上，实现信息系统之间的松耦合架构
• 简化了系统集成，使 IT 系统架构更加灵活，并降低了企业内部信息共享的成本

• ESB的局限性；

• 强调甚至过分强调业务系统的可重用性，结果导致大量的服务集成实现逻辑沉入了ESB，很难维护、迁移和扩展，进而成为ESB的沉重负担；
• 基于集中式消息处理系统，主要挑战是单体架构以及业务逻辑和平台之间紧密的技术耦合，这反而又导致了 技术和组织的中心化；
• 开发并部署服务到这样的系统中时，它和分布性系统框架产生的紧密耦合，限制了服务的进一步演化 ；
• 智能管道和哑端点的ESB系统架构无法适应快速变化和大规模创新

二 分布式应用

2.1 分布式应用需求

• 生命周期

• 编写业务功能时，编程语言会指定生态系统中的可用库、打包格式和运行时（ runtime）等 ；

• 例如， Java使用.jar打包格式，它将依赖到的所有Maven库视为生态系统，并使用JVM作为运行时

• 随着发布周期变得更短，生命周期中更为重要的是以自动化的方式部署的能力、从错误中恢复的能力和扩展服务的能力；

• 这组能力广泛地代表了应用程序生命周期的需求 ；

• 从某种意义上说，如今几乎所有的应用程序都是分布式应用程序，它们都需要网络，但现代分布式系统需要从更广泛的角度去掌控网络；

• 包括服务发现和错误恢复、实现现代软件发布技术和各种跟踪及遥测等

• 为了满足需要，我们甚至会在这个类别中包含不同的消息交换模式、点对点和发布/订阅方式， 以及智能路由机制等；

• 状态

• 此处的状态是指服务的状态 ；

• 一般我们认为，服务最好是无状态的
• 但管理服务的平台本身却是需要状态的（即有状态）

• 平台负责实现可靠的服务编排和工作流、分布式单例、临时调度（即周期式作业cron job）、幂等 性、状态的错误恢复、缓存等，这些功能都依赖于底层的状态

• 绑定

• 分布式系统的组件不仅要相互通信，而且要和现代的或以往的旧式外部系统集成 ；

• 这就要求连接器（connector）能够转换各种协议、支持不同的消息交换模式，如轮询、事件驱动、请求/应答、  转换消息格式，甚至能够执行自定义的错误恢复过程和安全机制

2.2 分布式架构治理模式

2.3 分布式构建原则

• 各服务由规范定义的标准化API提供，这些API通过服务描述的定义将服务消费者的实现与服务提供者的实现进行分离；

• 服务应该按照契约优先规则而不是代码优先规则来开发 ；
• 服务间通信基于面向文档的消息，而非特定语言的RPC协议，从而将服务同其实现语言解耦

• 各服务彼此独立，它们在时间、空间、技术和团队上是松散的耦合关系
• 各服务应该是无状态的，这样就可以灵活调用它们，而无须关心不同上下文中的会话状态
• 各服务应该是自治和自包含的，以便它们可以独立部署、版本控制、自我管理和恢复
• 各服务可以被发现和组合，例如 ：

• 可以通过使用服务注册中心来实现服务发现，从而可以将服务消费者动态绑定到服务提供者
• 来自不同系统的业务服务可以在业务流程中进行编排和组装

三 微服务介绍

3.1 微服务出现

随着互联网的快速大规模增长，企业IT架构的重点从传统的记录系统转变为参与系统，这类的参与 系统必须支持快速迭代和低成本试错，因而“微服务”的概念甫一出现便甚得人心

• 记录系统的代表：企业资源规划ERP和供应链管理SCM等
• 参与系统的代表：在线电商系统、网上银行系统等

3.2 微服务定义

• 最早出现于2011年的“微服务”在2014年由Martin Fowler通过一篇著名的文章发扬光大；该文章可抽象出以下几个关键点：

• 由一些独立的服务共同组成应用系统 ；
• 每个服务单独部署、独立运行在自己的进程中
• 每个服务都是独立的业务
• 分布式管理

• 遵循低耦合、高内聚的原则

3.3 微服务服务管理功能

微服务中的调用链路较之传统的分布式系统长了很多，于链路上发生故障的概率也必然随之增大，且存在性能损耗，于是，系统规划时必须考虑如何进行雪崩预防、功能降级、超时、重试、熔断、服务隔离等服务管理；

3.4 微服务基本原则

• 核心思想是通过应用功能的拆分和解耦来简化业务系统的实现
• 强调将应用功能划分为一组松散耦合的服务，每个服务都遵循单一职责原则
• 每个服务都可以独立部署和交付，极大地提高了业务敏捷性
• 每个服务都可以独立伸缩，以适应互联网的规模

3.5 微服务潜在的问题

• 将一个大的单一应用拆分成多个微服务，使得IT系统的研发协作、交付和维护变得更加复杂
• 幸运的是，容器技术、 DevOps和微服务架构的自然融合，使得微服务落地成为更加简便的实现可能

3.6 SOA到微服务代表产品

• Apache Dubbo
• Spring Cloud

3.7 微服务落地

3.7.1 客户端如何访问这些服务

• 各服务的实现上可能是无状态的，因而需要统一进行用户的登录信息和权限管理（ OAuth）
• 在服务和客户端之间提供一个代理（API GateWay）来统一管控流量

3.7.2 服务彼此如何通信

• 同步调用：REST或RPC
• 异步消息调用：点对点或发布订阅

3.7.3 如何进行服务发现

• 客户端发现
• 服务端发现

3.7.4 如何应对服务故障

• 重试
• 限流
• 熔断
• 负载均衡
• 降低（本地缓存）

3.8 微服务治理框架

3.8.1 库模型

• 为了克服服务通信和治理的复杂性，例如服务发现、融合、限流和端到端跟踪的挑战，需要用到专门的微服务治理框架；

• 微服务框架，如 HSF、 Dubbo 或 Spring Cloud，将这些能力打包成代码库，形成SDK；
• 程序员开发微服务时，将这些代码库内置于应用程序中，并随应用程序一起发布和维护；

• 存在问题： 库模型可能会抽象出满足微服务架构所需要的特 性，但它本身仍然是一个需要维护的组件 ；

• 学习和使用库需要相当程度力量的投入
• 本质上，服务通信和治理是横向连接不同部门的系统，因此与业务逻辑是正交的；但是，在微服务架构中，实现和生命周期是与业务逻辑耦合的，微服务框架的升级会导致整个服务应用的重新构建和重新部署；
• 代码库通常与特定语言绑定，因此难以支持企业应用程序的多语言实现；

3.8.2 sidecar

• Out-of-process architecture
• 合乎逻辑的步骤

• 将库中的功能整合进Network Stack是不可能的，许多从业者找到的解决方案是使用一个小巧的透明代理来实现；
• 使用Sidecar以辅助进程的方式，在应用程序旁边提供高级网络功能；

• sidecar

• 让服务集中解决业务逻辑的问题，网络相关的功能则与业务逻辑剥离，并封装为独立的运行单元并作为服务的反向透明代理，从而不再与业务紧密关联；
• 换句话说，微服务的业务程序独立运行，而网络功能则以独立的代理层工作于客户端与服务之间，专门为代理的服务提供熔断、限流、追踪、指标采集和服务发现等功能；

3.9 service mesh的雏形

将服务治理能力下沉到基础设施中，并将它们部署为服务消费者和服务提供者的独立流程

• 每个服务都使用一个专用的代理Sidecar来完成高级网络功能
• 各服务间仅通过Sidecar代理互相通信
• 各代理之间形成了一个网状网络， 2017年， William为其创建一个专用定义，并称之为Service Mesh

3.10  新一代Service Mesh

为Service Mesh中各独立工作的代理提供集中式的“控制平面”

• 实际的服务流量仍然直接在各代理之间完成，但控制平面知道每个代理实例
• 控制平面使代理能够实现诸如访问控制和指标收集之类的事情

四 微服务基础

4.1 康威定律

• 设计系统的组织由于受到约束，这些设计往往表现为组织内部沟通结构的副本。 ——Melvin Conway(1967)；

• 换句话说，组织设计系统来反映他们自己的沟通结构；

• 目前被引申为四条定律

• 组织设计的产品，等价于组织的沟通结构；
• 罗马并非一天建成的，学会先解决首要问题；

• 时间在充裕，也不可能将一件时间做完美，但总有时间做完一件事情；
• 忽略次要的需求，先完成，在完善；

• 限行系统和线型组织架构间有健在的异质同态特性；

• 创建独立的子系统，减少沟通成本；
• 线性子系统，或分布式子系统对应这不同的产品结构；

• 演进中，较之小系统，大系统具有更强的分解倾向；

• 线性子系统，或分布式子系统对应着不同的产品结构

4.2 服务拆分

4.2.1 横向扩展

横向扩展的目标是在多个相同实例之间实现请求的负载均衡，是扩展单体应用程序的常用方法；

• 提示吞吐量
• 提高可用性

4.2.2 纵向扩展

纵向扩展的目标是根据请求的某属性路由请求，通常也需要运行单体应用程序的多个实例，但每个实例仅负责数据的一个子集；

• 例如，应用程序可能会使用请求标头中包含的userID来路由请求；
• 后端多个程序实例各自仅负责处理指定范围内的用户请求；

4.2.3 微服务化

微服务化的目标是根据功能把应用拆分为多个子应用（服务），这是一种功能性分解机制；

• 每个服务是一个小应用程序，它实现了一组相关的功能；
• 服务也可以在需要的时候借助于X轴或Y轴进行扩展；
• 本质上是分布式系统

4.3 微服务

• 微服务如何体现微的特性

• 体积小：微小的甚至不超过100行代码；
• 开发周期短：必须在两周内完成开发或迭代；

• Netflix的架构师Adrian Cockcroft认为，微服务架构是面向服务的架构，它们由松耦合和具有边界上下文的元素组成；
• 而世界知名的软件大师Chris Richardson在“Microservices Patterns” 一书中通过一种三维可扩展模型“扩展立方体” 给出了不一样的定义：

• 把应用程序功能性分解为一组服务的架构风格，每一个服务都是由一组专注的、内聚的功能职责组成；
• 微服务的大小并不重要，更好的目标是将精心设计的服务定义为能够由小团队开发的服务，并且将会时间最短，与其它团队协作最少；
• 微服务架构应用程序通过一些小的、松耦合的服务组织在一起，从而提升开发效率、可维护性、可测试性和可部署性；

4.4 微服务架构

微服务与单体架构最显著的区别在于，单体应用程序只是单个应用程序，而微服务则是许多小的应用程序协同工作；

4.5 微服务重要组件

 典型微服务体系结构中的组件；

4.5.1 Management

• 负责在节点上放置服务、识别故障、跨节点重新平衡服务等；

4.5.2 Service Discovery

• 维护服务及其所在节点的列表。
• 启用服务查找以查找服务的终结点。

4.5.3 API Gateway

• API Gateway是客户端的入口点；
• 客户端不能直接调用目标服务，而是调用API网关，并由API网关将调用转发到后端相应服务；
• API网关可能聚合来自多个服务的响应并返回聚合响应；

4.5.4 监控体系

4.6 微服务架构的好处

• 使大型的复杂应用程序可以持续交付和持续部署；
• 每个服务都相对较小且容易维护；
• 服务可以独立部署；
• 服务可以独立扩展；
• 微服务架构可以实现团队的自治；
• 更好的容错机制；

4.7 微服务架构的弊端

• 服务的拆分是一项挑战；
• 分布式系统带来的各种复杂性，使开发、测试和部署变得更困难；

• 阔福的事务可能需要saga来维护服务间的数据一致性，同时还要使用API组合或CORS视图实现跨服务查询；
• 依赖高度自动化的基础设施；

• 自动化部署工具，例如Netfix Spinnaker；
• 产品化的Paas平台；
• Docker容器编排平台，例如Kubernetes或Docker Swarm；

• 服务间通信存在不同程度的延迟；
• 当部署跨越多个服务的功能是需要谨慎地协调更多团队；
• 开发者需要思考到底应用在应用的什么阶段使用微服务架构；

4.8 中台战略和微服务

4.9 服务分层

4.10 微服务总体技术架构

4.11 微服务的适用性

4.11.1 何时引入微服务

绿色线条：单体服务

蓝色线条：微服务

x轴：基础复杂度

Y轴：生产力

4.11.2 单体优先

4.12 RPC vs REST

4.13 微服务框架和治理

五 服务网格

网络通信是微服务架构的痛点，服务网格用来解决高级网络功能的；

5.1 分布式计算的8个谬论

• 网络是可靠的
• 网络延迟是0
• 带宽是无限的
• 网络是安全的
• 网络拓扑从不改变
• 只有一个管理员
• 传输成本是0
• 网络是同构的

5.2 微服务体系需要解决的问题

服务网格正是这种需求下逐步演进而形成的新一代解决方案；

• 服务注册和服务发现
• 客户端重试
• 可配置的超时机制
• 负载均衡
• 限速
• 熔断
• 服务间路由
• 异常点检测
• 监控状态检查
• 流量整型
• 流量镜像
• 边缘路由
• A/B测试
• 内部发布
• 故障注入
• 统计和度量
• 日志
• 分布式跟踪

5.3 服务网格介绍

• 概念源于Buoyant公司的CEO Willian Morgan的文章“What's a service mesh? And do I need one?” ；
• 是指专注于处理服务间通信的基础设施，它负责在现代云原生应用组成的复杂拓扑中可靠地传递请求；
• 治理模式：除了处理业务逻辑的相关功能外，每个微服务还必须实现此前单体应用模型中用于网络间通信的基础功能，甚至还包括分布式应用程序之间的通信环境中应该实现的其它网络功能，例如熔断、限流、应用跟踪、指标采集、服务发现和负载均衡等；

• 实现模型经过演进三代：内嵌于应用程序、SDK和Sidcar；

5.4 服务网格的基本功能

• 控制服务间通信： 熔断、重试、超时、故障注入、负载均衡和故障转移等；
• 服务发现：通过专用的服务总线发现服务端点；
• 可观测：指标数据采集、监控、分布式日志记录和分布式追踪；
• 安全性： TLS/SSL通信和密钥管理；
• 身份认证和授权检查：身份认证，以及基于黑白名单或RBAC的访问控制功能；
• 部署：对容器技术的原生支持，例如Docker和Kubernetes等；
• 服务间的通信协议： HTTP 1.1、 HTTP 2.0和gRPC等；
• 健康状态检测：监测上游服务的健康状态

5.5 控制平面（control plane）

• 数据平面与控制平面

• 数据平面：触及系统中的每个数据包或请求，负责服务发现、监控检查、路由、负责均衡、身份验证/授权和可观测性等；
• 控制平面：为网格中的所有正在运行的数据平面提供策略和配置，从而将所有数据平面联合构建为分布式系统，它不接触系统中的任何数据包或请求；

• 负责的任务包括例如确定两个服务Service X到Service Y之间的路由，Service Y相关集群的负载均衡机制、断路策略、流量转移机制等。并将决策下发给Service X和ServiceY的sidecar；

• 控制平面组件

• 工作负载调度程序：借助于底层的基础设施（例如kubernetes）完成服务及其Sidecar运行位置的调度决策；
• 服务发现：服务网格中的服务发现；
• 控制平面UI：管理人员的操作接口，用于配置全局级别的设置，例如部署、身份认证和授权、路由及负载均衡等；
• Sidecar代理配置API：各Sidecar代理以最终一致的方式从各种系统组件获取配置；

5.6 服务网格

• Service Mesh解决方案极大降低了业务逻辑与网络功能之间的耦合度，能够快捷、方便地集成到现有的业务环境中，并提供了多语言、多协议支持，运维和管理成本被大大压缩，且开发人员能够将精力集中于业务逻辑本身，而无须再关注业务代码以外的其它功能；
• 一旦启用Service Mesh，服务间的通信将遵循以下通信逻辑 ：

• 微服务彼此间不会直接进行通信，而是由各服务前端的称为Service Mesh的代理程序进行；
• Service Mesh内置支持服务发现、熔断、负载均衡等网络相关的用于控制服务间通信的各高级功能；
• Service Mesh与编程语言无关，开发人员可以使用任何编程语言编写微服务的业务逻辑，各服务之间也可以使用不同的编程语言开发；
• 服务间的通信的局部故障可由Service Mesh自动处理；
• Service Mesh中的各服务的代理程序由控制平面（Control Plane）集中管理；各代理程序之间的通信网络也称为数据平面（Data Plane）；
• 部署于容器编排平台时，各代理程序会以微服务容器的Sidecar模式运行；

5.7 服务网格和k8s间的关系

• kubernetes

• 解决容器编排与调度的问题；
• 本质上是应用的生命周期管理工具；
• 为服务网格提供基础支撑；

• Service Mesh

• 解决分布式应用间的通信问题；
• 本质上服务通信治理工具；
• 是对k8s在网络功能方面的扩展和延伸；

5.8 Service Mesh技术标准

UDPA：数据平面规范

SMI：控制平面规范

5.9 Service Mesh代表产品

在实现上，数据平面的主流解决方案有Linkerd、 Nginx、 Envoy、 HAProxy和Traefik等，而控制平面的实现主要有Istio、 Nelson和SmartStack等几种：

• Linkerd

• 由Buoyant公司于2016年率先创建的开源高性能网络代理程序（数据平面），是业界第一款Service Mesh产品，引领并促进了相关技术的快速发展；
• Linkerd使用Namerd提供控制平面，实现中心化管理和存储路由规则、服务发现配置、支持运行时动态路由等功能

• Envoy

• 核心功能在于数据平面，于2016年由Lyft公司创建并开源，目标是成为通用的数据平面
• 云原生应用，既可用作前端代理，亦可实现Service Mesh中的服务间通信
• Envoy常被用于实现API Gateway（如Ambassador）以及Kubernetes的Ingress Controller（例如gloo等），不过，基于Envoy实现的Service Mesh产品Istio有着更广泛的用户基础；

• Istio

• 相比前两者来说， Istio发布时间稍晚，它于2017年5月方才面世，但却是目前最火热的Service Mesh解决方案，得到了Google、IBM、 Lyft及Redhat等公司的大力推广及支持；
• 目前仅支持部署在Kubernetes之上，其数据平面由Envoy实现

5.10 服务网络的部署模式

服务网格的部署模式有两种：主机共享代理及Sidecar容器

• 主机共享代理

• 适用于同一主机上存在许多容器的场景，并且还可利用连接池来提高吞吐量
• 但一个代理进程故障将终止其所在主机上的整个容器队列，受影响的不仅仅是单个服务
• 实现方式中，常见的是运行为Kubernetes之上的DaemonSet

• sidecar容器

• 代理进程注入每个pod定义以与主容器一同运行；
• Sidecar进程应该尽可能轻量且功能完善
• 实现方案：Linkerd、envoy和Conduit

5.11 云原生时代的微服务分布式体系

• 生命周期

• 容器和Kubernetes将打包、分发和部署应用程序的方法演化成了同编程语言无关的格式
• 对Kubernetes来说，需要管理的最小原子单元是容器，并且，它专注于在容器级别和流程模型上交付分布式原子单元

• Kubernetes在管理应用程序的生命周期、健康检查、恢复、部署和扩展等方面都做得很出色，但是在运行于容器内的分布式应用的其他方面却没有做得很好，例如灵活的网络，状态管理和绑定

• 尽管Kubernetes 拥有有状态的工作负载、服务发现、 cron作业及其他功能，但是所有这些原语都是在容器级别的，并且在容器内部，开发人员仍然必须使用特定于语言的库实现更高级的功能

• 这其实就是推动诸如Envoy、 Linkerd、 Consul、 Knative、 Dapr和Camel-K等项目的原因

• 网络

• Kubernetes提供的围绕服务发现的基本网络功能打下了良好的基础，但这对于现代应用程序来说却仍嫌不足

• 随着微服务数量的增加和部署的加快，在不改动服务的情况下，对更高级的发布策略，管理安全性，指标，跟踪，从错误中恢复，模拟错误等等方面的需求变得越来越具有吸引力，并产生了一种新的软件类别，称为服务网格

• 服务网格将网络相关的关注点从包含业务逻辑的服务转移出来，放到一个单独的运行时中，该运行时可能是Sidecar，也可能是节点级代理
• 服务网格可以执行高级路由、协助完成测试、处理某些方面的安全性问题，甚至可以支持特定于应用的协议（例如， Envoy支持Kafka、 MongoDB、 Redis和MySQL等）
• 除了典型的服务网格外，还有其它项目，例如[Skupper](https://skupper.io/)等，它们证实了将网络能力放入外部运行时代理的趋势

• Skupper通过第7层虚拟网络解决了多集群通信的难题，并提供了高级路由及连接能力
• 但是，它没有将Skupper嵌入到业务服务运行时中，而是在每个Kubernetes名称空间中运行一个共享的Sidecar实例

• 状态

• 状态的管理比较困难，因而应该将其委派给专门的存储软件和托管服务

• 缓存、工作流管理、单例、幂等、事务管理、 cron作业触发器和状态化错误处理等都隶属状态管理范畴

• 对那些建立在云环境上的服务来讲，状态化工作流的管理是必备功能，例如AWS的Step函数、Azure的Durable函数等
• 在容器化的部署中， CloudState和Dapr都依赖Sidecar模型以提供分布式应用程序中状态化抽象更好的解耦
• 未来的发展趋势中，状态管理应该会通过一个专门的Sidecar应用来完成

• 绑定

• 微服务体系下，从应用程序中解耦分布式需求同样也会伴随着“绑定”

• 尽管，连接器、协议转换、消息转换、错误处理和安全相关的中间层都可以从应用中转移出来，但目前尚未实现，但Knative和Dapr等项目正朝着这个方向努力

• Apache Camel-K项目采用了另一种有趣的方法

• 它借助于一个智能的Kubernetes Operator利用来自Kubernetes和Knative附加的平台能力来构建应用程序运行时，而非在主应用程序周边运行一个Sidecar形式的代理
• Operator成了惟一的代理程序，它负责提供应用所需的各种分布式系统原语
• 不同之处在于，有些分布式原语添加到了应用程序运行时中，而有些则是在平台中实现（也可能包括Sidecar）

5.12 未来的架构趋势

• 除了生命周期之外，现在我们已然可以直接使用网络监测、状态抽象、声明性事件以及端点

  绑定等功能，而EIP（企业集成模式）则是该列表中的下一个元素

• 如果我们把不同领域进行创新的各种云原生项目进行叠加，那么最终将得到类似下图的组合

  形式

• 需要注意的是，上图只是用于说明，它有目的地选择了具有代表性的项目，并把它们映射为分布式原语的一种
• 实际上，我们不会同时使用所有这些项目，因为它们中的一些是重叠的，并且工作负载模型也并

六 云原生

6.1 计算机的发展历程

6.2 发展历程

• 2004年开始，Google已在内部大规模地使用容器技术。
• 2008年，Google讲Cgroups合并进入Linux内核。
• 2013年，Docker项目正式发布
• 2014年，Kubernetes项目正式发布。
• 2015年，由Google、Redhat以及微软等大型云计算厂商以及一些开源公司共同成立了CNCF(Cloud Native Computing Foundation)云原生计算基金会。
• 2017年，CNCF达到170个成员和14个基金项目。
• 2018年，CNCF成立三周年有了195个成员，19个基金会项目和11个孵化项目。

6.3 云原生定义

• 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
• 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
• 云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

6.4 云原生技术栈

• 容器：以Docker为代表的容器运行技术。
• 服务网格：比如Service Mesh等。
• 微服务：在微服务体系结构中，一个项目是由多个松耦合且可独立部署的较小组件或服务组成。
• 不可变基础设施：不可变基础设施可以理解为一个应用运行所需要的基本运行需求，不可变最基本的及时指运行服务器在完成部署后，就不在进行更改，比如镜像等。
• 声明式API：描述应用程序的运行状态，并且由系统来决定如何来创建这个环境，例如声明一个pod，会有k8s执行创建并维持副本。

6.5 云原生特征

• 符合12因素应用，12要素应用程序是一种构建应用程序的方法。

1. 基准代码：一份基准代码，多份部署(用同一个代码库进行版本控制，并可进行多次部署)。
2. 依赖：显示地声明和隔离相互之间的依赖。
3. 配置：在环境中存储配置。
4. 后端服务：把后端服务当作一种附加资源。
5. 构建，发布，运行：对程序执行构建或打包，并严格分离构建和运行。
6. 进程：以一个或多个无状态进程运行应用。
7. 端口绑定：通过端口绑定提供服务。
8. 并发：通过进程模型进行扩展。
9. 易处理：快速地启动，优雅的终止，做大程度上把持健壮性。
10. 开发环境于线上环境等价：尽可能的保持开发，预发布，线上环境相同。
11. 日志：将所有运行中进程和后端服务的输出流程按照时间顺序统一收集存储和展示。
12. 管理进程：一次性管理进程(数据备份)应该和正常的常驻进程使用同样的运行环境。

• 面向微服务架构。
• 自服务敏捷架构。
• 基于API的协作。
• 抗脆弱性。

6.6 云原生架构参考示例

6.7 华为云云原生架构参考示例

6.8 华为云云原生基础设施解决方案整体架构

6.9 华为一站式devops开发流水线

6.10 企业IT建设的三阶段两转变

• 服务器阶段

• 以硬件设备为中心，业务应用随不同厂商设备、操作系统、虚拟化软件的差异进行定制
• 设备的安装、调试，应用的部署、运维基本靠人力完成，自动化程度低，缺乏统一的设备和应用管理能力

• 云化阶段

• 各类资源如计算、存储、网络由虚拟化软件统一进行池化管控，实现了资源管理自动化，做到了以资源为中心部署应用
• 屏蔽了基础设施的一部分差异，为上层业务软件提供了统一的资源管理接口，应用的通用性得到增强
• 虚拟化软件平台差异较大，容易被厂商锁定

• 云原生阶段

• 完全屏蔽底层基础设施（包括云厂商）的差异，应用部署无须再关注底层基础环境
• 企业关注点转变为“以应用为中心”，包括应用敏捷交付、快速弹性、平滑迁移、无损容灾等
• 业务通用能力也将下沉为基础设施的一部分

6.11 云原生建设发展阶段

6.12 云原生景观图

• ​​https://landscape.cncf.io/​​