服务网格基础-知识篇_网格化服务基础知识点

技术采用生命周期

技术炒作周期

一、微服务的出现及治理方式演进

1、程序架构概述

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

2、架构风格

架构风格分类：
◼ 单体架构：整个系统的所有功能单元整体部署到同一进程（所有代码可以打包成一个或多个文件）
◆ 进一步细分：简单单体模式、MVC模式、前后端分离模式、组件模式和类库模式等；
◼ 分布式架构：整个系统的功能单元分散到不同的进程，然后由多个进程共同提供不同的业务能力；
◆ 面向服务的架构（SOA）
◆ 微服务架构（MSA）

3、分布式应用的需求

Bilgin Ibryam将其分为生命周期、网络、状态和绑定四个方面
lifecycle:自动化方式部署、恢复、扩展能力
·Packaging
·Healthcheck
·Deployment
·Scaling缩放
·Configuration
networking：
·Service discovery
·A/B testing,canary rollouts金丝雀发布
·Retry,timeout,circuit breaker
·Point-to-point,pub/sub发布/订阅
·Security,observability可观测性
state:一般我们认为，服务最好是无状态的；但管理服务的平台本身却是需要有状态的
·Workflow mgmt工作流
·Idempotency幂等性
·Temporal scheduling临时调度/周期性作业
·Caching
·Application state
binding：
·Connectors
·Protocol conversion协议转换
·Message transformation
·Message routing
·Transactionality交易

4、一图了解分布式架构治理模式演进

SOA(面向服务)/ESB(企业服务总线)–>MSA(microservices)–>云原生(cloud native)

5、SOA提出的分布式系统的构建原则

各服务由规范定义的标准化API提供，这些API通过服务描述的定义将服务消费者的实现与服务提供者的实现进行分离
◼ 服务应该按照契约优先规则而不是代码优先规则来开发
◼ 服务间通信基于面向文档的消息，而非特定语言的RPC协议，从而将服务同其实现语言解耦
各服务彼此独立，它们在时间、空间、技术和团队上是松散的耦合关系
各服务应该是无状态的，这样就可以灵活调用它们，而无须关心不同上下文中的会话状态
各服务应该是自治和自包含的，以便它们可以独立部署、版本控制、自我管理和恢复
各服务可以被发现和组合，例如
◼ 可以通过使用服务注册中心来实现服务发现，从而可以将服务消费者动态绑定到服务提供者
◼ 来自不同系统的业务服务可以在业务流程中进行编排和组装

6、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可以进行系统间解耦，并借助于失败策略、重试等机制完成错误处理；
◆ 点对点模式
◆ 发布订阅模式

7、传统分布式中间件ESB

早期的SOA系统的服务间通信多采用“点对点”模型，服务调用和集成逻辑也通常嵌入到了应用程序中实现
◼ 适合服务数量较少的系统，简单、高效
◼ 服务数量增多到一定程度时，连接路径和复杂度急剧增加，为应对这种治理挑战而引入了ESB
ESB提供服务间的连接、转换和中介功能
◼ 将企业内部系统和各种服务连接到服务总线上，实现信息系统之间的松耦合架构
◼ 简化了系统集成，使 IT 系统架构更加灵活，并降低了企业内部信息共享的成本

8、ESB的局限性

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

9、分布式微服务架构MSA

随着互联网的快速大规模增长，企业IT架构的重点从传统的记录系统转变为参与系统，这类的参与系统必须支持快速迭代和低成本试错，
因而“微服务”的概念甫一出现便甚得人心
◼ 记录系统的代表：企业资源规划ERP和供应链管理SCM等
◼ 参与系统的代表：在线电商系统、网上银行系统等
微服务的规范定义
◼ 最早出现于2011年的“微服务”，2014年由Martin Fowler一篇文章发扬光大，包含以下几个关键点
◆ 由一些独立的服务共同组成应用系统
◆ 每个服务单独部署、独立运行在自己的进程中
◆ 每个服务都是独立的业务
◆ 分布式管理
◼ 遵循低耦合、高内聚的原则
微服务中的调用链路较之传统的分布式系统长了很多，于链路上发生故障的概率也必然随之增大，且存在性能损耗，
于是，系统规划时必须考虑如何进行雪崩预防、功能降级、超时、重试、熔断、服务隔离等服务管理；

