云原生架构模式
常见模式列举
服务化架构模式
服务化架构是云时代构建云原生应用的标准架构模式,要求以应用模块为颗粒度划分一个软件,以接口契约(例如 IDL)定义彼此业务关系,以标准协议(HTTP、gRPC 等)确保彼此的互联互通,结合DDD(领域模型驱动)、TDD(测试驱动开发)、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务。
需要注意,服务拆分导致要维护的模块数量增多,如果缺乏服务的自动化能力和治理能力,会让模块管理和组织技能不匹配,反而导致开发和运维效率的降低。
Mesh 化架构模式
Mesh 化架构是把中间件框架(比如 RPC、缓存、异步消息等)从业务进程中分离,让中间件 SDK 与业务代码进一步解耦,从而使得中间件升级对业务进程没有影响,甚至迁移到另外一个平台的中间件也对业务透明。
Serverless 模式
Serverless 将“部署”这个动作从运维中“收走”,使开发者不用关心应用在哪里运行,更不用关心装什么 OS、怎么配置网络、需要多少 CPU …… 从架构抽象上看,当业务流量到来 / 业务事件发生时,云会启动或调度一个已启动的业务进程进行处理,处理完成后云自动会关闭 / 调度业务进程,等待下一次触发。也就是把应用的整个运行时都委托给云。
Serverless 并不适合所有的应用场景,适合于事件驱动的数据计算任务、计算时间短的请求 / 响应应用、没有复杂相互调用的长周期任务。
存储计算分离模式
分布式环境中的 CAP 困难主要是针对有状态应用,因为无状态应用不存在 C(一致性)这个维度,因此可以获得很好的 A(可用性)和 P(分区容错性),因而获得更好的弹性。在云环境中,推荐把各类暂态数据(如 session)、结构化和非结构化持久数据都采用云服务来保存,从而实现存储计算分离。
分布式事务模式
微服务模式提倡每个服务使用私有的数据源,而不是像单体这样共享数据源,但往往大颗粒度的业务需要访问多个微服务,必然带来分布式事务问题,否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。
传统采用 XA 模式,虽然具备很强的一致性,但是性能差;
基于消息的**最终一致性(BASE)**通常有很高的性能,但是通用性有限,且消息端只能成功而不能触发消息生产端的事务回滚;
TCC 模式完全由应用层来控制事务,事务隔离性可控,也可以做到比较高效;但是对业务的侵入性非常强,设计开发维护等成本很高;
SAGA 模式与 TCC 模式的优缺点类似但没有 try 这个阶段,而是每个正向事务都对应一个补偿事务,也是开发维护成本高;
开源项目 SEATA 的 AT 模式非常高性能且无代码开发工作量,且可以自动执行回滚操作,同时也存在一些使用场景限制。
可观测架构
可观测架构包括 Logging、Tracing、Metrics 三个方面,其中 Logging 提供多个级别(verbose/debug/warning/error/fatal)的详细信息跟踪,由应用开发者主动提供;Tracing 提供一个请求从前端到后端的完整调用链路跟踪,对于分布式场景尤其有用;Metrics 则提供对系统量化的多维度度量。
建立可观测性的主要目标是对**服务 SLO(Service Level Objective)**进行度量,从而优化 SLA,因此架构设计上需要为各个组件定义清晰的 SLO,包括并发度、耗时、可用时长、容量等。
事件驱动架构
事件驱动架构(EDA,Event Driven Architecture)本质上是一种应用 / 组件间的集成架构模式,事件和传统的消息不同,事件具有 schema,所以可以校验 event 的有效性,同时 EDA 具备 QoS 保障机制,也能够对事件处理失败进行响应。事件驱动架构不仅用于**(微)服务解耦**,还可应用于以下场景中: