序
本文是对《阿里云云原生架构实践》的笔记与摘要，借助官方的视角来增加一下了解。
序与前言
序
云原生，究其根本意义，是规范“用云”的架构模式、技术标准......
希望云原生能够将过去在应用架构层做的大量工作，尤其是弹性与韧性，下沉到云平台层去实现......
“三位一体”：技术社区的云原生产品及标准与阿里云客户、阿里巴巴自身业务系统使用的产品及标准，必须是同一套。
云原生也让企业用云方式从“上云”到“云上”转变。
云原生技术则是实现数字化转型的最短路径。
前言
如果你想得到从未拥有过的东西，你就得去做从未做过的事情。 —— 托马斯·杰斐逊
企业急需完整的技术理论方法，以重塑软件全生命周期研发管理体系与技术栈，改造传统IT架构，融合先进技术，提高服务能力，为企业的高速发展提供支持，而这一套完整的技术与理论方法就是云原生。
阿里云认为云原生必将依循“概念引爆—落地尝试—规模复制”的认知升级路径。
云原生介绍
什么是云原生
云原生可分解为“云”（Cloud）和“原生”（Native）两个词。在说云原生的时候，也暗指云原生计算（Cloud Native Computing）。
使用云的变化：应用的整体成本（Total Cost of Ownership, TCO）因为采用了“按量付费”的模式而大幅下降，同时企业的IT支持从CapEx（Capital Expenditure，资本性支出）模式转变为OpEx（Operating Expense，管理支出）模式，整个IT支出变得更可控。
Heroku 于2011年提出了十二因子应用的概念。十二因子适用于任何编程语言，通常被认为是最早的云原生应用的技术特征。
CNCF最新版的云原生定义为：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。.......”
云原生是云计算的再升级
云原生对应用的重构体现在应用开发的整个生命周期中：
- 重塑研发流水线
- 重新定义软件交付模式
- 利用容器做整体交付
- 将 Git 作为 “Single Version of Truth” （唯一真实版本）
- 声明式API
- 尽量采用OpenApi作为系统间的集成方式
- 运维模式的升级
- 基础设施是只读的，好处是任何变更都是可版本化的
- 运维原则是面向观测数据的自动化运维
- 应用架构的升级
- re-platform：不重构代码或不重写代码的情况下，尽量采用云原生技术。如：把Kafaka替换为云服务。
- re-build：需要重构甚至完全重写应用，比如把单体架构改为微服务架构。
- re-host：只是做计算、存储、网络的一对一迁移。不是一种云原生升级方式。
- 组织结构的升级
阿里巴巴上云阶段
- 应用架构互联网阶段（2009-2016，re-build）
- 核心系统全面原生化阶段（2017-2019，re-platform）
- 云原生技术全面升级阶段（2020-，re-build）
云原生架构定义
从技术的角度出发。云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在帮助企业和开发人员充分利用云平台所提供的平台化能力和弹性资源能力。
与传统架构的区别：
- 可以最大化剥离云应用中的非业务代码部分（例如：弹性、韧性、安全、可观测性、灰度等），同时具备轻量、敏捷、高度自动化等特点。
- 可以将计算、存储、网络资源管理以及相应的自动化部署和运维能力，交由云基础设施执行，应用自身因此变得更为灵活。
云原生架构带来的优势：
- 降低研发成本和项目维护复杂度
- 加快软件迭代速度，降低管理和运行成本
云原生架构原则
服务化原则
服务化设计原则是指通过服务化架构拆分不同生命周期的业务单元，实现业务单元的独立迭代，从而加快整体的迭代速度，保证迭代的稳定性，
弹性原则
弹性原则是指系统部署规模可以随着业务量变化而自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源。
构建弹性的系统架构，要遵循四个基本原则：
- 按功能切割应用
- 支持水平切分：其中最大挑战在于数据库系统，数据库系统自身是有状态的。
- 自动化部署
- 支持服务降级
可观测原则
指标（Metric）、链路跟踪（Tracing）和日志（Logging）这三类数据是构建一个完整的可观测性系统的“三大支柱”。
韧性原则
韧性是指软件所依赖的软硬件组件出现异常时，软件所表现出来的抵御能力。
韧性原则的实践有：
- 服务异步化能力
- 重试/限流/降级/熔断/反压
- 主从模式
- 集群模式
- 多AZ（Available Zone, 可用区）的高可用
- 单元化
- 跨区域（Region）容灾
- 异地多活等
所有过程自动化原则
要实现大规模的自动化，需要遵循如下原则:
- 标准化
- 面向终态
- 关注点分离
- 面向失败设计
零信任模型
传统安全架构认为防火墙内的一切都是安全的，而零信任模型假设防火墙边界已经被攻破，且每个请求都来自于不可信网络，因此每个请求都需要经过验证。
架构持续演进原则
演进式架构是指在软件开发的初始阶段，就通过具有可扩展性和松耦合的设计，让后续可能发生的变更更加容易、升级重构的成本更低.......
云原生架构模式和反模式
服务化架构模式
服务化架构通常也称为面向服务的架构（SOA），即在通信双方（服务提供者和服务消费者）之间约定好服务规约，然后基于该规约发布和调用服务。
服务化架构设计的价值体现在：
- 更好地面向业务（Business Oriented）
- 松耦合和灵活性（Loose Coupling & Flexibility）
- 服务共享和复用（Shared Service）
实现服务规约的技术方案有：
- 服务接口定义：指对应的编程语言对服务接口的描述，如 Apache Dubbo。
- IDL定义：指通过IDL（Interface Definition Language，接口定义语言）对服务进行规约定义。如：Google gRPC，Apache Thrift。
- OpenAPI：是基于HTTP REST 通信的接口规范。
- 其它：WSDL、SOAP、xml-rpc、json-rpc、Java RMI 等。
Service Mesh 化架构模式
Service Mesh（服务网格）是专用的基础结构层，主要用于保障服务之间安全、快速和可靠的通信。
Service Mesh 的经典解决方案有：
- SideCar 模式，如：Istio + Envory
- 服务注册和发现模式（Service Register & Discovery），如：Spring Cloud
- 中心化Broker模式，如：RSocket Broker
Sidecar 模式
Sidecar 模式最典型的方案是 Istio + Envory 的结构，其中 Istio 主要负责控制面（Control Plane）的管控，而Envory 则负责数据面（Data Plane）的网络流量转发。
通过代理人通信的好处：
- 服务路由和可靠性保证
- 隔离性和安全性
- 为应用减负
- 服务调用的可观测性
Istio + Envory 模式中的一些问题：
- 对 Kubernetes 的依赖
- 性能损失和资源浪费
- 开发成本增加
服务注册和发现模式
阿里巴巴基于阿里云的基础设施服务，推出了Spring Cloud Alibaba。
中心化Broker模式
中心化 Broker 是指通信双方同时连接到一个中心的 Broker。
Broker 模式的优势：
- 无端口监听
- 无网络要求
- 无底层基础设施依赖
- 无服务注册依赖，无负载均衡要求
- 简化运维
Broker 模式的重大问题：
- 异步化架构：为了应对 C10k 问题，Broker 需要采用异步化架构，但开发成本高，并不多见。
- 协议适配和单点故障。
Serverless 架构模式
Serverless 是一种新型的云计算运行模式，是指由云平台提供应用运行时需要的服务器，并且动态管理应用运行时需要的资源分配。
计算存储分离模式
计算和存储是计算机最核心的组件，将计算和存储分离的原因是考虑了无状态（Stateless）和有状态（Stateful）应用架构的区别。
- 无状态应用：指服务请求和所在的服务器完全无关，即便请求涉及数据相关的逻辑，也是从外部获取。
- 有状态应用：请求和对应的服务器是相关的，如请求涉及的数据就保存在服务器上。
无状态应用架构的好处是不仅是设计简单，更提高了应用的可用性，具备失败后快速迁移的特点。
分布式事务模式
分布式事务的实现主要有5种模式：两阶段提交（2PC）、最终一致性BASE、预留资源的TCC、补偿机制的Saga、高效的AT。
两阶段提交
最知名的是XA协议，存在的问题有：
- 同步阻塞问题
- 单点故障
- 潜在的数据不一致风险
BASE
BASE 是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写。
软状态：指运行系统中的数据存在中间状态，并认为该中间状态不会影响系统的整体可用性和最终一致性。
TCC
TCC 是 Try、Confirm 和 Cancel 的简称，将事务的提交过程分为 try-confirm-cancel 三个阶段。
- try 阶段完成业务检查、预留业务资源
- confirm 阶段使用预留的资源执行业务操作
- cancel 阶段取消执行业务操作，释放预留的资源
Saga
Saga 模式是一种用于解决长事务的实现方案，是一种补偿协议。在该模式下，一个分布式事务内会有多个参与者，每个参与者都是一个带有补偿逻辑的服务，即该服务可以根据业务场景实现正向操作和逆向回滚操作。
在两阶段提交的方案中，XA资源能够支持的通常是数据库事务；而在Saga模式中，服务可以以任何形式存在。
AT
AT（Automatic Transaction）事务模式是阿里巴巴中间件内部为了解决HSF跨服务一致性和TDDL分库分表一致性而演化出来的一种事务模式，在内部称为TXC（Taobao Transaction Constructor）事务模式。
可观测架构模式
可观测性（Observability）主要是指了解程序内部运行情况的能力。主要涉及三个部分：日志（logging）、度量（Metrics）和追踪（Tracing）。
事件驱动架构模式
事件驱动架构是基于事件进行的通信架构。对于事件驱动的系统来说，事件的生成、捕获、通信、监听处理和持久化都是核心结构。
如果是在一个进程中，事件的处理不需要借助消息的机制也能完成。但是在分布式场景中，事件的异步通信还是需要依赖消息来实现的。
网关架构模式
网关也称统一接入层，主要负责处理南北流向（North-South Traffic）的网络请求，如来自浏览器、手机移动端货合作伙伴等的访问流量都会经由网关转发给具体的业务系统。
混沌工程模式
如何通过人为注入故障的方式快速检测故障并协调团队及时修复、检验系统的能力，是一个备受关注的问题。
声明式设计模式
声明式设计，也称为声明式编程，主要目的是通过对目标的描述，让计算机明白要达到的目标，而非过程。与之对应的是命令式编程，强调每一步该如何执行。
典型的云原生架构反模式
- 庞大的单体应用
- 单体应用“硬拆”为微服务
- 缺乏自动化能力的微服务
- 架构不能充分使用云的弹性能力
- 技术架构与组织能力不匹配
云原生技术及概念介绍
容器技术
Docker 容器基于操作系统虚拟化技术，具有共享操作系统内核、轻量、无资源损耗、秒级启动等优势，极大地提升了系统的应用部署密度和弹性。更重要的是，Docker 提出了创新的应用打包规范，即Docker镜像。
Kubernetes 也开源了，在容器编排之战脱颖而出，称为分布式资源调度和自动化运维的事实标准。
容器技术的三个核心价值：敏捷、弹性、可移植性。
典型的容器技术有：容器编排、安全容器、边缘容器。
DevOps技术
DevOps（Development + Operations）作为一组过程、方法与系统的统称，是云原生概念的重要组成部分，旨在促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
微服务
微服务模式将后端的单体应用拆分为多个松耦合的子应用，由每个子应用负责一组子功能。这些子应用称为“微服务”。
Serverless
面向特定领域的后端云服务（Backend as Service，BaaS）提供了性能高度优化、抽象度更高的API，称为构成云原生应用的重要元素。
Serverless 计算包含如下特征：
- 全托管的计算服务
- 通用性
- 自动的弹性伸缩
- 按量计费
Serverless 的典型技术与架构：
- 计算资源弹性调度
- 流量控制
- 安全性
开放应用模型
开放应用模型（Open Application Model，OAM）是描述应用程序及其实现的解耦的规范。
OAM的目标是“让简单的应用程序变得更简单，让复杂的应用程序更易于管理”。
OAM的设计思想：
- 提出云原生“应用”这一概念，并在这个概念中建立了对应用和所需运维能力定义与描述的标准规范。
- 提供更高级的应用层抽象和关注点分离的定义模型。
OAM的核心概念
- 应用组件依赖
- 应用运维特征
- 应用配置
Service Mesh 技术
Service Mesh 又称为服务网格。之所以称为服务网格，是因为每台主机上同时运行了业务逻辑代码和代理，这个代理被形象地称为Sidecar，服务之间通过Sidecar 发现和调用目标服务，从而在服务之间形成一种网络状依赖关系。
之前，微服务软件架构所带来问题采用框架思维解决（能力以SDK的形式提供给开发人员），存在瓶颈：
- 单一编程语言无法有效实现所有业务需求
- SDK 与应用在同一个进程中紧密耦合，让应用无法独立快速演进
Service Mesh 的出现，使得解决问题的思路从之前的框架思维变成了平台思维，SDK中非常固定的内容任然保留在SDK中，其他内容则完全剥离至完全独立的 Proxy （即 Sidecar）进程中。
Service Mesh 因为 Proxy 的引入多了两次IPC通信的成本。
分布式消息队列
分布式消息系统是一种利用高效可靠的消息传递机制进行平台无关的数据交互，并基于数据通信进行分布式系统集成服务的系统。
云原生数据库技术
DBaaS（DataBase as a Service，数据库即服务）
云原生关系数据库，具备的优势有：
- 资源池化，大容量，高性价比
- 提供极致弹性
- 强大的容灾能力及可靠性
- 完全托管
- 智能化 + 自动化管控平台
云原生数据库的一些关键技术：
- 计算存储分离技术
- 计算内存分离技术
- 高可用及数据的一致性
- 数据及日志的复制技术
- 跨地域高可用技术
- Serverless 及多租户技术
- HTAP（Hybrid Transaction/Analytical Processing, 混合事务 / 分析处理）
云原生大数据
云原生大数据的价值：
- 弹性伸缩
- 简单易用
- 性能卓越
云原生大数据的典型技术：
- 数据仓库
- 数据湖
- 实时计算
- 数据治理
云原生AI
云原生AI的典型技术：
- AI 训练平台
- 在线推理服务平台
- AI 服务编排
云端开发
云端开发通常是指基于云平台完成编码、测试、发布等开发流程的闭环。
云原生安全
云原生安全的典型技术：
- 零信任
- DevSecOps
- 云原生安全可信
阿里巴巴云原生架构设计
云平台其实就是大家平常提到的“技术中台”。
软件能力成熟度模型（Capability Maturity Model for Software，CMM），作为一种评估软件实施能力和帮助企业改善软件质量的方法，对软件企业各阶段的管理工作都做了详细描述。
相对CMM，云原生架构的目标更简单，主要是：帮助企业改善软件的架构，使其能够快速、有效地享用云计算提供的各种服务，提升软件的交付效率，降低软件的整体成本，提高软件的交付质量。
阿里巴巴独有的云原生架构设计方法——ACNA（Alibaba Cloud Native Architecting）。
ACNA 认为架构维度保护七个重要的领域：
- 服务化能力
- 弹性能力
- 无服务器化程度
- 可观测性
- 韧性能力
- 自动化水平
- 安全能力
ACNA 包含6个关键的架构维度，简称 SESORA
- Service : 服务化能力
- Elasticity：弹性能力
- Serverless：无服务器化程度
- Observability：可观测性
- Resilience：韧性能力
- Automation：自动化水平
总结
正如书中所提：云平台其实就是大家平常提到的“技术中台”。这本书也很好地定义了日常工作中比较技术的部分，是一本不错的学习资料，也可以培养一些技术认同感~
