本文主要介绍了云原生架构的主要设计模式,讨论了这些模式的优缺点及其适用场景,并探讨了在云计算环境中的应用和挑战。原文: Cloud-Native Architecture Patterns (Part 1),Cloud-Native Architecture Patterns (Part 2)
![Bernard Hermant @Unsplash](https://img-blog.csdnimg.cn/img_convert/c71022994e6942da2879b2d2a899cef8.png)
在云原生环境中构建应用时,软件架构可能会采用略有不同的方法。云原生应用广泛采用微服务形式构建,此外,应用程序应该能在动态调度和容器化环境中运行,以便利用云计算模型的优势。
云环境中软件架构背后的动机是关注点分离,尤其是运行在容器中的模块化软件组件,以下模式有助于实现这一目的。
边车(Sidecar)/插件(Sidekick)
如果想在不同微服务中抽象出主应用程序的某些外围部分,这种模式会很有帮助,这有助于实现服务之间的独立性,打破紧密耦合的组件。
如果应用程序使用相同的语言和库,需要共享生命周期但又能独立部署的服务,那么 Sidecar/Sidekick 模式将是一个有益的选择。如果为每个实例部署 Sidecar 服务的资源成本不值得隔离的优势,那么在应用程序中实施 Sidecar/Sidekick 模式就是一个错误的决定。如下图所示,日志、配置等功能可以抽象到另一个微服务中。该模式与主服务的关系为 1:1
![Sidecar/Sidekick 模式](https://img-blog.csdnimg.cn/img_convert/bbd3b22f103c22a479c06542c77c4810.png)
大使(Ambassador)
大使模式通常用于扩展现有服务的网络能力,尤其是在该服务已经过时或复杂到需要修改的情况下。
大使服务可被视为与客户端同处一地的进程外代理。
通过这种模式增加额外代理会带来延迟。与 Sidecar 不同,这种模式可用于多种服务,有助于增强传统服务的连接功能。因为 Ambassador 模式有代理开销,如果对低延迟要求很高,那么这种模式就不是个好选择。
![大使模式](https://img-blog.csdnimg.cn/img_convert/84206daeeb18740a6d96ceab35acc627.png)
分散(Scatter)/聚合(Gather)
这种模式适用于使用冗余服务的传统应用,其主要思想是建立一个聚合器,汇总来自不同服务的响应,并提供最佳响应。这种模式可以很好的控制流向其他服务的消息流。
![分散/聚集模式](https://img-blog.csdnimg.cn/img_convert/7a97f475a1c78867f69f18f5dce0d723.png)
BFF(Backends For Frontend)
这种模式的要点是在前端和真正的后端之间再做一层后端,就是所谓的BFF(Backend For Frontend),是在广泛应用的最流行的模式之一。通过添加这一额外层,可以在不同的前端和后端服务之间进行协调,验证来自前端的过滤响应,映射和转换从后端交付的数据模型。
![alt](https://img-blog.csdnimg.cn/img_convert/7f5ca755042361ba6ffe1e567ef0c53c.png)
防腐层(Anti-Corruption Layer)
如果系统中有不同的子系统或微服务,它们的语义并不相同,那么这种模式可能会非常有用。防腐层(Anti-Corruption Layer)可以翻译或整合这些服务之间的通信。Eric Evans在《领域驱动设计》(Domain-Driven Design)一书中首次介绍了这一模式。
如果你正在将遗留系统迁移到新系统,因此部分新系统使用了遗留系统的功能资源,那么就很可能出现这种情况。
可能有如下缺点和副作用:
-
这一额外层引入了更多延迟 -
这一层也是额外的服务,会占用资源 -
可维护性、数据一致性、自动缩放以及连接服务的开销也需要被额外关注
![ACl 模式](https://img-blog.csdnimg.cn/img_convert/778754de24458be8094541b8fec27b9d.png)
命令与查询责任分离(CQRS, Command and Query Responsibility Segregation)
这种模式基于数据库读取和更新的 SoC(Separation of Concerns,关注点分离)。在传统架构中,如果读取执行许多查询,而写入执行非常复杂的验证和业务逻辑,就会出现数据复杂性问题。这种读写不对称,具有不同的性能和需求。
这里的解决方案可能是 CQRS,将读写分离成不同的部分,命令用于更新,查询用于读取:
-
命令必须基于任务("预订酒店房间",而不是"将预定状态设为已预订")。 -
通过异步通信执行命令 -
查询从不更改数据库。查询响应的 DTO 不包含业务逻辑。
这种模式的缺点是读写组件保持同步。
![CQRS 模式](https://img-blog.csdnimg.cn/img_convert/0bb6dc412772ad75858cb32aebe2d840.png)
事件源(Event Sourcing)
事件源模式(Event Sourcing Pattern)是近十年来针对 CRUD 应用缺乏一致性的情况而流行的技术之一。与传统 CRUD 应用一样,事件源的主要思想是以仅增加(append-only)的方式保存数据,而不仅仅保存当前状态,从而存储对数据采取的一系列完整操作。这种方式为事务性数据提供了一致性,保持了对历史版本的全面审计控制。
优势:
-
通过实现强大的数据一致性来提高性能 -
使用事件存储简化数据版本的实施和管理 -
事件对于领域专家来说是可读的,而不仅是让开发人员可以理解 -
由于事件基于时间排序,可以防止对同一数据进行并发更新 -
事件存储作为数据操作的单一来源
缺点:
-
被认为是对小领域应用的过度设计 -
不适合实时数据驱动型应用
你好,我是俞凡,在Motorola做过研发,现在在Mavenir做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。为了方便大家以后能第一时间看到文章,请朋友们关注公众号"DeepNoMind",并设个星标吧,如果能一键三连(转发、点赞、在看),则能给我带来更多的支持和动力,激励我持续写下去,和大家共同成长进步!
本文由 mdnice 多平台发布