网站是做流程图,联想用来网站开发笔记本,网站开发目录,科技网站模板云原生架构有非常多的架构模式#xff0c;这里列举一些对应用收益更大的主要架构模式#xff0c;如服务化架构模式、Mesh化架构模式、Serverless模式、存储计算分离模式、分布式事务模式、可观测架构、事件驱动架构等。
1.服务化架构模式 服务化架构是云时代构建云原生应用的… 云原生架构有非常多的架构模式这里列举一些对应用收益更大的主要架构模式如服务化架构模式、Mesh化架构模式、Serverless模式、存储计算分离模式、分布式事务模式、可观测架构、事件驱动架构等。
1.服务化架构模式 服务化架构是云时代构建云原生应用的标准架构模式要求以应用模块为颗粒度划分一个软件以接口契约例如IDL定义彼此业务关系以标准协议HTTP、gRPC等确保彼此的互联互通结合DDD领域模型驱动、TDD测试驱动开发、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务模式其中小服务可以看作是一组关系非常密切的服务的组合这组服务会共享数据小服务模式通常使用于非常大型的软件系统避免接口的颗粒度太细而导致过多的调用损耗特别是服务间调用和数据一致性处理和治理复杂度。 通过服务化架构把代码模块关系和部署关系进行分离每个接口可以部署不同数量的实例单独扩缩容从而使得整体的部署更经济。此外由于在进程级实现了模块的分离每个接口都可以单独升级从而提升了整体的迭代效率。但也需要注意服务拆分导致要维护的模块数量增多如果缺乏服务的自动化能力和治理能力会让模块管理和组织技能不匹配反而导致开发和运维效率的降低。
2.Mesh化架构模式 Mesh化架构是把中间件框架如RPC、缓存、异步消息等从业务进程中分离让中间件SDK与业务代码进一步解耦从而使得中间件升级对业务进程没有影响甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务过程中只保留很“薄”的Client部分Client通常很少变化只负责与Mesh进程通信原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。整个架构如图1所示。 图1 Mesh化架构 实施Mesh化架构后大量分布式架构模式熔断、限流、降级、重试、反压、隔仓…… 都由Mesh进程完成即使业务代码的制品中并没有使用这些三方软件包同时获得更好的安全性比如零信任架构能力、按流量进行动态环境隔离、基于流量做冒烟/回归测试等。
3.Serverless模式 Serverless将“部署”这个动作从运维中“收走”使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等从架构抽象上看当业务流量到来/业务事件发生时云会启动或调度一个已启动的业务进程进行处理处理完成后云自动关闭/调度业务进程等待下一次触发也就是把应用的整个运行都委托给云。
4.存储计算分离模式 分布式环境中的CAP困难主要是针对有状态应用因为无状态应用不存在C一致性这个维度因此可以获得很好的A可用性和P分区容错性因而获得更好的弹性。在云环境中推荐把各类暂态数据如session、结构化和非结构化持久数据都采用云服务来保存从而实现存储计算分离。但仍然有一些状态如果保存到远端缓存会造成交易性能的明显下降比如交易会话数据太大、需要不断根据上下文重新获取等这时可以考虑通过采用时间日志快照或检查点的方式实现重启后快速增量恢复服务减少不可用对业务的影响时长。
5.分布式事务模式 微服务模式提倡每个服务使用私有的数据源而不是像单体这样共享数据源但往往大颗粒度的业务需要访问多个微服务必然带来分布式事务问题否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。 1传统采用XA模式虽然具备很强的一致性但是性能差。 2基于消息的最终一致性BASE通常有很高的性能但是通用性有限。 3TCC模式完全由应用层来控制事务事务隔离性可控也可以做到比较高效但是对业务的侵入性非常高设计开发维护等成本很高。 4SAGA模式与TCC模式的优缺点类似但没有try这个阶段而是每个正向事务都对应一个补偿事务也是开发维护等成本很高。 5开源项目SEATA的AT模式非常高性能且无代码开发工作量且可以自动执行回滚操作同时也存在一些使用场景限制。
6.可观测架构 可观测架构包括Logging、Tracing、Metrics三个方面其中Logging提供多个级别verbose/debug/warming/error/fatal的详细信息跟踪由应用开发者主动提供Tracing提供一个请求从前端到后端的完整调用链路跟踪对于分布式场景尤其有用Metrics则提供对系统量化的多维度度量。
7.事件驱动架构 事件驱动架构EDA,Event Driven Architecture本质上是一种应用/组件间的集成架构模式。 事件和传统的消息不同事件具有schema所以可以校验event的有效性同时EDA具备QoS保障机制也能够对事件处理失败进行响应。事件驱动架构不仅用于微服务解耦还可应用于下面的场景中。 1增强服务韧性由于服务间是异步集成的也就是下游的任何处理失败甚至宕机都不会被上游感知自然也就不会对上游带来影响。 2CQRSCommand Query Responsibility Segregation把对服务状态有影响的命令用事件来发起而对服务状态没有影响的查询才使用同步调用的API接口结合EDA中的Event Sourcing机制可以用于维护数据变更的一致性当需要重新构建服务状态时把EDA中的事件重新“播放”一遍即可。 3数据变化通知在服务架构下往往一个服务中的数据发生变化另外的服务会感兴趣比如用户订单完成后积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级。 4构件开放式接口在EDA下事件的提供者并不用关心有哪些订阅者不像服务调用的场景——数据的产生者需要知道数据的消费者在哪里并调用它因此保持了接口的开放性。 5事件流处理应用于大量事件流而非离散事件的数据分析场景典型应用是基于Kafka的日志处理。 基于事件触发的响应在IoT时代大量传感器产生的数据不会像人机交互一样需要等待处理结果的返回天然适合用EDA来构建数据处理应用。
