一、 为什么需要云原生架构？
企业内部 IT 建设以“烟筒”模式比较多，每个部门甚至每 个应用都相对独立，如何管理与分配资源成了难题。大家都基于最底层 IDC 设施独自向上构建，都需要 单独分配硬件资源，这就造成资源被大量占用且难以被共享。
但是上云之后，由于云厂商提供了统一的 IaaS 能力和云服务，大幅提升了企业 IaaS 层的复用程度，CIO 或者 IT 主管自然而然想到 IaaS 以上层 的系统也需要被统一，使资源、产品可被不断复用，从而能够进一步降低企业运营成本。
二、 云原生架构定义
应用的开发人员就不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端（云存储，如对象存储，文件存储，块存储等）的问题，也不 用处理当业务峰值到来时如何对存储节点进行扩容（HPA）的问题，而应用的运维人员不用在发现 zero day 安全 问题时紧急对三方存储软件进行升级。
非功能性特性的大量委托
任何应用都提供两类特性，功能性特性和非功能性特性。
功能性特性 是真正为业务带来价值的代码， 比如如何建立客户资料、如何处理订单、如何支付等等；即使是一些通用的业务功能特性，比如组织管理、 业务字典管理、搜索等等也是紧贴业务需求的。
非功能性特性 是没有给业务带来直接业务价值，但通常 又是必不可少的特性，比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发 布能力等等。
以大家最头疼的高可用为例，云产品在多个层面为应用提供了解决方案：
虚机：当虚机检测到底层硬件异常时，自动帮助应用做热迁移，迁移后的应用不需重新启动而仍然具 备对外服务的能力，应用对整个迁移过程都不会有任何感知；
容器：有时应用所在的物理机是正常的，只是应用自身的问题（比如 bug、资源耗尽等）而无法正常 对外提供服务。容器通过监控检查探测到进程状态异常，从而实施异常节点的下线、新节点上线和生产 流量的切换等操作，整个过程自动完成而无需运维人员干预；
云服务：如果应用把“有状态”部分都交给了云服务（如缓存、数据库、对象存储等），加上全局对象的持有小型化或具备从磁盘快速重建能力，由于云服务本身是具备极强的高可用能力，那么应用本身会变成更薄的“无状态”应用，因为高可用故障带来的业务中断会降至分钟级；如果应用是 N-M 的对等架构模式，那么结合 Load Balancer 产品可获得几乎无损的高可用能力！
高度自动化的软件交付
软件一旦开发完成，需要在公司内外部各类环境中部署和交付，以将软件价值交给最终客户。软件交 付的困难在于开发环境到生产环境的差异（公司环境到客户环境之间的差异）以及软件交付和运维人员 的技能差异，填补这些差异的是一大堆安装手册、运维手册和培训文档。容器以一种标准的方式对软件 打包，容器及相关技术则帮助屏蔽不同环境之间的差异，进而基于容器做标准化的软件交付。
对自动化交付而言，还需要一种能够描述不同环境的工具，让软件能够“理解”目标环境、交付内容、 配置清单并通过代码去识别目标环境的差异，根据交付内容以“面向终态”的方式完成软件的安装、配置、 运行和变更。
基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例，应用微 服务化以后，往往被部署到成千上万个节点上，如果系统不具备高度的自动化能力，任何一次新业务的 上线，都会带来极大的工作量挑战，严重时还会导致业务变更超过上线窗口而不可用。
三、云原生架构原则
1、服务化原则
2、弹性原则
3、 可观测原则
今天大部分企业的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需 要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、哪些服务违反了其定义的 SLO、目前 的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等，这些都要求系统具备更强的可观 测能力。可观测性与监控、业务探活、APM 等系统提供的能力不同，前者是在云这样的分布式系统中， 主动通过日志、链路跟踪和度量等手段，让一次 APP 点击背后的多次服务调用的耗时、返回值和参数都 清晰可见，甚至可以下钻到每次三方软件调用、SQL 请求、节点拓扑、网络响应等，这样的能力可以使 运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析 能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。
4、 韧性原则
当业务上线后，最不能接受的就是业务不可用，让用户无法正常使用软件，影响体验和收入。韧性代 表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，这些异常通常包括硬件故障、 硬件资源瓶颈（如 CPU/ 网卡带宽耗尽）、业务流量超出软件设计能力、影响机房工作的故障和灾难、 软件 bug、黑客攻击等对业务不可用带来致命影响的因素。
韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是降低软件的 MTBF（Mean Time Between Failure，平均无故障时间）。
从架构设计上，韧性包括服务异步化能力、重试 / 限流 / 降级 / 熔断 / 反压、主从模式、集群模式、AZ 内的高可用、单元化、跨 region 容灾、异地多活容灾等。
5、 所有过程自动化原则
6、 零信任原则
7、 架构持续演进原则
今天技术和业务的演进速度非常快，很少有一开始就清晰定义了架构并在整个软件生命周期里面都适 用，相反往往还需要对架构进行一定范围内的重构，因此云原生架构本身也应该和必须是一个具备持续 演进能力的架构，而不是一个封闭式架构。
四、 主要架构模式
云原生架构有非常多的架构模式，这里选取一些对应用收益更大的主要架构模式进行讨论。
1、服务化架构模式
服 务化架构的典型模式是微服务和小服务（Mini Service）模式，其中小服务可以看做是一组关系非常密切 的服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度 太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。
2、 Mesh 化架构模式
如服务网格（Service Mesh）。
Mesh 化架构是把中间件框架（比如 RPC、缓存、异步消息等）从业务进程中分离，让中间件 SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件 也对业务透明。分离后在业务进程中只保留很“薄”的 Client 部分，Client 通常很少变化，只负责与 Mesh 进程通讯，原来需要在 SDK 中处理的流量控制、安全等逻辑由 Mesh 进程完成。
3、 Serverless 模式
和大部分计算模式不同，Serverless 将“部署”这个动作从运维中“收走”，使开发者不用关心应 用在哪里运行，更不用关心装什么 OS、怎么配置网络、需要多少 CPU …… 从架构抽象上看，当业务 流量到来 / 业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭 / 调度业务进程，等待下一次触发，也就是把应用的整个运行时都委托给云。
4、 存储计算分离模式
分布式环境中的 CAP 困难主要是针对有状态应用，因为无状态应用不存在 C（一致性）这个维度， 因此可以获得很好的 A（可用性）和 P（分区容错性），因而获得更好的弹性。在云环境中，推荐把各类暂态数据（如 session）、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。 但仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不 断根据上下文重新获取等，则可以考虑通过采用 Event Log + 快照（或 Check Point）的方式，实现重 启后快速增量恢复服务，减少不可用对业务的影响时长。
5、 分布式事务模式
微服务模式 提倡 每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务 需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。
架构师需要根据不同的场景选择合适的分布式事务模式。
传统采用 XA 模式，虽然具备很强的一致性，但是性能差；
基于消息的最终一致性（BASE）通常有很高的性能，但是通用性有限，且消息端只能成功而不能触发消息 生产端的事务回滚；
TCC 模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效；但是对业务的侵入性非常强， 设计开发维护等成本很高；
SAGA 模式与 TCC 模式的优缺点类似但没有 try 这个阶段，而是每个正向事务都对应一个补偿事务，也是 开发维护成本高；
开源项目 SEATA 的 AT 模式非常高性能且无代码开发工作量，且可以自动执行回滚操作，同时也存在一些 使用场景限制。
6、 可观测架构
可观测架构包括 Logging、Tracing、Metrics 三个方面。
其中 Logging 提供多个级别（verbose/ debug/warning/error/fatal）的详细信息跟踪，由应用开发者主动提供；
Tracing 提供一个请求从前端 到后端的完整调用链路跟踪，对于分布式场景尤其有用；
Metrics 则提供对系统量化的多维度度量。
架构决策者需要选择合适的、支持可观测的开源框架（比如 OpenTracing、OpenTelemetry）， 并规范上下文的可观测数据规范（例如方法名、用户信息、地理位置、请求参数等），规划这些可观测 数据在哪些服务和技术组件中传播，利用日志和 tracing 信息中的 span id/trace id，确保进行分布式链路分析时有足够的信息进行快速关联分析。
由于建立可观测性的主要目标是对服务 SLO（Service Level Objective）进行度量，从而优化 SLA，因此架构设计上需要为各个组件定义清晰的 SLO，包括并发度、耗时、可用时长、容量等。
7、 事件驱动架构
五、 主要云原生技术
主要有容器技术， 云原生微服务 ，以下分别说明
六、容器技术
1、容器技术背景与价值
在过去几年，容器技术获得了越发广泛的应用的同时，三个核心价值最受用户关注：
- 敏捷
容器技术提升企业 IT 架构敏捷性的同时，让业务迭代更加迅捷，为创新探索提供了坚实的技术保障。比如 疫情期间，教育、视频、公共健康等行业的在线化需求突现爆发性高速增长，很多企业通过容器技术适时把握了 突如其来的业务快速增长机遇。据统计，使用容器技术可以获得 3~10 倍交付效率提升，这意味着企业可以更快 速的迭代产品，更低成本进行业务试错。
- 弹性
- 可移植性
2、 容器编排
Kubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提 供了分布式应用管理的核心能力：
资源调度 ：根据应用请求的资源量 CPU、Memory，或者 GPU 等设备资源，在集群中选择合适的节点来运 行应用；
应用部署与管理 ：支持应用的自动发布与应用的回滚，以及与应用相关的配置的管理；也可以自动化存储卷 的编排，让存储卷与容器应用的生命周期相关联；
自动修复 ：Kubernetes 可以会监测这个集群中所有的宿主机，当宿主机或者 OS 出现故障，节点健康检查 会自动进行应用迁移；K8s 也支持应用的自愈，极大简化了运维管理的复杂性；
服务发现与负载均衡 ：通过 Service 资源出现各种应用服务，结合 DNS 和多种负载均衡机制，支持容器化应用之间的相互通信；
弹性伸缩 ：K8s 可以监测业务上所承担的负载，如果这个业务本身的 CPU 利用率过高，或者响应时间过长， 它可以对这个业务进行自动扩容。
Kubernetes 的控制平面包含四个主要的组件：API Server、Controller、Scheduler 以及 etcd。如 下图所示：
Kubernetes 在容器编排中有几个关键设计理念：
声明式 API： 开发者可以关注于应用自身，而非系统执行细节。比如 Deployment（无状态应用）、 StatefulSet（有状态应用）、Job（任务类应用）等不同资源类型，提供了对不同类型工作负载的抽象；对 Kubernetes 实现而言，基于声明式 API 的 “level-triggered” 实现比 “edge-triggered” 方式可以提 供更加健壮的分布式系统实现。
可扩展性架构 ：所有 K8s 组件都是基于一致的、开放的 API 实现和交互；三方开发者也可通过 CRD（Custom Resource Definition）/Operator 等方法提供领域相关的扩展实现，极大提升了 K8s 的能力。
可移植性 ：K8s 通过一系列抽象如 Loadbalance Service（负载均衡服务）、CNI（容器网络接口）、CSI（容器存储接口），帮助业务应用可以屏蔽底层基础设施的实现差异，实现容器灵活迁移的设计目标。
七、 云原生微服务
1、云原生微服务典型架构
自从微服务架构理念在 2011 年提出以来，典型的架构模式按出现的先后顺序大致分为四代。
第一代微服务架构中，应用除了需要实现业务逻辑之外，还需要自行解决上下游寻址、通讯，以及容错等问题。 随着微服务规模扩大，服务寻址逻辑的处理变得越来越复杂，哪怕是同一编程语言的另一个应用，上述微服务的基础 能力都需要重新实现一遍。
在第二代微服务架构中，引入了服务注册中心作为协调者来完成服务的自动注册和发现。服务之间的通讯以及容错机制开始模块化，形成独立服务框架。
但是随着服务框架内功能日益增多，用不同语言的基础功能复用显得十分困难，这也就意味着微服务的开发者被迫被绑定在某种特定语言上，从而违背了微服务的敏捷迭代原则。
2016 年出现了第三代微服务架构 - 服务网格，原来被模块化到服务框架里的微服务基础能力，被进一步的从一 个 SDK 演进成为一个独立进程 - Sidecar。这个变化使得第二代架构中多语言支持问题得以彻底解决，微服务基础 能力演进和业务逻辑迭代彻底解耦。这个架构就是在云原生时代的微服务架构 - Cloud Native Microservices，边车（Sidecar）进程开始接管微服务应用之间的流量，承载第二代中服务框架的功能，包括服务发现、调用容错，到 丰富的服务治理功能，例如：权重路由、灰度路由、流量重放、服务伪装等。
近两年开始，随着 AWS Lambda 的出现，部分应用开始尝试利用 Serverless 来架构微服务，这种方式被称之为第四代微服务架构。
在这个架构中，微服务进一步由一个应用简化为微逻辑（Micrologic），从而对边车模式提出 了更高诉求，更多可复用的分布式能力从应用中剥离，被下沉到边车中，例如：状态管理、资源绑定、链路追踪、事 务管理、安全等等。
同时，在开发侧开始提倡面向 localhost 编程的理念，提供标准 API 屏蔽掉底层资源、服务、 基础设施的差异，进一步降低微服务开发难度。这个也就是目前业界提出的多运行时微服务架构（Muti-Runtime Microservices）。
2、 主要微服务技术
Apache Dubbo 作为源自阿里巴巴的一款开源高性能 RPC 框架，特性包括基于透明接口的 RPC、智能负载均 衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。经过数年发展已是国内使用最广泛的 微服务框架并构建了强大的生态体系。为了巩固 Dubbo 生态的整体竞争力，2018 年阿里巴巴陆续开源了 SpringCloud Alibaba( 分布式应用框架 )、Nacos( 注册中心 & 配置中心 )、Sentinel( 流控防护 )、Seata( 分布式事务 )、 Chaosblade( 故障注入 )，以便让用户享受阿里巴巴十年沉淀的微服务体系，获得简单易用、高性能、高可用等核心 能力。Dubbo 在 v3 中发展 Service Mesh，目前 Dubbo 协议已经被 Envoy 支持，数据层选址、负载均衡和服务 治理方面的工作还在继续，控制层目前在继续丰富 Istio/Pilot-discovery 中。
Spring Cloud 作为开发者的主要微服务选择之一，为开发者提供了分布式系统需要的配置管理、服务发现、断 路器、智能路由、微代理、控制总线、一次性 Token、全局锁、决策竞选、分布式会话与集群状态管理等能力和开 发工具。
Eclipse MicroProfile 作 为 Java 微 服 务 开 发 的 基 础 编 程 模 型， 它 致 力 于 定 义 企 业 Java 微 服 务 规 范， MicroProfile 提供指标、API 文档、运行状况检查、容错与分布式跟踪等能力，使用它创建的云原生微服务可以自 由地部署在任何地方，包括 Service Mesh 架构。
Tars 是腾讯将其内部使用的微服务框架 TAF（Total Application Framework）多年的实践成果总结而成的开 源项目，在腾讯内部有上百个产品使用，服务内部数千名 C++、Java、Golang、Node.Js 与 PHP 开发者。Tars 包含一整套开发框架与管理平台，兼顾多语言、易用性、高性能与服务治理，理念是让开发更聚焦业务逻辑，让运维 更高效。
SOFAStack（Scalable Open Financial Architecture Stack）是由蚂蚁金服开源的一套用于快速构建金融 级分布式架构的中间件，也是在金融场景里锤炼出来的最佳实践。MOSN 是 SOFAStack 的组件，它一款采用 Go 语言开发的 Service Mesh 数据平面代理，功能和定位类似 Envoy ，旨在提供分布式、模块化、可观测、智能化的 代理能力。MOSN 支持 Envoy 和 Istio 的 API ，可以和 Istio 集成。
Dapr（Distributed Application Runtime ，分布式应用运行时）是微软新推出的，一种可移植的、Serverless 的、事件驱动的运行时，它使开发人员可以轻松构建弹性，无状态和有状态微服务，这些服务运行在云和边缘上，并 包含多种语言和开发框架。
八、 Serverless
1、 技术特点
随着以 Kubernetes 为代表的云原生技术成为云计算的容器界面，Kubernetes 成为云计算的新一代操作 系统。面向特定领域的后端云服务（BaaS）则是这个操作系统上的服务 API，存储、数据库、中间件、大数据、 AI 等领域的大量产品与技术都开始提供全托管的云形态服务，如今越来越多用户已习惯使用云服务，而不是自 己搭建存储系统、部署数据库软件。
当这些 BaaS 云服务日趋完善时，Serverless 因为屏蔽了服务器的各种运维复杂度，让开发人员可 以将 更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。Serverless 计算包含以下特征：
- 全托管的计算服务： 客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施 的开发、运维、安全、高可用等工作；
- 通用性： 结合云 BaaS API 的能力，能够支撑云上所有重要类型的应用；
- 自动的弹性伸缩： 让用户无需为资源使用提前进行容量规划；
- 按量计费： 让企业使用成本得有效降低，无需为闲置资源付费。
参考：
阿里云云原生架构白皮书
