当前位置：文档之家 › 微服务架构10个最重要的设计模式

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

  • 格式：docx
  • 大小：49.00 KB
  • 文档页数：19

微服务架构10个最重要的设计模式自从软件开发的早期(1960年代)以来，解决大型软件系统中的复杂性一直是一项艰巨的任务。

多年来，软件工程师和架构师为解决软件系统的复杂性进行了许多尝试：David Parnas的模块化和信息隐藏(1972)，Edsger W. Dijkstra的关注分离(1974)，面向服务的体系结构(1998)。

他们所有人都使用了久经考验的成熟技术来解决大型系统的复杂性：分而治之。

自2010年代以来，这些技术不足以解决Web规模应用程序或现代大型企业应用程序的复杂性。

结果，架构师和工程师开发了一种新方法来解决现代软件系统的复杂性：微服务架构。

它也使用了相同的旧"分而治之"技术，尽管采用了新颖的方式。

软件设计模式是解决软件设计中常见问题的通用，可重用的解决方案。

设计模式可帮助我们共享通用词汇，并使用经过实战检验的解决方案，而不是重新发明轮子。

今天描述的是一组设计模式，以帮助您实现这些最佳实践。

本文主要内容：·微服务架构·微服务架构的优势·微服务架构的缺点·何时使用微服务架构·微服务架构设计模式请注意，此清单的大多数设计模式都有几种上下文，可以在非微服务体系结构中使用。

但是我将在微服务架构的背景下对其进行描述。

微服务架构微服务体系结构：简要概述以及为什么要在下一个项目中使用它以及模块化单片软件体系结构真的死了吗?我的微服务架构定义是：微服务架构旨在将大型，复杂的系统垂直(按功能或业务要求)划分为较小的子系统，这些子系统属于流程(因此可独立部署)，并且这些子系统之间通过与语言无关的轻量级网络通信相互通信(例如REST，gRPC)或异步(通过消息传递)方式。

这是具有微服务架构的业务Web应用程序的组件视图：> Microservice Architecture by Md Kamaruzzaman 微服务架构的重要特征：·整个应用程序分为多个单独的进程，每个进程可以包含多个内部模块。

·与模块化Monoliths或SOA相反，微服务应用程序是垂直拆分的(根据业务能力或领域)微服务边界是外部的。

结果，微服务通过网络调用(RPC或消息)相互通信。

·由于微服务是独立的流程，因此它们可以独立部署。

他们以轻巧的方式交流，不需要任何智能交流渠道。

微服务架构的优势：·更好的开发规模。

·更高的发展速度。

·支持迭代或增量现代化。

·充分利用现代软件开发生态系统(云，容器，DevOps，无服务器)的优势。

·支持水平缩放和粒度缩放。

·由于尺寸较小，它降低了开发人员的认知复杂度。

微服务架构的缺点：·大量的活动部件(服务，数据库，流程，容器，框架)。

·复杂性从代码转移到基础架构。

·RPC调用和网络流量的激增。

·管理整个系统的安全性具有挑战性。

·设计整个系统比较困难。

·介绍分布式系统的复杂性。

何时使用微服务架构：·Web规模应用程序开发。

·当多个团队处理应用程序时，进行企业应用程序开发。

·长期收益优先于短期收益。

·该团队拥有能够设计微服务架构的软件架构师或高级工程师。

微服务架构的设计模式每个微服务独占数据库一旦公司用许多较小的微服务替换了大型的单片系统，它面临的最重要的决定就是关于数据库。

在整体架构中，使用大型中央数据库。

许多架构师都喜欢保留数据库原样，即使他们转向微服务架构也是如此。

尽管它提供了一些短期好处，但它是一种反模式，尤其是在大规模系统中，因为微服务将紧密耦合在数据库层中。

转向微服务的整个目标将失败(例如，团队授权，独立开发)。

更好的方法是为每个微服务都提供自己的数据存储，以使数据库层中的服务之间不存在强耦合。

在这里，我使用数据库一词来表示数据的逻辑分离，即微服务可以共享同一物理数据库，但是它们应该使用单独的架构/集合/表。

它还将确保根据域驱动设计正确隔离微服务。

> Database per Microservice by Md Kamaruzzaman 优点：·数据对服务的完全所有权。

·开发服务的团队之间的松耦合。

缺点：·在服务之间共享数据变得充满挑战。

·提供应用程序范围的ACID事务保证变得更加困难。

·将Monolith数据库分解为较小的零件需要仔细设计，这是一项艰巨的任务。

每个微服务何时使用数据库：·在大型企业中的应用。

·当团队需要其微服务的完全所有权以进行开发扩展和提高开发速度时。

