简介

提前看了《云原生架构白皮书》一直想着要写点东西，拖延来去《白皮书》已经正式发布2天了，我还迟迟没有动手。没动手的一方面原因是我的懒癌症又犯了；另一个原因是《白皮书》覆盖面之广，基本触及到云原生的方方面面，而我在云原生方面的知识储备不足以支撑我写出一篇好文。
云原生概念虽然在2013年就已被提出，但到目前为止各家对它的理解都些许不同的侧重，在这儿阿里给出了自己对云原生的理解。看《白皮书》目录如下图，全文从7个章节对云原生架构进行剖析、讲解。我也从这7个方面带大家快速过一遍……

为什么需要云原生

这一部分内容比较少，大家可以看下《白皮书》上是怎么说的。我理解的重点是：科技发展进入了云的时代，硬件升级，更新速度要求越来越高，「生产关系」已经严重制约「生产力」的发展。在云的时代，需要新的技术架构，来解决人们「生产力」越来越高的要求。于是，云原生架构应运而生。

云原生架构

云原生架构定义

从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的 非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、 可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

利用云服务和提升软件交付能力，进一步加快软件开发
让开发专注于对公司业务最核心的部分，剥离大量非功能性特性
具有高度自动化的软件交付

云原生架构原则

1. 服务化原则: 把一个大服务拆分成多个小服务，每个小团队负责指定服务，各个服务间的升级互不影响，加快业务迭代的速度。
2. 弹性原则: 弹性是指系统的部署规模可以随着业务量的变化自动伸缩。
3. 可观测原则: 可观测性是指通过log, trace, metric等手段，让一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见。
4. 韧性原则: 韧性是指当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力。
5. 所有过程自动化原则: 软件技术栈的复杂度和组件规模的增加，带来了软件交付的复杂性，通过使用自动化交付工具实现交付和运维的自动化。
6. 零信任原则: 默认情况下不应该信任网络内部和外部的任何人 / 设备 / 系统，需要基于认证和授权重构访 问控制的信任基础。
7. 架构持续演进原则: 现在技术和业务还处在快速变化的时代，云原生架构本身也需要具有具备持续演进能力。

主要架构模式

1. 服务化架构模式: 服务化架构是云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约(例如 IDL)定义彼此业务关系，以标准协议(HTTP、gRPC 等)确保彼此的互联互通，结合 DDD(领域模型驱动)、TDD(测试驱动开发)、容器化部署提升每个接口的代码质量和迭代速度。
2. Mesh 化架构模式: Mesh化架构是把中间件框架(比如 RPC、缓存、异步消息等)从业务进程中分离，让中间件 SDK与业务代码进一步解耦。
3. Serverless 模式: Serverless模式更进一步，把用户从非核心中解放出来，只需要关心核心业务逻辑。
4. 存储计算分离模式: 把存储这种有状态的操作和计算这种不需要状态的操作分别用不同的方式处理。
5. 分布式事务模式: 微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源。但实际使用场景中总有一些别的因素考量。所以有下面几个分布式事务模式分别适应不同的场景：XA模式、BASE、TCC模式、SAGA模式、AT 模式。
6. 可观测架构: 可观测架构包括 Logging、Tracing、Metrics 三个方面。
7. 事件驱动架构: 本质上是一种应用 / 组件间的集成架构模式。

典型的云原生架构反模式

1. 庞大的单体应用: 庞大单体应用的最大问题在于缺乏依赖隔离，因此需要考虑通过服务化进行一定的拆分。
2. 单体应用“硬拆”为微服务: 服务的拆分需要适度，过分服务化拆分反而会导致新架构与组织能力的不匹配。
3. 缺乏自动化能力的微服务: 当软件规模变大后，自动化能力的缺失还会带来更大的危害。

主要的云原生技术

容器技术

容器技术背景与价值

Docker 提出了创新的应用打包规范 —— Docker 镜像，解耦了应用与运行环境，使应用可以在不同计 算环境间一致、可靠地运行。让开发所需要的灵活性、开放 性和运维所关注的标准化、自动化达成相对平衡。

容器编排

Kubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提
供了分布式应用管理的核心能力。
Kubernetes 在容器编排中有几个关键设计理念:

1. 声明式API
2. 可扩展性架构
3. 可移植性

云原生微服务

微服务发展背景

在云原生时代，云原生微服务体系将充分利用云资源的高可用和安全体系，让应用获得更有保障的弹性、 可用性与安全性。

微服务设计约束

相较于单体应用，微服务架构的架构转变，在提升开发、部署等环节灵活性的同时，也提升了在运维、监控环节的复杂性。
1 微服务个体约束: 个微服务修改或者发布时，不应该影响到同一系统里另一个微服务的业务交互。
2 微服务与微服务之间的横向关系: 主要微服务的可发现性和可交互性处理服务间的横向关系。
3 微服务与数据层之间的纵向约束: 在微服务领域，提倡数据存储隔离原则。对于有状态的微服务，通常使用计算与存储分离的方式.
4 全局视角下的微服务分布式约束: 微服务系统设计一开始，就需要考虑全局视角。

云原生微服务典型架构

第一代微服务架构:

第二代微服务架构:

第三代微服务架构:

第四代微服务架构:

主要微服务技术

Apache Dubbo
Spring Cloud
Eclipse MicroProfile
Tars
SOFAStack
Dapr

Serverless

1 技术特点

