微服务架构是_面向服务架构_结构风格的变体,它将应用程序分解为松散耦合的服务集合,使用API等通信机制相互交互。

微服务旨在提供可扩展性、去中心化、可用性、故障隔离、实时负载平衡等。

IDEALS 原则 包含了关键的基于微服务架构的原则。它包括一些 SOLID 原则。 IDEALS 代表_接口隔离:可部署性:事件驱动:可用性优于一致性:松散耦合:单一责任_

坚持这些原则带来了实施挑战,这些挑战在不同的设计模式的帮助下得以解决。

设计模式是针对软件设计中给定上下文中常见问题的可重用解决方案。这里的上下文是微服务架构。这些模式相互补充,以满足应用程序架构中的不同层和问题,如下图所示:

图片详情可以参考:docs.microsoft.com/microservices-design-patterns

一旦我们决定将我们的应用程序从单体架构重构为微服务,我们脑海中的第一个问题是:“那么,计划是什么,我们将如何去做?”,因为我们在 Prod 中有一个现有的功能业务应用程序以及多个新的要求一字排开。

一种方法是通过 Strangler Fig Pattern。扼杀者无花果,也称为扼杀者,以多种热带无花果(榕属,桑科)中的任何一种命名,因其在寄主树上的生长模式而命名,这通常会导致寄主死亡。

Strangler Fig 支持将遗留应用程序“增量重构”为新的(扼杀者)微服务应用程序,通过“稳定和频繁的发布”逐渐用新服务替换特定功能。

它由两种类型的服务组成。一是那些实现了以前存在于单体应用中的功能,这些功能会随着时间的推移而缩小。第二,实现新功能的服务。

重构的另一种模式是 Anti-Corruption Layer,它在新旧应用程序之间实现了一个_façade_,以确保新应用程序的设计不受对旧系统的依赖的限制。

我

接口隔离原则建议每个微服务接口满足客户程序的特定需求。换句话说,不应强迫客户端依赖于他们不使用的接口。

实现该原理的一种方法是通过 API 网关。

API网关通过帮助理解各种通信协议,根据需要翻译它们,修改请求和响应以适应服务和客户端程序等,解决基于微服务的应用程序中_如何访问单个服务_的问题。 API网关_充当所有客户端的单一入口点_并通过代理或路由到适当的服务或通过分散到多个服务来处理请求。

D

可部署性原则承认开发人员在打包、部署和运行微服务方面需要做出的关键设计决策和技术选择。

可部署性包括:

• 配置运行时基础设施,包括容器、Pod、集群、持久性、安全性和网络

• 微服务伸缩或运行时环境迁移

• 加快提交+构建+测试+部署过程

• 最小化停机时间

• 同步版本变更

• 监控微服务健康状况以识别和修复故障

每个服务都部署为一组服务实例,以提高吞吐量和可用性。

每个主机的单个服务和每个主机的多个服务模式是两种不同的部署策略,解决了打包和部署它们的方法。

单个主机服务将每个服务实例部署在自己的主机上。

这种模式提供_服务实例隔离_避免资源冲突并使监控和管理变得简单,但在资源利用率方面相对于每个主机多个服务而言效率较低。

每个主机多个服务 在共享主机上运行_多个不同服务的实例_。这可以通过将每个服务实例部署为一个 JVM 进程或通过在同一个 JVM 中部署多个服务实例来完成。

此单服务每主机模式有进一步的改进,如每虚拟机模式的服务实例和每容器模式的服务实例。

无服务器部署模式 是上述解决方案的替代解决方案。

E

事件驱动原则

使微服务容错的关键设计决策之一是避免由依赖服务的停机时间引起的级联故障。

事件驱动原则在这方面有所帮助,因为事件的生产者和消费者不是紧密耦合的。用于通信的消息传递通道使其两端保持独立,从而使它们保持松散耦合。这一原则提高了整个系统的可靠性、可扩展性和吞吐量。

Event Sourcing 是一种实现这一原则的设计模式,它有助于_可靠地、原子地更新数据库并发送消息/事件_。例如,参与 saga(如下所述)的服务需要自动更新数据库并发送消息/事件。类似地,发布域事件的服务必须以原子方式更新聚合并发布事件,这可以通过实现事件溯源来完成。

A

可用性优于一致性

CAP 定理本质上提供了两个选项:可用性或一致性,以及分区容差。

对于微服务,启用可用性选择的主要策略是_data replication_,可以通过Service Data Replication pattern、Command Query Responsibility Segregation (CQRS) pattern等来实现。CQRS将设计和实现分离从仅读取数据(查询)的操作更改数据(命令)的操作。

通过 Event Sourcing 模式(事件驱动架构)的消息复制通常适用于_Eventual Consistency_,保持可用性高于一致性。

L

松散耦合是一种耦合技术,用于_描述信息系统内相互连接但不依赖的组件的程度和意图_。与其他服务松散耦合 - 使团队能够在大部分时间独立地处理他们的服务,而不会受到其他服务更改的影响,也不会影响其他服务。

可以使用和组合几种策略来促进传入(传入)和传出(传出)松散耦合。 传入耦合衡量有多少其他服务使用特定服务作为传入,传出耦合衡量特定服务使用了多少不同的服务。

单一职责是允许对不太大或太瘦的微服务进行建模的想法,因为它们包含适量的“内聚功能”。

很少有促进松散耦合的设计模式是 Database per Microservice、Saga、API Gateway、BFF、Saga 等。

Backends for Frontends (BFF) 为不同类型的客户端(例如桌面和移动)创建单独的后端服务。这样,单个后端服务就不需要处理各种客户端类型的冲突需求。这种模式可以帮助_保持每个微服务简单,通过分离客户端特定的关注点_。

每个微服务的数据库 建议每个微服务的持久数据是该服务私有的,并且只能通过其 API 访问。服务的事务仅涉及其数据库。

在这里,紧密耦合是在数据库层处理的。

单独的数据存储并不意味着每个服务只有一个数据库,而是 Private-tables-per-service、Schema-per-service 或 Database-server-per-service,根据要求。

当我们实现每个微服务的数据库时,一些业务事务跨越多个服务,因此需要实现跨服务的事务,这是另一种称为 Saga Pattern 的模式。

Saga 是一个长期存在的事务,可以分解为事务,但仍作为一个单元执行,确保最终的一致性。

很少有其他与数据库相关的模式是 API Composition 和 Command Query Responsibility Segregation (CQRS) 模式,它们提供了_实现查询_的方法。

S

单一职责原则 (SRP) 是关于在 OO 类中具有内聚功能。单一职责的概念可以扩展到微服务中服务的内聚性。微服务架构风格规定部署单元应该只包含一个服务或几个内聚的服务。如果一个微服务充满了责任,也就是说,有太多不那么内聚的服务,那么它可能会承受单体的痛苦。

在这里,我们只看到了一堆设计模式,只有很少的微服务原则。这是一个更广泛的主题,可以满足各种领域、用例和挑战。

参考 :

microservices.io

martinfowler.com

docs.microsoft.com

wikipedia.org

cs.cornell.edu

lokajittikayatray.com

infoq.com

wikipedia.org

britannica.com

techopedia.com

stackoverflow.com

图片参考:

docs.microsoft.com