软考 系统架构设计师系列知识点之云原生架构设计理论与实践（9）

接前一篇文章：软考 系统架构设计师系列知识点之云原生架构设计理论与实践（8）

所属章节：

第14章. 云原生架构设计理论与实践

          第2节 云原生架构内涵

14.2 云原生架构内涵

关于云原生的定义有众多版本，对于云原生架构的理解也不尽相同。本节将根据广泛的云原生技术、产品和上云实践，给出一般性的理解。

14.2.3 主要架构模式

云原生架构有非常多的架构模式，这里选取一些对应用收益更大的主要架构模式进行讨论。

1. 服务化架构模式

2. Mesh化架构模式

3. Serverless模式

4. 存储计算分离模式

5. 分布式事务模式

6. 可观测架构

可观测架构包括Logging、Tracing、Metrics三个方面。其中Logging提供多个级别（verbose/debug/warning/error/fatal）的详细信息跟踪，由应用开发者主动提供；Tracing提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics则提供对系统量化的多维度度量。

架构决策者需要选择合适的、支持可观测的开源框架（比如Open Tracing、Open Telemetry等），并规范上下文的可观测数据规范（例如方法名、用户信息、地址位置、请求参数等），规划这些可观测数据在哪些服务和技术组件中传播，利用日志和ttracing信息中的spanid/traceid，确保进行分布式链路分析时有足够的信息进行快速关联分析。

由于建立可观测性的主要目标是对服务SLO（Service Level Objective）进行度量，从而优化SLA（Service Level Agreement），因此架构设计上需要为各个组件定义清晰的SLO，包括并发度、耗时、可用时长、容量等。

7. 事件驱动架构

事件驱动架构（EDA，Event Driven Architecture）本质上是一种应用/组件间的集成架构模式。

事件和传统的消息不同，事件具有schema，所以可以校验event的有效性，同时EDA具备QoS（Quality of Service）保障机制，也能够对事件处理失败进行响应。事件驱动架构不仅用于（微）服务解耦，还可应用于下面的场景中：

（1）增强服务韧性

由于服务间是异步集成的，也就是下游的任何处理失败甚至宕机都不会被上游感知，自然也就不会对上游带来影响。

（2）CQRS（Command Query Responsibility Segregation）

把对服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的API接口；结合EDA中的Event Souring机制可以用于维护数据变更的一致性，当需要重新构建服务状态时，把EDA中的事件重新“播放”一遍即可。

（3）数据变化通知

在服务架构下，往往一个服务中的数据发生变化，另外的服务会感兴趣。比如，用户订单完成后，积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级。

（4）构建开放式接口

在EDA下，事件的提供者并不用关心有哪些订阅者，不像服务调用的场景——数据的产生者需要知道数据的消费者在哪里并调用它，因此保持了接口的开放性。

（5）事件流处理

应用于大量事件流（而非离散事件）的数据分析场景，典型应用是基于Kafka的日志处理。

基于事件触发的响应：在IoT时代，大量传感器产生的数据，不会像人机交互一样需要等待处理结果的返回，天然适合用EDA来构建数据处理应用。

更多内容请看下回。