[系统架构设计师]云原生架构设计理论与实践（十四）

1.代码结构发生巨大变化

2.非功能性特性大量委托给云原生架构来解决：高可用能力，容灾能力，安全特性，可运维性，易用性，可测试性，灰度发布能力

3.高度自动化的软件交付

1.服务化原则：通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代

2.弹性原则：系统的部署规模可以随着业务量的变化而自动伸缩

3.可观测性原则：通过日志，链路跟踪和度量等手段，使得多次服务调用的耗时，返回值和参数都清晰可见

4.韧性原则：软件所依赖的软硬件组件出现异常时，软件表现出来的防御能力

5.所有过程自动化原则：让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化

6.零信任原则：不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础

7.架构持续演进原则：架构具备持续演进能力

1.服务化架构模式：要求以应用模块为颗粒度划分一个应用软件，以接口契约（例如IDL）定义彼此业务关系，

以标准协议（HTTP，gRPC）确保彼此的互联互通，结合领域驱动模型（DDD），测试动开发（TDD），容器化部署提升每个接口的代码质量和迭代速度

2.Mesh化架构模式：把中间件框架（如RPC，缓存，异步消息等）从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务没有影响，甚至迁移到另一个平台的中间件也对业务透明

3.Serverless模式：适合事件驱动的数据计算任务，计算时间短的请求/响应应用，没有复杂相互调用的长周期任务

4.存储计算分离模式：无状态应用不存在一致性维度，可获得很好的可用性和分区容错性，因而获得更好的弹性

5.分布式事务模式：XA模式（传统采用XA模式），基于消息的最终一致性（BASE），TCC模式，SAGA模式，开源项目SEATA的AT模式

6.可观测架构：Logging，Tracing，Metrics

7.事件驱动架构（EDA）：应用/组件间的集成架构模式

1.庞大的单体应用

2.单体应用"硬拆"为微服务

3.缺乏自动化能力的微服务

资源调度，应用部署与管理，自动修复，服务发现与负载均衡，弹性伸缩，声明式API，可扩展性架构，可移植性

设计约束：

1.微服务个体约束：微服务应用的功能在业务领域划分上应该是相互独立的

2.微服务与微服务之间的横向关系：可发现性和可交互性处理微服务间的横向关系

3.微服务与数据层之间的纵向约束：数据存储隔离（DSS）原则数据访问通过API访问

4.全局视角下的微服务分布式约束：全自动化，支持蓝绿，金丝雀等不同发布策略

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

服务网格主要技术：Istio，Linkerd，Consul

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

服务网格主要技术：Istio，Linkerd，Consul