10、分布式微服务架构MSA（2）

微服务强调的基本原则
◼ 核心思想是通过应用功能的拆分和解耦来简化业务系统的实现
◼ 强调将应用功能划分为一组松散耦合的服务，每个服务都遵循单一职责原则
◼ 每个服务都可以独立部署和交付，极大地提高了业务敏捷性
◼ 每个服务都可以独立伸缩，以适应互联网的规模
潜在的问题
◼ 将一个大的单一应用拆分成多个微服务，使得IT系统的研发协作、交付和维护变得更加复杂
◼ 幸运的是，容器技术、DevOps和微服务架构的自然融合，使得微服务落地成为更加简便的实现可能
SOA向MSA进化的代表产品
◼ Apache Dubbo
◼ Spring Cloud

11、微服务实践细节

微服务落地过程中，必须要仔细解决如下问题：
◼ 客户端如何访问这些服务？
◆ 各服务的实现上可能是无状态的，因而需要统一进行用户的登录信息和权限管理（OAuth） ◆ 在服务和客户端之间提供一个代理（API GateWay）来统一管控流量
◼ 服务彼此间如何通信？
◆ 同步调用：REST或RPC
◆ 异步消息调用
◼ 如何进行服务发现？
◆ 客户端发现
◆ 服务端发现
◼ 如何应对服务故障？
◆ 重试
◆ 限流
◆ 熔断
◆ 负载均衡
◆ 降级（本地缓存）

12、微服务治理框架

为了克服服务通信和治理的复杂性，例如服务发现、融合、节流和端到端跟踪的挑战，需要用到专门的微服务治理框架
◼ 微服务框架，如 HSF、Dubbo 或 Spring Cloud，将这些能力打包成代码库，形成SDK
◼ 程序员开发微服务时，将这些代码库内置于应用程序中，并随应用程序一起发布和维护
存在问题：库模型可能会抽象出满足微服务架构所需要的特性，但它本身仍然是一个需要维护的组件
◼ 学习和使用库需要相当程度力量的投入
◼ 本质上，服务通信和治理是横向连接不同部门的系统，因此与业务逻辑是正交的；但是，在微服务架构中，实现和生命周期是与业务逻辑耦合的，微服务框架的升级会导致整个服务应用的重新构建和重新部署
◼ 代码库通常与特定语言绑定，因此难以支持企业应用程序的多语言实现

13、Sidecar

下一个合乎逻辑的步骤
◼ 将库中的功能整合进Network Stack是不可能的，许多从业者找到的解决方案是使用一个小巧的透明代理来实现
◼ 使用Sidecar以辅助进程的方式，在应用程序旁边提供高级网络功能
Sidecar
◼ 让服务集中解决业务逻辑的问题，网络相关的功能则与业务逻辑剥离，并封装为独立的运行单元并作为服务的反向透明代理，从而不再与业务紧密关联
◼ 换句话说，微服务的业务程序独立运行，而网络功能则以独立的代理层工作于客户端与服务之间，专门为代理的服务提供熔断、限流、追踪、指标采集和服务发现等功能

14、为什么要使用Sidecar机制？

Out-of-process architecture进程外托管架构

15、Service Mesh 的雏形

将服务治理能力下沉到基础设施中，并将它们部署为服务消费者和服务提供者的独立流程
◼ 每个服务都使用一个专用的代理Sidecar来完成高级网络功能
◼ 各服务间仅通过Sidecar代理互相通信
◼ 各代理之间形成了一个网状网络，2017年，William为其创建一个专用定义，并称之为Service Mesh