全托管的计算服务
通用性
自动的弹性伸缩
按量计费

2 常见场景

小程序 /Web/Mobile/API 后端服务
大规模批处理任务
基于事件驱动架构的在线应用和离线数据处理
开发运维自动化

3 技术关注点

计算资源弹性调度
负载均衡和流控
安全性

开放应用模型(OAM)

2019 年末，阿里云联合微软共同发布了 Open Application Model (OAM) 开源项目，其主要目标是解决从 Kubernetes 项目到“以应用为中心”的平台之间最关键环节——标准化应用定义。

Service Mesh 技术

Service Mesh 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流 量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注 微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。

根据 Gartner 研究报告，Istio 有望成为 Service Mesh 的事实标准（话外音:OUC的成立不知道会不会对此事造成影响？），而 Service Mesh 本身也将成为容器服务技术的标配技术组件。

DevOps

1 概述
DevOps 就是为了提高软件研发效率，快速应对变化，持续交付价值的的一系列理念和实践，其基本思想就是 持续部署(CD)，让软件的构建、测试、发布能够更加快捷可靠，以尽量缩短系统变更从提交到最后安全部署到生产 系统的时间。

要实施 DevOps，需要遵循一些基本原则，这些原则被简写为 CAMS:

文化(Culture) 
自动化(Automation) 
度量(Measurement) 
共享(Sharing)

运维平台一般都经历过如下几个发展阶段:手工、脚本、工具、平台、智能化运维等。
现有运维平台虽然很多实现方式，但总体来说分为两类:

指令式 
声明式

阿里云原生架构设计

阿里巴巴独有的云原生架构设计方法——ACNA(Alibaba Cloud Native Architecting)。ACNA 是一个 「4+1」 的架构设计流程
「4」 代表架构设计的关键视角，包括:

企业战略视角
业务发展视角
组织能力视角
云原生技术架构视角

「1」 表示云原生架构的架构持续演进闭环。

4 个架构视角和一个闭环的关系如下图所示:

阿里云原生产品介绍

云原生产品家族

阿里巴巴云原生产品家族包括容器产品家族、微服务产品家族、Serverless 产品家族、Service
Mesh 产品家族、消息产品、云原生数据库家族、云原生大数据产品家族等。

1. 容器产品家族:

容器服务 Kubernetes 版(ACK)
Serverless Kubernetes(ASK)
镜像服务(ACR)

1. 微服务产品家族

EDAS(企业分布式应用服务)
MSE(微服务引擎)
ACM(应用配置管理)
CSB Micro Gateway(微服务网关服务)
GTS(全局事务服务)
ARMS(应用实时监控服务 ) 
链路追踪(Tracing Analysis)
PTS(Performance Testing Service)

1. Serverless 产品家族

FC(函数计算)
SAE(Serverless 应用引擎)
Serverless 工作流

1. Service Mesh 产品家族

托管服务网格(ASM)
AHAS(应用高可用服务)

1. 消息产品家族

消息队列 RocketMQ 版
消息队列 Kafka 版
消息队列 AMQP 版
微消息队列 MQTT 版
阿里云消息服务 MNS
事件总线 EventBridge

1. 云原生数据库产品家族

PolarDB
PolarDB-X

1. 云原生大数据产品家族

云原生数据仓库 AnalyticDB MySQL 版
云原生数据仓库 AnalyticDB PostgreSQL 版

各行业面临的挑战&解决方案

分别举了「申通」「完美日记」「特步」「中国联通」「Timing App」5个例子

云原生架构未来发展趋势

容器技术发展趋势

趋势一:无处不在的计算催生新一代容器实现

新的容器运行时技术解决了安全隔离性、执行效率和通用性三个不同维度的要求:

KataContainer
Firecracker
gVisor
Unikernel 

趋势二:云原生操作系统开始浮现

Linux 的计算调度单元是进程，调度范围限制在一台计算节点。而 Kubernetes 的调度单位是 Pod， 可以在分布式集群中进行资源调度，甚至跨越不同的云环境。

趋势三: Serverless 容器技术逐渐成为市场主流

通过 Serverless 容器，一方面根本性解决 Kubernetes 自身复杂性问题，让用户无需受困于 Kubernetes 集群容量规划、安全维护、故障诊断等运维工作; 一方面进一步释放云计算能力，将安全、可用性、可伸缩性等需求下沉到基础设施实现。

趋势四:动态、混合、分布式的云环境将成为新常态

对于企业客户而言，有些业务出于对数据主权、安全隐私的考量，会采用混合云架构。一些企业为了满足安全合规、成本优化、提升地域覆盖性和避免云厂商锁定等需求，会选择多个云厂商。混合云 / 多云 架构已成为企业上云新常态。

基于云原生的新一代应用编程界面

包括生命周期管理、运维管理、配置范围和扩展和管理、以及语言无关的编程框架，一起构成了崭新的应 用与云之间的编程界面。这一变革的核心逻辑还是把应用中和业务无关的逻辑和职责，剥离到云服务，并在这个过程 中形成标准，让应用开发者能够在专有云、公有云、或者混合云的场景中，都能有一致的研发运维体验。

Serverless 发展趋势

1 趋势一:Serverless 将无处不在
2 趋势二:Serverless 将通过事件驱动的方式连接云及其生态中的一切
3 趋势三:Serverless 计算将持续提高计算密度，实现最佳的性能功耗比和性能价格比