4.8 云原生架构
" 云原生" 来自于cloud Native的直译，拆开来看，cloud就是指其应用软件和服务是在云端而非传统意义上的数据中心。Native 代表应用软件从一开始就是基于云环境，专门为云端特性而设计，可充分利用和发挥云环境的弹性与分布式优势，最大化释放云环境生产力。
4.8.1 发展概述
出于协调开发和运维的"信息对称"问题，开发者又推出了一套新的方法--DevOps。DevOps可以看作是开发、技术运营和质量保障三者的交集，促进他们之间的沟通、协作与整合，从而提高开发周期和效率。
4.8.2 架构定义
从技术的角度，云原生架构 是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性 (如弹性、韧性、安全、可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
由于云原生是面向"云"而设计的应用，因此，技术部分依赖于传统云计算的3层概念，即基础设施即服务(laas)、平台即服务(Paas)和软件即服务(Saas)。
云原生的代码通常包括三部分 ：业务代码、三方软件、处理非功能特性的代码。
·"业务代码"指实现业务逻辑的代码；
·"三方软件"是业务代码中依赖的所有三方库，包括业务库和基础库；
·"处理非功能特性的代码"指实现高可用、安全、可观测性等非功能性能力的代码。
三部分中只有业务代码是核心，是给业务真正带来价值的，另外两个部分都只算附属物。
4.8.3 基本原则
关于云原生架构原则，立足不同的价值视角或技术方向等有所不同，常见的原则主要包括服务化、弹性、可观测、韧性、所有过程自动化、零信任、架构持续演进等原则。
4.8.4 常用架构模式
云原生架构有非常多的架构模式，不同的组织环境、业务场景和价值定位等，通常采用不同的架构模式，常用的架构模式 主要有服务化架构、Mesh化架构、Serverless、存储计算分离、分布式事务、可观测、事件驱动等。
1.服务化架构模式
服务化架构 是新时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约(例如IDL) 定义彼此业务关系，以标准协议 (HTTP、gRPC等) 确保彼此的互联互通，结合领域模型驱动 (Domain容器化
Driven Design,DDD) 测试驱动开发(Test Driven Development, TDD)部署提升每个接口的代码质量和迭代速度。
服务化架构的典型模式是微服务和小服务模式，其中小服务可以看作是一组关系非常密切的服务的组合，这组服务会共享数据。小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗(特别是服务间调用和数据一致性处理)和治理复杂度。
2.Mesh化架构模式
Mesh (网格)化架构是把中间件框架 (如RPC、缓存、异步消息等)从业务进程中分离，让中间件的软件开发工具包 (Software Development Kit,SDK)与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。
分离后在业务进程中只保留很"薄"的client部分，client通常很少变化，
只负责与Mesh进程通信，原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。
- Serverless 模式
Serverless (无服务器)将"部署"这个动作从运维中"收走"，使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等。也就是把应用的整个运行都委托给云。
·Serverless并非适用任何类型的应用：
①如果应用是有状态的，由于serverless的调度不会帮助应用做状态同步，因此云在进行调度时可能导致上下文丢失；
②如果应用是长时间后台运行的密集型计算任务，会无法发挥Serverless的优势；
③如果应用涉及频繁的外部I/O (包括网络或者存储，以及服务间调用等)， 也因为繁重的1/0负担、时延大而不适合。
·Serverless非常适合于 ：事件动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。
4.存储计算分离模式
分布式环境中的CAP (一致性：Consistency；可用性：Availability；分区容错性：Partitiontolerance)困难主要是针对有状态应用，因为无状态应用不存在C(一致性)这个维度，因此可以获得很好的A (可用性)和P (分区容错性)，因而获得更好的弹性。
在云环境中，推荐把各类暂态数据 (如session)结构化和非结构化持久
数据都采用云服务来保存，从而实现存储计算分离。
5.分布式事务模式
微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源
但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。
6.可观测架构
可观测架构 包括Logging、Tracing、Metrics三个方面。
·Logging (日志)提供多个级别的详细信息跟踪，由应用开发者主动提供；
·Tracing (追踪)提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；
·Metrics (度量)则提供对系统量化的多维度度量。
架构决策者需要选择合适的、支持可观测的开源框架。
由于建立可观测性的主要目标是对服务SLO (Service Level objective，服务级别目标)进行度量，从而优化SLA (Service Level Agreement，服务水平协议)，因此架构设计上需要为各个组件定义清晰的SLO，包括并发度、耗时
可用时长、容量等。
7.事件驱动架构
事件驱动架构 (Event Driven Architecture,EDA) 本质上是一种应用/组件
间的集成架构模式。
事件驱动架构不仅用于 (微) 服务解耦，还可应用于下面的场景中
(1) 增强服务韧性。
(2) CQRS (命令查询的责任分离)。
(3) 数据变化通知。
(4) 构建开放式接口。
(5) 事件流处理。
(6) 基于事件触发的响应。