服务网格是用于处理服务到服务通信的专用基础设施层。
它负责通过复杂的服务拓扑可靠地交付请求，这些服务拓扑包含一个现代的云本地应用程序。
在实践中，服务网格通常被实现为与应用程序代码一起部署的轻量级网络代理数组，应用程序不需要知道这些代理。

16、新一代Service Mesh

为Service Mesh中各独立工作的代理提供集中式的“控制平面”
◼ 实际的服务流量仍然直接在各代理之间完成，但控制平面知道每个代理实例
◼ 控制平面使代理能够实现诸如访问控制和指标收集之类的事情

二、微服务基础

1、康威定律

设计系统的组织由于受到约束，这些设计往往表现为组织内部沟通结构的副本。 ——Melvin Conway(1967)
◼ 换句话说，组织设计系统来反映他们自己的沟通结构；
目前被引申为四条定律：
◼ 组织设计的产品，等价于组织的沟通结构；
◼ 罗马并非一天建成的，学会先解决首要问题；
◆ 时间再充裕，也不可能将一件事情做完美，但总有时间做完一件事情；
◆ 忽略次要的需求，“先完成，再完善”；
◼ 线型系统和线型组织架构间有潜在的异质同态特性；
◆ 创立独立的子系统，减少沟通成本；
◆ “线性子系统”，或“分布式子系统”对应着不同的产品结构
◼ 演进中，较之小系统，大系统具有更强的分解倾向；
“线性子系统”，或“分布式子系统”对应着不同的产品结构
“线性子系统”：划分为前端团队、后端开发团队和DBA团队的组织
“分布式子系统”：而基于业务边界划分为多个小团队的组织，各团队按照业务目标去构建小的系统或产品

2、Scale cube and microservices（扩展立方体）

Scale cube定义了三种不同的方法来缩放应用:
◼X-axis scaling负载平衡请求跨多个相同的实例;
◼Z-axis scaling基于请求的一个属性路由请求;
◼Y-axis scaling从功能上将应用程序分解为服务。

3、X-axis Scaling

X轴扩展的目标是在多个相同实例之间实现请求的负载均衡，是扩展单体应用程序的常用方法
◼ 提升吞吐量
◼ 提高可用性

4、Z-axis Scaling

Z轴扩展的目标是根据请求的某属性路由请求，通常也需要运行单体应用程序的多个实例，但每个实例仅负责数据的一个子集；
◼ 例如，应用程序可能会使用请求标头中包含的userID来路由请求；
◼ 后端多个程序实例各自仅负责处理指定范围内的用户请求；

5、Y-axis Scaling: 微服务化

Y轴扩展的目标是根据功能把应用拆分为多个子应用（服务），这是一种功能性分解机制；
◼ 每个服务是一个小应用程序，它实现了一组相关的功能；
◼ 服务也可以在需要的时候借助于X轴或Y轴进行扩展；
◼ 本质上是分布式系统

6、MSA架构

微服务如何体现“微”的特性？
◼ 体积小：微小的甚至不超过100行代码
◼ 开发周期短：必须在两周内完成开发或迭代
◼ 等
Netflix的架构师Adrian Cockcroft认为，微服务架构是面向服务的架构，它们由松耦合和具有边界上下文的元素组成；
而世界知名的软件大师Chris Richardson在“Microservices Patterns”一书中通过一种三维可扩展模型“扩展立方体”给出了不一样的定义
◼ 把应用程序功能性分解为一组服务的架构风格，每一个服务都是由一组专注的、内聚的功能职责组成；
◼ 微服务的大小并不重要，更好的目标是将精心设计的服务定义为能够由小团队开发的服务，并且将会时间最短，与其它团队协作最少；
◼ 微服务架构应用程序通过一些小的、松耦合的服务组织在一起，从而提升开发效率、可维护性、可测试性和可部署性；