什么时候不使用每个微服务的数据库：·在小型应用中。

·如果一个团队开发所有微服务。

启用技术示例：所有SQL和NoSQL数据库都提供逻辑上的数据分离(例如，分离的表，集合，模式，数据库)。

事件源Event Sourcing在微服务架构中，尤其是在每个微服务使用数据库的情况下，微服务需要交换数据。

对于有弹性，高度可扩展和容错的系统，它们应通过交换事件进行异步通信。

在这种情况下，可能需要进行原子操作，例如，更新数据库并发送消息。

如果您有SQL数据库，并且希望为大量数据分配分布式事务，则不能使用两阶段锁定(2PL)，因为它无法扩展。

如果使用NoSQL数据库并希望具有分布式事务，则不能使用2PL，因为许多NoSQL数据库不支持两阶段锁定。

在这种情况下，请结合使用基于事件的体系结构和事件源。

在传统数据库中，具有当前"状态"的业务实体被直接存储。

在事件源中，将存储任何状态更改事件或其他重要事件，而不是实体。

这意味着业务实体的修改将保存为一系列不可变的事件。

通过在给定时间重新处理该业务实体的所有事件，可以扣除该业务实体的状态。

因为数据存储为一系列事件，而不是通过直接更新数据存储来存储，所以各种服务可以从事件存储中重播事件以计算其各自数据存储的适当状态。

> Event Sourcing by Md Kamaruzzaman优点：·为高度可扩展的系统提供原子性。

·实体的自动历史记录，包括时间旅行功能。

·松散耦合和事件驱动的微服务。

缺点：·从事件存储中读取实体变得具有挑战性，通常需要额外的数据存储(CQRS 模式)·系统的整体复杂性增加，通常需要域驱动设计。

·系统需要处理重复事件(幂等)或丢失事件。

·迁移事件模式变得具有挑战性。

何时使用事件来源：·具有SQL数据库的高度可扩展的事务系统。

·带有NoSQL数据库的事务系统。

·高度可扩展且具有弹性的微服务架构。

·典型的消息驱动或事件驱动系统(电子商务，预订和预订系统)。

何时不使用事件来源：·具有SQL数据库的低伸缩性事务系统。

·在简单的微服务架构中，微服务可以同步交换数据(例如，通过API)。

启用技术示例：·事件存储：EventStoreDB，Apache Kafka，Confluent Cloud，AWS Kinesis，Azure事件中心，GCP发布/订阅，Azure Cosmos DB，MongoDB，Cassandra。

Amazon DynamoDB，·框架：Lagom，Akka，Spring，akkatecture，Axon，Eventuate命令查询职责隔离(CQRS)如果我们使用事件源，那么从事件存储中读取数据将变得充满挑战。

要从数据存储中获取实体，我们需要处理所有实体事件。

另外，有时我们对读写操作有不同的一致性和吞吐量要求。

在这种用例中，我们可以使用CQRS模式。

在CQRS模式中，系统的数据修改部分(命令)与数据读取(查询)部分分开。

CQRS模式有两种形式：简单和高级，这导致软件工程师之间产生一些混淆。

以简单的形式，不同的实体或ORM模型用于读取和写入，如下所示：> CQRS (simple) by Md Kamaruzzaman它有助于实施"单一责任原则"和"关注点分离"，从而使设计更简洁。

在其高级形式中，不同的数据存储区用于读取和写入操作。

高级CQRS与事件来源一起使用。

根据使用情况，使用不同类型的写入数据存储和读取数据存储。

写入数据存储区是"记录系统"，即整个系统的黄金来源。

> CQRS (advanced) by Md Kamaruzzaman对于重读应用程序或微服务体系结构，将OLTP数据库(任何提供ACID事务保证的SQL或NoSQL数据库)或分布式消息平台用作写存储。

对于繁重的写程序(高写可伸缩性和吞吐量)，使用了水平可写伸缩的数据库(公共云全局数据库)。

规范化的数据保存在写入数据存储中。

为搜索(例如Apache Solr，Elasticsearch)或读取(键值数据存储，文档数据存储)而优化的NoSQL数据库用作读取存储。

在许多情况下，在需要SQL查询的地方使用可伸缩的SQL数据库。

归一化和优化的数据将保存在读取存储中。

数据从写入存储异步复制到读取存储。

结果，读存储区滞后于写存储区，并且最终保持一致。

优点：·在事件驱动的微服务中更快地读取数据。

·数据的高可用性。

·读写系统可以独立扩展。

缺点：·读取数据存储弱一致性(最终一致性)·系统的整体复杂性增加。

货运培训CQRS可能会严重危害整个项目。

何时使用CQRS：·在使用事件源的高度可扩展的微服务体系结构中。

