微服务架构10个最重要的设计模式

《微服务架构10个最重要的设计模式》由会员分享，可在线阅读，更多相关《微服务架构10个最重要的设计模式（19页珍藏版）》请在金锄头文库上搜索。

1、微效劳架构 10 个最重要的设计模式自从软件开发的早期 (1960 年月)以来，解决大型软件系统中的简单性始终是一项困难的任务。多年来，软件工程师和架构师为解决软件系统的简单性进展了 很多尝试： David Parnas 的模块化和信息隐蔽 (1972)，Edsger W. Dijkstra 的关注分别(1974)，面对效劳的体系构造 (1998)。他们全部人都使用了久经考验的成熟技术来解决大型系统的简单性：分而治 之。自 2021 年月以来，这些技术缺乏以解决 Web 规模应用程序或现代大型企业应用程序的简单性。结果，架构师和工程师开发了一种新方法来解决现代软件系 统的简单性：微效劳架构。它

2、也使用了一样的旧 “分而治之“技术，尽管承受了新颖的方式。软件设计模式是解决软件设计中常见问题的通用，可重用的解决方案。设计模式可挂念我们共享通用词汇，并使用经过实战检验的解决方案，而不是重新制造轮子。今日描述的是一组设计模式，以挂念您实现这些最正确实践。本文主要内容： 微效劳架构 微效劳架构的优势 微效劳架构的缺点 何时使用微效劳架构 微效劳架构设计模式请留意，此清单的大多数设计模式都有几种上下文，可以在非微效劳体系构造中使用。但是我将在微效劳架构的背景下对其进展描述。微效劳架构微效劳体系构造： 简要概述以及为什么要在下一个工程中使用它以及模块化单片软件体系构造真的死了吗 ?我的微效劳架构定

3、义是：微效劳架构旨在将大型，简单的系统垂直 (按功能或业务要求)划分为较小的子系统，这些子系统属于流程 (因此可独立部署)，并且这些子系统之间通过与语言无关的轻量级网络通信相互通信 (例如 REST，gRPC)或异步(通过消息传递)方式。这是具有微效劳架构的业务 Web 应用程序的组件视图： Microservice Architecture by Md Kamaruzzaman 微效劳架构的重要特征： 整个应用程序分为多个单独的进程，每个进程可以包含多个内部模块。 与模块化 Monoliths 或 SOA 相反，微效劳应用程序是垂直拆分的 (依据业务力量或领域)微效劳边界是外部的。结果，微效

4、劳通过网络调用 (RPC 或消息)相互通信。 由于微效劳是独立的流程，因此它们可以独立部署。他们以轻松的方式交流，不需要任何智能沟通渠道。微效劳架构的优势： 更好的开发规模。 更高的进展速度。 支持迭代或增量现代化。 充分利用现代软件开发生态系统 (云，容器， DevOps，无效劳器 )的优势。 支持水平缩放和粒度缩放。 由于尺寸较小，它降低了开发人员的认知简单度。微效劳架构的缺点： 大量的活动部件(效劳，数据库，流程，容器，框架 )。 简单性从代码转移到根底架构。 RPC 调用和网络流量的激增。 治理整个系统的平安性具有挑战性。 设计整个系统比较困难。 介绍分布式系统的简单性。何时使用微效劳

5、架构： Web 规模应用程序开发。 当多个团队处理应用程序时，进展企业应用程序开发。 长期收益优先于短期收益。 该团队拥有能够设计微效劳架构的软件架构师或高级工程师。微效劳架构的设计模式每个微效劳独占数据库一旦公司用很多较小的微效劳替换了大型的单片系统，它面临的最重要的决 定就是关于数据库。在整体架构中，使用大型中心数据库。很多架构师都宠爱保 留数据库原样，即使他们转向微效劳架构也是如此。尽管它供给了一些短期好处， 但它是一种反模式，尤其是在大规模系统中，由于微效劳将严密耦合在数据库层 中。转向微效劳的整个目标将失败 (例如，团队授权，独立开发 )。更好的方法是为每个微效劳都供给自己的数据存储