7、Microservices Logical（微服务逻辑）

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

8、其它的重要组件

典型微服务体系结构中的其他组件
◼ Management
◆ 负责在节点上放置服务、识别故障、跨节点重新平衡服务等；
◼ Service Discovery
◆ 维护服务列表以及服务所在的节点。
◆ 启用服务查找以查找服务的端点。
◼ API Gateway
◆ API网关是客户端的入口点。
◆ 客户端不能直接调用目标服务，而是调用API网关，并由API网关将调用转发到后端相应服务；
◆ API网关可能聚合来自多个服务的响应并返回聚合响应；

9、微服务架构的好处

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

10、微服务架构的弊端

◼ 服务的拆分是一项挑战；
◼ 分布式系统带来的各种复杂性，使开发、测试和部署变得更困难；
◆ 跨服务的事务可能需要Saga来维护服务间的数据一致性，同时还要使用API组合或CORS视图实现跨服务查询
◆ 依赖高度自动化的基础设施
⚫ 自动化部署工具，例如Netflix Spinnaker
⚫ 产品化的PaaS平台
⚫ Docker容器编排平台，例如Kubernetes或Docker Swarm
◼ 服务间通信存在不同程度的延迟
◼ 当部署跨越多个服务的功能时需要谨慎地协调更多团队
◼ 开发者需要思考到底应该在应用的什么阶段使用微服务构架

11、微服务面临的架构挑战

01运维成本增高
服务越小，独立性更好，但是相应的服务数量越多。每个服务都需要独立配置、部署、监控、日志搜集等，成本呈指数增长。
02异步性
微服务经常使用异步编程、消息队列及并行处理，如果要求一个操作必须是同步且具有事务性，就需要管理好相关联服务及分布式事务操作的复杂性
03分布式系统复杂性
作为一种分布式系统、微服务引入了复杂性、入网络延迟、容错性、消息序列化等一系列问题
04必要DevOps能力
基于微服务架构的应用，与其运行环境紧密关联，需要开发团队及运维团队无缝协作才能保障此类应用的成功开发和运行
05测试困难
无论手工还是自动测试、通常都很难一致性的方式重现微服务应用环境
06依赖管理复杂
当把传统的系统拆分成多个相互协作的独立服务后，随着服务数量的增多，如何清洗明了的展示服务间的依赖关系逐渐成为挑战

12、微服务的适用性

何时引入微服务？
对于不太复杂的系统，管理微服务所需的额外负担降低了生产力
随着复杂性的出现，生产力开始快速下降
微服务松耦合降低了生产力的衰减
但请记住，团队的技能将超过任何单一服务/微服务的选择

13、单体优先

直接使用微服务体系结构是有风险的
庞然大物允许您探索系统的复杂性及其组件边界
随着复杂性的增加，开始出现一些微服务
随着您对边界和服务管理知识的增加，继续分解服务

14、中台战略和微服务

业务前台（应用）
业务中台（核心业务层）
技术中台（PaaS云平台/IaaS云平台）

15、服务分层

外部设备
微服务或SOA（聚合服务、基础服务）

16、微服务总体技术架构

接入层：外部+内部LB
网关层：内部GW、H5 GW、无线GW、第三方GW、开放平台GW
业务服务层：聚合服务、 基础服务
支撑服务：注册发现、集中配置、容错限流、认证授权、日志聚合、监控告警、后台服务(DB\MQ\cache\job)
平台服务：发布系统、集群资源调度、镜像治理、IAM
基础设施层：计算、网络、存储、NOC监控、安全、IDC

17、微服务网关

user interface
load balance
API Gateway：反向路由、认证安全、限流熔断、日志监控
Micro-services：endpoint

18、服务发现和路由体系

服务注册：
服务发现：
接入层、网关层、聚合服务层、基础服务层

19、RPC vs REST

20、服务框架和治理