·在读取数据需要查询到多个数据存储区的复杂域模型中。

·在读写操作具有不同负载的系统中。

何时不使用CQRS：·在微事件数量微不足道的微服务体系结构中，使用事件存储快照来计算实体状态是更好的选择。

·在读写操作具有相似负载的系统中。

启用技术示例：·写存储：EventStoreDB，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如果您将微服务体系结构与每个微服务的数据库一起使用，那么通过分布式事务管理一致性就具有挑战性。

合集下载

六种微服务架构的设计模式

六种微服务架构的设计模式

六种微服务架构的设计模式微服务架构是一种将大型应用程序拆分成一系列小型独立服务的设计模式，每个服务都有自己的独立业务逻辑和数据库。

这种架构模式可以提高系统的可伸缩性、灵活性和可维护性。

在实际应用中，可以根据需求选择适合的微服务架构设计模式。

下面介绍六种常见的设计模式。

1. 单一职责模式（Single Responsibility Pattern）在这种模式下，每个微服务只负责一个具体的业务功能。

这样可以简化服务的设计和维护，降低耦合性，提高可测试性。

同时，该模式也易于水平扩展，因为可以根据实际需求添加或删除服务。

2. 事件驱动模式（Event-driven Pattern）这种模式下，微服务之间通过事件进行通信，一个服务的操作可以触发一个或多个事件，这些事件被其他服务监听并做出相应的处理。

这种模式可以实现松耦合和异步处理，每个服务可以独立演化而不影响其他服务。

3. 网关模式（Gateway Pattern）在微服务架构中，可以使用一个独立的网关服务来处理所有的请求，然后将请求路由到相应的微服务。

这种模式可以实现请求的集中管理、身份验证和授权，同时还可以提供负载均衡和缓存等功能。

4. 数据复制模式（Data Replication Pattern）在一些情况下，为了提高性能和可用性，可以将数据复制到多个微服务中。

这些微服务可以独立操作自己的副本，提高查询性能和并发处理能力。

同时，数据的复制也增加了系统的可用性，一旦一些服务不可用，可以自动切换到其他可用的服务。

5. 服务发现模式（Service Discovery Pattern）在微服务架构中，服务的数量可能非常庞大，每个服务都有自己的地址和端口号，手动管理会非常复杂。

为了解决这个问题，可以使用服务发现模式，将服务注册到服务发现服务器，并由其他服务进行查询和调用。

这种模式可以实现动态服务的发现和注册，以及负载均衡和故障转移等功能。

6. 服务容错模式（Service Fault-tolerance Pattern）在微服务架构中，由于服务之间的依赖关系，一个服务的故障有可能会导致整个系统的故障。

《微服务架构设计模式》相关考题

《微服务架构设计模式》相关考题

《微服务架构设计模式》相关考题基础知识回顾1.什么是微服务架构？微服务架构是一种以服务为中心的软件设计方法，将应用拆分成一系列小型、自治的服务，每个服务只关注特定的业务功能。

各个服务之间通过轻量级的通信方式进行交互，从而实现系统的高扩展性、高可用性和快速迭代的特性。

2.微服务架构与单体架构的区别是什么？在传统的单体架构中，整个应用作为一个单一的单元被构建和部署。

而在微服务架构中，应用被拆分成多个小型服务，每个服务都有独立的数据库和逻辑。

这种拆分使得每个服务能够独立开发、测试、部署和扩展，使得整个系统更加灵活和可伸缩。

3.为什么要使用微服务架构？使用微服务架构可以带来以下好处：-更高的可扩展性：由于每个微服务都可以独立部署和扩展，系统可以根据需要进行弹性扩展，而无需整体升级。

-更好的可维护性：每个微服务只关注特定的业务功能，使得代码更加模块化和可维护。

-更短的开发周期：微服务架构可以支持团队的并行开发，各个服务可以独立开发、测试和部署，从而加快开发速度。

-更好的系统容错性：由于每个微服务都运行在独立的进程或容器中，当某个服务发生故障时，不会影响整个系统的正常运行。

设计模式与微服务架构1.什么是设计模式？设计模式是一套经过验证的解决特定问题的软件设计原则和方法。

在微服务架构中，设计模式可以帮助我们解决一些常见的问题，如服务间通信、数据一致性等。

2.常用的设计模式有哪些在微服务架构中常用的设计模式有以下几类：-服务发现与注册模式：例如使用服务注册中心来管理服务的注册与发现，如N et fl ix的E u re ka。

-负载均衡模式：例如使用负载均衡器来分发请求给不同的服务实例，如N gi nx。

-断路器模式：用于防止级联故障，当某个服务不可用时，断路器会快速返回失败结果，避免影响到整个系统的正常运行，如Ne tf li x的H y st ri x。