6、，以使数据库层中的效劳之间不存在强耦合。在这里，我使用数据库一词来表示数据的规律分别，即微服务可以共享同一物理数据库，但是它们应当使用单独的架构/集合/表。它还将确保依据域驱动设计正确隔离微效劳。 Database per Microservice by Md Kamaruzzaman优点： 数据对效劳的完全全部权。 开发效劳的团队之间的松耦合。缺点： 在效劳之间共享数据变得布满挑战。 供给应用程序范围的 ACID 事务保证变得更加困难。 将 Monolith 数据库分解为较小的零件需要认真设计，这是一项困难的任务。每个微效劳何时使用数据库： 在大型企业中的应用。 当团队需要其微效劳的完全全部

7、权以进展开发扩展和提高开发速度时。什么时候不使用每个微效劳的数据库： 在小型应用中。 假设一个团队开发全部微效劳。启用技术例如：全部 SQL 和 NoSQL 数据库都供给规律上的数据分别 (例如，分别的表，集合，模式，数据库)。大事源 Event Sourcing在微效劳架构中，尤其是在每个微效劳使用数据库的状况下，微效劳需要交换数据。对于有弹性，高度可扩展和容错的系统，它们应通过交换大事进展异步通信。在这种状况下，可能需要进展原子操作，例如，更新数据库并发送消息。如 果您有 SQL 数据库，并且期望为大量数据安排分布式事务，那么不能使用两阶段锁定(2PL)，由于它无法扩展。假设使用 NoSQ

8、L 数据库并期望具有分布式事务，那么不能使用2PL，由于很多 NoSQL 数据库不支持两阶段锁定。在这种状况下，请结合使用基于大事的体系构造和大事源。在传统数据库中， 具有当前“状态“的业务实体被直接存储。在大事源中，将存储任何状态更改大事 或其他重要大事，而不是实体。这意味着业务实体的修改将保存为一系列不行变的大事。通过在给定时间重新处理该业务实体的全部大事，可以扣除该业务实体的状态。由于数据存储为一系列大事，而不是通过直接更新数据存储来存储，所以各种效劳可以从大事存储中重播大事以计算其各自数据存储的适当状态。 Event Sourcing by Md Kamaruzzaman优点： 为高度

9、可扩展的系统供给原子性。 实体的自动历史记录，包括时间旅行功能。 松散耦合和大事驱动的微效劳。缺点： 从大事存储中读取实体变得具有挑战性，通常需要额外的数据存储(CQRS 模式) 系统的整体简单性增加，通常需要域驱动设计。 系统需要处理重复大事(幂等)或丧失大事。 迁移大事模式变得具有挑战性。何时使用大事来源： 具有 SQL 数据库的高度可扩展的事务系统。 带有 NoSQL 数据库的事务系统。 高度可扩展且具有弹性的微效劳架构。 典型的消息驱动或大事驱动系统 (电子商务，预订和预订系统 )。何时不使用大事来源： 具有 SQL 数据库的低伸缩性事务系统。 在简洁的微效劳架构中，微效劳可以同步交换

10、数据 (例如，通过 API)。启用技术例如： 大事存储： EventStoreDB ，Apache Kafka ，Confluent Cloud ，AWS Kinesis，Azure 大事中心， GCP 公布/订阅，Azure Cosmos DB，MongoDB， Cassandra 。Amazon DynamoDB ， 框架：Lagom，Akka，Spring，akkatecture ，Axon，Eventuate命令查询职责隔离 (CQRS)假设我们使用大事源，那么从大事存储中读取数据将变得布满挑战。要从数据存储中猎取实体，我们需要处理全部实体大事。另外，有时我们对读写操作有不同的全都性和