业务逻辑<–>
配置集成、后台服务集成、服务注册发现、软负载、日志、metrics、调用链埋点、限流熔断、安全&访问控制、REST/RPC、序列化XML/json/二进制、底层通讯TCP/HTTP、统一异常处理、文档

21、监控体系和监控分类

监控体系：
端用户体验监控（性能，返回码、城市、地区、运营商、版本、系统等）
业务监控（核心指标监控，登录注册，下单，支付等）
应用层监控（url，service，sql，cache可用率，响应时间，qps等）
系统层监控（物理机，虚拟机，OS）（cpu，memory，network，disk等）
基础设施监控（网络，交换机）（网络流量，丢包，错包，连接数等）
监控分类：
日志监控、Metrics监控、调用链监控、告警系统、健康检查

22、基于环境治理和多环境的持续交付流水线

git–>jenkins（构建、单元测试、打镜像）–>镜像治理中心（docker）

三、服务网格

1、微服务架构面临什么样的问题？

服务间通信管理将面临巨大挑战

2、网络通信是微服务架构的痛点

分布式计算的8个谬论（Fallacies of Distributed Computing Explained）
◼ 网络是可靠的
◼ 网络延迟是0
◼ 带宽是无限的
◼ 网络是安全的
◼ 网络拓扑从不改变
◼ 只有一个管理员
◼ 传输成本是0
◼ 网络是同构的

3、微服务体系下服务治理面临的挑战

事实上，分布式环境中，网络的不可靠性无法忽略，可靠地解决如下问题，方能确保结果落地
◼ 服务注册和服务发现
◼ 客户端重试
◼ 可配置的超时机制
◼ 负载均衡
◼ 限速
◼ 熔断
◼ 服务间路由
◼ 异常点检测
◼ 健康状态检查
◼ 流量整型
◼ 流量镜像
◼ 边缘路由
◼ 按需路由
◼ A/B测试
◼ 内部发布
◼ 故障注入
◼ 统计和度量
◼ 日志
◼ 分布式跟踪
服务网格，也正是这种需求下逐步演进而形成的新一代解决方案~

4、服务网格（Service Mesh）

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

5、非侵入式“服务治理”

第一代：服务治理能力内嵌在业务代码中
典型技术：SOA、ESB
优势
• 简单使用依赖少
劣势
• 代码耦合
• 代码重复高
• 运维复杂
• 解耦差，开发要求高

第二代：服务治理能力抽象到统一SDK实现
典型技术：Spring Cloud、Dubbo
优势
• 代码重复少
• 治理逻辑代码和业务代码分开
劣势
• SDK语言绑定、代码侵入
• 基于SDK开发学习门槛高
• 在用系统改造代价大
• 治理能力升级影响用户业务

第三代：服务治理能力归一到服务网格
优势
• 独立进程，用户业务非侵入、语言无关
• 治理逻辑升级业务无感知
• 可以渐进的微服务化
劣势
• 代理的性能和资源开销

服务治理与业务逻辑解耦，服务治理能力下沉到基础设施层
服务网格以基础设施的方式提供无侵入的连接控制、安全、可监测性、灰度发布等治理能力

6、服务网格的基本功能

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

7、控制平面（Control Plane）

数据平面与控制平面
◼ 数据平面：触及系统中的每个数据包或请求，负责服务发现、健康检查、路由、负载均衡、身份验证/授权和可观测性等；
◼ 控制平面：为网格中的所有正在运行的数据平面提供策略和配置，从而将所有数据平面联合构建为分布式系统，它不接触系统中的任何数据包或请求；
◆ 负责的任务包括例如确定两个服务Service X到Sevice Y之间的路由，Service Y相关集群的负载均衡机制、断路策略、流量转移机制等，并将决策下发给Service X和Service Y的Sidecar； 

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

8、服务网格