-事件驱动模式：用于实现服务之间的解耦，通过事件的发布与订阅，实现松耦合的组件间通信，如Ap ac he Kaf k a。

软件架构设计的五种常用模式

软件架构设计的五种常用模式

软件架构设计的五种常用模式现在的软件行业中，软件的复杂性和规模越来越大，而软件架构设计可以让我们更好地管理和维护软件系统，以满足业务和技术的需求。

软件架构设计的核心就是选择合适的架构模式，让软件系统在更高的层次上易于使用、扩展和维护。

下面将介绍软件架构设计中的五种常用模式。

一、客户端-服务器模式客户端-服务器模式是最常见的架构模式之一，它使用了两个核心组件：客户端和服务器。

服务器是一个中央处理器，它处理所有的业务逻辑，而客户端则用于接收和呈现数据。

客户端可以是桌面应用程序、Web应用程序或移动应用程序等。

这种模式的最大优势是它的可移植性和可扩展性，因为客户端和服务器是独立的，可以在不影响对方的情况下进行修改和升级。

它也很容易进行并发处理，因为服务器可以同时处理多个客户端的请求。

二、MVC模式MVC（Model-View-Controller）是另一种常见的软件架构模式。

在MVC中，所有的组件都有明确的角色分配：模型（Model）、视图（View）和控制器（Controller）。

模型处理数据和业务逻辑，视图呈现数据并与用户进行交互，控制器协调模型和视图之间的交互。

MVC的优势在于它可以解耦业务逻辑和视图，使得系统更具灵活性和可移植性。

它也很容易进行单元测试和改进，因为它允许各个组件进行独立的测试和修改。

三、面向服务的架构（SOA）面向服务的架构（SOA）是一种分布式系统架构，它将业务逻辑封装在可重用的服务中。

每个服务都提供一组相关的功能并使用标准化的接口进行通信。

客户端通过使用这些服务来访问业务逻辑。

SOA的优势在于它可以支持多种平台和技术，使得系统更具灵活性和可扩展性。

它还可以使开发团队更好地重用和共享代码，从而提高效率和降低成本。

四、微服务架构微服务架构是SOA的一种变体，它将系统拆分成许多小的、独立的服务。

每个服务专注于处理一个特定的需求，并使用标准化的接口进行通信。

这样做可以使得系统更具弹性和可伸缩性，因为每个服务都可以独立部署和升级。

企业级应用的架构与设计模式

企业级应用的架构与设计模式

企业级应用的架构与设计模式随着互联网的普及和技术的不断发展，企业所面临的竞争压力也日益加大。

为了应对这些挑战，企业需要构建稳定、可靠和高效的应用系统。

这就要求企业级应用具备良好的架构和设计模式，以支持系统的可扩展性、可维护性和可伸缩性。

本文将介绍一些常见的企业级应用架构和设计模式，并探讨它们的优缺点。

1.分层架构分层架构是一种常见的企业级应用架构，它将系统划分为多个层次，每个层次都有特定的责任和功能。

通常分为以下几个层次：-表现层：负责处理用户界面和展示逻辑。

-业务逻辑层：负责处理业务逻辑，对外提供服务接口。

-数据访问层：负责与数据库进行交互，处理数据的增删改查操作。

-数据库层：负责存储和管理数据。

分层架构的主要优点是代码的组织清晰，各层之间的关系明确，便于开发和维护。

同时，它也提供了很好的可扩展性，可以根据需要添加新的层次。

然而，分层架构也存在一些缺点，比如层次过多会增加开发复杂度和性能开销。

2.微服务架构微服务架构是一种将应用拆分为多个小型服务的架构模式。

每个服务都是一个独立的单元，有自己的数据库和业务逻辑。

它们之间通过轻量级的通信机制进行交互。

微服务架构的主要优点是松耦合、独立部署和可扩展性。

每个服务都可以独立开发、测试和部署，可以更灵活地响应变化和需求。

然而，微服务架构也增加了系统的复杂度，对运维人员的要求更高。

3.事件驱动架构事件驱动架构是一种基于事件和消息传递的架构，应用系统中的每个组件都是一个事件的消费者或生产者。

当事件发生时，系统会相应地作出反应。

事件驱动架构具有松耦合的特点，可以实现系统的高度可伸缩性和可扩展性。

同时，它也提供了更好的可维护性和灵活性。

然而，事件驱动架构也带来了一些挑战，比如事件的处理顺序、数据一致性和错误处理等问题。

4.MVC设计模式MVC（Model-View-Controller）设计模式是一种常见的架构模式，将应用系统划分为三个组件：模型、视图和控制器。