11、吞吐量要求。在这种用例中，我们可以使用 CQRS 模式。在 CQRS 模式中，系统的数据修改局部(命令)与数据读取(查询)局部分开。CQRS 模式有两种形式：简洁和高级， 这导致软件工程师之间产生一些混淆。以简洁的形式，不同的实体或 ORM 模型用于读取和写入，如下所示： CQRS (simple) by Md Kamaruzzaman它有助于实施“单一责任原那么“和“关注点分别“，从而使设计更简洁。在其高级形式中，不同的数据存储区用于读取和写入操作。高级CQRS 与大事来源一起使用。依据使用状况，使用不同类型的写入数据存储和读取数据存储。 写入数据存储区是“记录系统“，即整个系统的黄金来源。

12、 CQRS (advanced) by Md Kamaruzzaman对于重读应用程序或微效劳体系构造，将 OLTP 数据库(任何供给 ACID 事务保证的 SQL 或 NoSQL 数据库)或分布式消息平台用作写存储。对于繁重的写程序(高写可伸缩性和吞吐量 )，使用了水平可写伸缩的数据库 (公共云全局数据库)。标准化的数据保存在写入数据存储中。为搜寻(例如 Apache Solr，Elasticsearch) 或读取(键值数据存储，文档数据存储)而优化的 NoSQL 数据库用作读取存储。在很多状况下，在需要 SQL 查询的地方使用可伸缩的 SQL 数据库。归一化和优化的数据将保存在读取存储中。

13、数据从写入存储异步复制到读取存储。结果，读存储区滞后于写存储区，并且最终保持全都。优点： 在大事驱动的微效劳中更快地读取数据。 数据的高可用性。 读写系统可以独立扩展。缺点： 读取数据存储弱全都性(最终全都性) 系统的整体简单性增加。货运培训 CQRS 可能会严峻危害整个工程。何时使用 CQRS： 在使用大事源的高度可扩展的微效劳体系构造中。 在读取数据需要查询到多个数据存储区的简单域模型中。 在读写操作具有不同负载的系统中。何时不使用 CQRS： 在微大事数量微缺乏道的微效劳体系构造中，使用大事存储快照来计算实体状态是更好的选择。 在读写操作具有相像负载的系统中。启用技术例如： 写存储：Ev

14、entStoreDB ，Apache Kafka，Confluent Cloud ，AWS Kinesis， Azure Event Hub，GCP 公布/订阅，Azure Cosmos DB，MongoDB，Cassandra 。亚马逊 DynamoDB 阅读商店： Elastic Search，Solr，Cloud Spanner ，Amazon Aurora，Azure Cosmos DB ，Neo4j 框架：Lagom，Akka，Spring，akkatecture ，Axon，EventuateSAGA假设您将微效劳体系构造与每个微效劳的数据库一起使用，那么通过分布式事务治理全都性就

15、具有挑战性。您不能使用传统的两阶段提交协议，由于它无法扩展(SQL 数据库)或不被支持(很多 NoSQL 数据库)。您可以将 Saga 模式用于 Microservice Architecture 中的分布式事务。Saga 是一种旧模式，于 1987 年开发，作为 SQL 数据库中长期运行的数据库事务的概念替代方案。但是，这种模式的现代变体对于分布式事务也格外有效。 Saga 模式是一个本地事务序列，其中每个事务在单个微效劳中更新数据存储中的数据并发 布大事或消息。传奇中的第一个事务由外部恳求 (大事或操作)启动。一旦本地事务完成(数据存储在数据存储中，并且公布消息或大事)，公布的消息 /大事将触发Saga 中的下一个本地事务。 Saga by Md Kamaruzzaman假设本地事务失败，那么 Saga 执行一系列补偿事务，以撤消从前本地事务的更改。Saga 交易协调主要有 两种变体： 分散的协调，每个微效劳生成并收听其他微效劳的大事 /消息，并打算是否应当实行措施