Service Mesh解决方案极大降低了业务逻辑与网络功能之间的耦合度，能够快捷、方便地集成到现有的业务环境中，并提供了多语言、多协议支持，运维和管理成本被大大压缩，且开发人员能够将精力集中于业务逻辑本身，而无须再关注业务代码以外的其它功能
一旦启用Service Mesh，服务间的通信将遵循以下通信逻辑：
◼ 微服务彼此间不会直接进行通信，而是由各服务前端的称为Service Mesh的代理程序进行；
◼ Service Mesh内置支持服务发现、熔断、负载均衡等网络相关的用于控制服务间通信的各种高级功能；
◼ Service Mesh与编程语言无关，开发人员可以使用任何编程语言编写微服务的业务逻辑，各服务之间也可以使用不同的编程语言开发；
◼ 服务间的通信的局部故障可由Service Mesh自动处理；
◼ Service Mesh中的各服务的代理程序由控制平面（Control Plane）集中管理；各代理程序之间的通信网络也称为数据平面（Data Plane）；
◼ 部署于容器编排平台时，各代理程序会以微服务容器的Sidecar模式运行；

9、典型企业应用云原生架构升级实践：容器+服务网格快速实现灰度发布与治理

原SDK 开发的微服务剥离多余治理能力，保留gRPC、REST应用框架，基于网格进行服务治理。

痛点1：灰度发布
➢ 只能通过LB上对入口服务进行灰度发布，不方便对内部单个微服务进行灰度发布。
➢当基于SDK做微服务的灰度发布，为了支持某些规则，SDK和业务代码需要进行大量修改。
痛点2：SDK等治理能力升级
➢ SDK版本升级时，需要所有微服务版本跟着升级，即使服务业务代码未涉及修改。
➢ 业务团队经常要陪着框架团队一起升级验证
痛点3：多语言
➢ 服务中除了大量Java开发的微服务外，还包含大量C、C++和老的单体应用需要服务治理，无法使用SDK完成
痛点4：部署、运维需要额外开发
➢新增服务或更新环境信息时需要大量配置
➢ 需要自研不停机部署，需要对每个服务独立配置及频繁变更
➢ 发布件版本管理不便
➢ 扩缩容不便

收益1：
➢ 可以对入口和内部单个和多个微服务进行灰度发布➢灰度发布不涉及业务代码修改
➢ 提供灵活的权重或者内容的流量规则
➢ 可以和流水线配合，完成新版本的灰度发布
收益2：
➢ 治理能力升级只需基础设施升级即可，业务的镜像等发布件不受影响
➢ 在容器+网格集群上一键可以升级网格管理面和数据面
收益3：
➢ 服务网格与业务代码解耦，支持多种语言的治理
➢ 对老系统访问也可以进行治理，无需老系统改造，老系统可以分步骤改造。
收益4：
➢ Kubernetes容器服务提供敏捷的部署运维能力
➢ Kubernetes 滚动升级保证业务不断服
➢ 基于容器镜像的软件分发（包含应用和环境依赖）
➢ 细粒度资源编排调度
➢ 极致弹性

10、服务网格和K8S间的关系

Kubernetes
◼ 解决容器编排与调度的问题
◼ 本质上是应用的生命周期管理工具
◼ 为服务网格提供基础支撑
Service Mesh
◼ 解决分布式应用间的通信问题
◼ 本质上服务通信治理工具
◼ 是对K8S在网络功能方面的扩展和延伸

11、Service Mesh 技术标准

UDPA(Universal Data Plane APl)
SMI(Service Mesh Interface)

12、Service Mesh 产品发展史

2016年
 Linkerd
 9月，Envoy 1.0发布
2017年
 Linkerd加入CNCF
 4月，Linkerd1.0发布
 5月，Istio 0.1发布
 9月，Envoy加入CNCF
 12月，Conduit发布
2018年
 7月，Istio 1.0发布
 Envoy稳定发布
 Conduit并入Linkerd 2.0
 国内大厂研发
2019年
 3月，Istio 1.1发布
 4月，AWS App Mesh GA
 5月，Google Traffic Director
beta发布
 9月，Kong发布Kuma
 蚂蚁金服Mosn支持双11
2020年
 3月，Istio 1.5发布

13、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实现

14、服务网格的部署模式

服务网格的部署模式有两种：主机共享代理及Sidecar容器
◼ 主机共享代理
◆ 适用于同一主机上存在许多容器的场景，并且还可利用连接池来提高吞吐量
◆ 但一个代理进程故障将终止其所在主机上的整个容器队列，受影响的不仅仅是单个服务
◆ 实现方式中，常见的是运行为Kubernetes之上的DaemonSet
◼ sidecar容器
◆ 代理进程注入每个Pod定义以与主容器一同运行
◆ Sidecar进程应该尽可能轻量且功能完善
◆ 实现方案：Linkerd、Envoy和Conduit

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

生命周期
◼容器和Kubernetes将打包、分发和部署应用程序的方法演化成了同编程语言无关的格式
◼对Kubernetes来说，需要管理的最小原子单元是容器，并且，它专注于在容器级别和流程模型上交付分布式原子单元
◆Kubernetes在管理应用程序的生命周期、健康检查、恢复、部署和扩展等方面都做得很出色，但是在运行于容器内的分布式应用的其他方面却没有做得很好，例如灵活的网络，状态管理和绑定
◼ 尽管Kubernetes 拥有有状态的工作负载、服务发现、cron作业及其他功能，但是所有这些原语都是在容器级别的，并且在容器内部，开发人员仍然必须使用特定于语言的库实现更高级的功能
◆ 这其实就是推动诸如Envoy、Linkerd、Consul、Knative、Dapr和Camel-K等项目的原因
网络
◼ Kubernetes提供的围绕服务发现的基本网络功能打下了良好的基础，但这对于现代应用程序来说却仍嫌不足
◆随着微服务数量的增加和部署的加快，在不改动服务的情况下，对更高级的发布策略，管理安全性，指标，跟踪，从错误中恢复，模拟错误等等方面的需求变得越来越具有吸引力，并产生了一种新的软件类别，称为服务网格
◼ 服务网格将网络相关的关注点从包含业务逻辑的服务转移出来，放到一个单独的运行时中，该运行时可能是Sidecar，也可能是节点级代理
◼服务网格可以执行高级路由、协助完成测试、处理某些方面的安全性问题，甚至可以支持特定于应用的协议（例如，Envoy支持Kafka、MongoDB、Redis和MySQL等）
◼除了典型的服务网格外，还有其它项目，例如Skupper等，它们证实了将网络能力放入外部运行时代理的趋势
◆ 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）

16、未来的架构趋势

除了生命周期之外，现在我们已然可以直接使用网络监测、状态抽象、声明性事件以及端点绑定等功能，而EIP（企业集成模式）则是该列表中的下一个元素

如果我们把不同领域进行创新的各种云原生项目进行叠加，那么最终将得到类似下图的组合形式
◼ 需要注意的是，上图只是用于说明，它有目的地选择了具有代表性的项目，并把它们映射为分布式原语的一种
◼ 实际上，我们不会同时使用所有这些项目，因为它们中的一些是重叠的，并且工作负载模型也并不兼容

四、云原生

1、云计算的发展历程

“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。这种特性经常被称为像水电一样使用IT基础设施。
vmware–>opnestack–>docker–>k8s–>CNCF–>服务网格–>tikv

2、Pivotal的定义

云原生概念的提出
2013年，Pivotal公司的Matt Stine首次提出这一概念
云原生架构的特征
2015年，Matt Stine在其《迁移到云原生架构》一书中定义：12要素应用、微服务架构、自服务敏捷架构、基于API协作、抗脆弱性
云原生架构特征2.0
2017年，Matt Stine重新修正了云原生特征：可测试、可处理、可替换
Pivotal网站的定义
2017年，Pivotal在其网站定义云原生的特征：DevOps、CD、微服务和容器化

3、CNCF及云原生定义

2015年7月：CNCF成立 Cloud Native Computing Foundation
2015年：云原生定义初始版（应用容器化、面向微服务、容器编排）
2018年：云原生定义v1.0（容器化、微服务、服务网格、声明式API、不可变基础设施）

4、CNCF对云原生的定义

2018年， CNCF在关于云原生定义v1.0版本中这样描述云原生技术体系
⚫ 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用
⚫ 云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术

5、容器技术 （Containers）和容器编排

“Kubernetes已经成为Linux容器开发事实上的标准。”
—— Michael Hinterland ICS 云和自动化与 ICS 系统和中间件团队主管，Porsche Informatik
容器技术采用已经很普遍，全球近50%的受访者至少在一定程度上在生产环境中使用容器

6、容器采用阶段调研结果

7、Kubernetes对于云原生应用策略的重要性

毋庸置疑，基于容器和 Kubernetes 的基础架构是新一轮应用开发的基础，是实现数字化转型的关键。
Kubernetes对云原生应用策略的重要性的调研结果：
绝大多数受访者认为，Kubernetes 对于旨在实现容器编排的云原生应用策略很重要，如上所示。调研结果还显示，容器和Kubernetes 的使用量可能会持续增长。30% 的 IT 领导者预计，在未来 12 个月内，容器的使用量将大大增加。另有 42% 的受访者预计容器的使用量会稍微增加。

8、Kubernetes和声明式API

Kubernetes的关键特性
⚫ 容器编排系统
⚫ 声明式API
◆ 遵循“控制器模式”
⚫ “以应用为中心”的现代应用基础设施
◆ 纳管各类基础支撑类服务，并经由声明式API向上层应用暴露这些基础设施的能力
⚫ Platform for Platform 类型的系统
◆ 根本目标在于方便基础设施工程师构建其它的平台系统
◆ 例如 Service Mesh或Serverless等

9、不可变基础设施（immutable infrastructure）与一次性组件

不可变基础设施是早在2013年由Chad Fowler在其一篇博客中提出的一个很有的预见性的构想
⚫ 其核心思想在于，任何基础设施的实例一旦创建之后即变为只读状态，若需要修改和升级，只能通过替换为新的实例来实现
⚫ 传统的服务器（裸金属或虚拟机）支持配置的多次变更，因而通常会导致如下问题
◆ 灾难发生时，重新构建较为困难（因手动的变更操作所致）
◆ 存在导致状态不一致的风险
实现
⚫ 容器和容器镜像
⚫ 云端虚拟化组件

10、云原生架构的参考示例

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

12、华为云一站式DevOps开发流水线可加速业务敏捷上线

13、华为云ASM服务网格

14、企业IT建设的“三阶段两转变”

服务器阶段
⚫ 以硬件设备为中心，业务应用随不同厂商设备、操作系统、虚拟化软件的差异进行定制
⚫ 设备的安装、调试，应用的部署、运维基本靠人力完成，自动化程度低，缺乏统一的设备和应用管理能力
云化阶段
⚫ 各类资源如计算、存储、网络由虚拟化软件统一进行池化管控，实现了资源管理自动化，做到了以资源为中心部署应用
⚫ 屏蔽了基础设施的一部分差异，为上层业务软件提供了统一的资源管理接口，应用的通用性得到增强
⚫ 虚拟化软件平台差异较大，容易被厂商锁定
云原生阶段
⚫ 完全屏蔽底层基础设施（包括云厂商）的差异，应用部署无须再关注底层基础环境
⚫ 企业关注点转变为“以应用为中心”，包括应用敏捷交付、快速弹性、平滑迁移、无损容灾等
⚫ 业务通用能力也将下沉为基础设施的一部分

15、企业IT数字化战略从“Cloud First”转向 “Cloud Native First”

16、云原生建设发展阶段