微服务设计模式是一种领导微服务架构设计和开发的一系列准则和实际。微服务设计模式的目标是为了解决微服务架构中遇到的一些常见的问题和挑战，比方服务划分、服务通信、服务治理、服务测试等。微服务设计模式能够帮忙咱们构建出高效、牢靠、可扩大、可保护的微服务零碎。
本文将介绍以下十种微服务设计模式：
- API 网关（Api Gateway Pattern）
- 服务发现与注册（Service Registration and Discovery Pattern）
- 断路器（Circuit Breaker Pattern）
- 隔板模式（Bulkhead Pattern）
- 命令和查问职责拆散（CQRS Pattern）
- 事件驱动模式 (Dvent Driven Pattern)
- Saga 模式 (Saga Pattern)
- 扼杀者模式（Strangler Pattern）
- 边车模式（Sidecar Pattern）
- BFF 模式（Backend for Frontend Pattern）
1. API 网关
API 网关是拜访任何微服务的入口点，位于客户端和微服务之间，负责解决诸如鉴权、限流、重试、负载平衡、服务发现等通用性能，以及依据客户端的需要进行数据过滤、映射和聚合等操作。这种模式能够简化客户端的逻辑，缩小网络开销，爱护后端服务，以及实现不同级别的 API 接口。在 Spring Cloud 中咱们能够应用 Zuul 或 Spring Cloud Gateway 来实现这一点。
利用场景
- 对于任何微服务调用 API 网关是惟一入口，简化客户端逻辑。
- 能够依据不同的规定将申请路由到不同的微服务上。
- 能够与 Eureka、Nacos、Ribbon 等注册核心集成，实现服务发现和负载平衡。
- 能够聚合后端的申请后果再发送给前端。
- 能够在不同通信协议的服务之间做协定转换。
- 能够把受权 / 认证性能从微服务中迁徙到 API 网关上。
- 能够记录申请日志。
- 能够做服务限流以及服务熔断。
2. 服务注册与发现
服务注册与发现是一种用于治理微服务实例地址变动的技术。它能够让微服务之间通过一个对立的服务名来进行通信，而不须要晓得对方的具体位置。它次要包含两个组件：服务注册核心和服务发现客户端。
- 服务注册核心：服务注册核心是一个中心化的组件，负责存储所有微服务实例的地位信息（如 IP 地址和端口号），以及提供查问和更新这些信息的接口。每个微服务实例在启动时都会向服务注册核心注册本人的地位信息，并定期发送心跳音讯来维持本人的在线状态。如果某个微服务实例进行或下线了，它会从服务注册核心登记本人的地位信息，或者由服务注册核心检测到并删除它。
- 服务发现客户端：服务发现客户端是一个分布式的组件，负责从服务注册核心获取所需微服务实例的地位信息，并依据负载平衡策略抉择一个适合的实例进行调用。每个客户端或其余微服务在须要调用某个微服务时都会应用其服务名来申请服务发现客户端，由服务发现客户端返回一个可用的实例地址，并建设连贯。
引入服务注册与发现能够给微服务架构带来很多益处，例如，
- 动静发现：咱们能够动静地发现新退出或退出的微服务实例，而不须要手动配置或批改地址信息。
- 负载平衡：咱们能够依据不同的算法（如轮询、随机、起码连贯等）来抉择最合适的微服务实例来解决申请，从而进步零碎的性能和效率。
- 容错解决：咱们能够检测并排除不可用或故障的微服务实例，从而进步零碎的可靠性和稳定性。
常见的服务注册核心如下，
- Eureka：Eureka 是 Netflix 开源的一款服务发现组件，是 Spring Cloud 老版本的外围组件之一，当初曾经处于保护期。它提供了服务注册、服务发现和负载平衡等性能，具备高可用、高牢靠、易于扩大的特点。实用于须要高可用、易于部署和保护的微服务架构。
- Consul：Consul 是由 HashiCorp 开源的一款服务网格解决方案，提供了服务注册、服务发现和健康检查等性能，同时还反对多数据中心部署和分布式一致性协定。实用于须要多数据中心部署和强一致性的微服务架构。
- Zookeeper：Zookeeper 是 Apache 开源的一款分布式协调服务，提供了命名服务、配置管理、分布式锁等性能。Zookeeper 具备高可用、高牢靠、反对集群和多数据中心等特点。实用于须要分布式锁、分布式配置管理等性能的微服务架构。
- Nacos：Nacos 是阿里巴巴开源的一款动静服务发现、配置管理和服务治理平台，反对 DNS-based 和 RPC-based 两种模式。Nacos 具备简略易用、高性能、高可扩大等特点。实用于须要动静配置管理和服务治理的微服务架构。
- Etcd：Etcd 是一个分布式键值存储系统，基于 Raft 协定实现了强一致性和容错性。Etcd 能够作为服务注册核心应用，也能够作为配置核心或分布式锁等其余场景应用。实用于须要强一致性和高性能的微服务架构。
3. 断路器
断路器是一种解决近程调用失败或超时的模式。因为微服务之间须要通过网络进行通信，因而可能会遇到网络故障、超时、拥塞等问题，导致近程调用失败或提早。如果不及时处理这些问题，可能会造成雪崩效应（Cascading Failure），即一个失败的调用会引起其余调用的失败，最终导致整个零碎解体。电路断路器模式能够防止这种状况，它相似于电路中的保险丝，当检测到某个近程调用呈现故障时，就会切断该调用，避免进一步的侵害，并尝试复原该调用。在 Spring Cloud 中，咱们能够应用 Hystrix 或 Resilient4J 来实现断路器。
断路器模式通常有三种状态：闭合（Closed）、关上（Open）和半开（Half-Open）。闭合状态示意近程调用失常工作，关上状态示意近程调用呈现故障，半开状态示意近程调用正在复原。电路断路器依据肯定的条件和策略来切换这三种状态，比方故障次数、故障比例、故障工夫等。电路断路器还能够提供一些备选计划来解决失败的调用，比方重试、降级、缓存等。
断路器行为相似于电路中的断路器。当间断的申请失败的次数超过阈值时，断路器将跳闸一段时间，并且在跳闸的这段时间内，所有近程服务调用的尝试都将立刻失败。当超过了断路器跳闸工夫之后，断路器将容许无限数量的测试申请通过。如果这些申请胜利，则断路器将恢复正常操作。否则如果有一个申请失败，则断路器再次跳闸。对于一个利用试图尝试调用另一个近程服务或者获取共享资源，并且该操作很容易的失败的状况来说，这个模式十分实用。
3. 隔板模式
隔板模式（Bulkhead Pattern）通过依据须要调用的服务数量划分线程池，帮忙解决与线程池相干的容错问题。例如咱们在服务 A 中定义了一个 50 线程池，服务 A 会向服务 B 和 C 发出请求。因而服务 A 应该将 50 线程池分为 2 个（服务 B 25 个，服务 C 25 个），如果服务 C 不可用或须要较长时间来解决申请，则不会影响服务 B 调用，因为它有本人的线程池来执行作业。在 Spring Cloud 中，咱们能够应用 Resilient4J 来实现这一点。
隔板模式相似于船体中一个个被隔离的分区。依据使用者负载和可用性要求，这些分区服务实例被宰割到不同的组外面。这种设计模式有助于隔离故障（isolate failures），并容许即便在故障期间仍可为某些使用者提供服务性能。
5. 命令和查问职责拆散
命令和查问职责拆散（Command Query Responsibility Segregation，CQRS）模式，是一种将数据存储的读取操作和更新操作拆散的模式。这种模式的目标是进步微服务的性能、可扩展性和安全性。CQRS 的根本思维是，对于不同的操作，能够应用不同的模型、服务和数据库。例如，读取操作能够应用一个优化了查问效率的数据库，而更新操作能够应用一个保障了数据一致性的数据库。这样就能够依据不同的需要来抉择适合的技术和架构。
长处
- 能够依据读写比例来调整资源分配，进步零碎的效率和响应速度。
- 能够针对不同的场景应用不同的数据模型和验证规定，进步零碎的灵活性和可维护性。
- 能够升高数据抵触和并发问题的危险，进步零碎的可靠性和安全性。
毛病
- 须要保护多个数据源之间的同步和一致性，减少了零碎的复杂度和开发成本。
- 须要解决数据提早和最终一致性的问题，可能影响用户体验和业务逻辑。
6. 事件驱动模式
微服务中的事件驱动模式是一种让微服务之间通过公布和订阅事件来进行异步通信的模式。事件是一种示意零碎中产生了某种变动或动作的音讯，比方订单创立、领取实现、用户注册等。事件驱动模式的长处是能够升高微服务之间的耦合度，进步零碎的可扩展性、性能和可靠性，以及反对简单的业务逻辑和流程。事件驱动模式的挑战是须要保障事件的程序、一致性、幂等性和可追溯性，以及解决分布式事务和异常情况。事件驱动模式中的事件个别是通过音讯队列收回，例如 RabbitMQ 或 Apache Kafka。
事件驱动模式让微服务之间通过公布和订阅事件来进行异步通信，而不是间接调用或依赖其余微服务的接口。这样每个微服务只须要关注本人的业务逻辑，而不须要晓得其余微服务的存在和状态。
7. Saga 模式
家喻户晓，解决分布式系统很艰难，尤其是波及分布式事务时，二阶段提交是最好的抉择，但因为其乐观锁的性质使其难以扩大、性能较低，所以就有了 Saga 模式，是一种在分布式事务场景中跨微服务治理数据一致性的办法。Saga 是一系列事务，用于更新每项服务并公布音讯或事件来触发下一个事务步骤。如果某个步骤失败，则 Saga 将执行弥补事务，以对消上一个事务的影响。这种模式能够保证数据的最终一致性，同时防止了长时间锁定资源的问题。有两种常见的 Saga 实现办法，即协调和编排。每个办法都有本人的一组挑战和技术来协调工作流。
协调
协调是协调 Saga 的一种办法，参与者在没有集中控制点的状况下替换事件。通过协调，每个本地事务都会公布在其余服务中触发本地事务的域事件。。
益处
- 实用于只需很少参与者且不须要协调逻辑的简略工作流。
- 不须要额定的服务实现和保护。
- 不会引入繁多故障点，因为责任在各个 Saga 参与者之间进行调配。
毛病
- 增加新步骤时，工作流可能会变得凌乱，因为很难跟踪哪些 Saga 参与者侦听哪些命令。
- 因为 Saga 参与者必须应用彼此的命令，因而他们之间存在循环依赖的危险。
- 集成测试很艰难，因为必须运行所有服务能力模仿事务。
编排
编排是协调 Saga 的一种办法，在此办法中，地方控制器通知 Saga 参与者要执行的本地事务。Saga 编排器解决所有事务，并告知参与者依据事件执行哪项操作。编排器执行 Saga 申请、存储和解释每个工作的状态，并通过弥补事务处理故障复原。
益处
- 实用于只需很少参与者且不须要协调逻辑的简略工作流。
- 不须要额定的服务实现和保护。
- 不会引入繁多故障点，因为责任在各个 Saga 参与者之间进行调配。
毛病
- 增加新步骤时，工作流可能会变得凌乱，因为很难跟踪哪些 Saga 参与者侦听哪些命令。
- 因为 Saga 参与者必须应用彼此的命令，因而他们之间存在循环依赖的危险。
- 集成测试很艰难，因为必须运行所有服务能力模仿事务。
8. 扼杀者模式
扼杀者（Strangler Pattern）模式是一种将单体利用逐步迁徙到微服务架构的模式，它的灵感来源于一种缠绕并杀死它所附丽的树木的藤蔓动物。扼杀者模式的根本思维是，通过创立单体利用的新版原本替换旧版本，同时放弃内部 API 不变，让客户端感知不到任何变动。随着转换进度的推动，最终所有性能都被重构为微服务，新架构“扼杀”取代了原来的单体架构。
扼杀利用（Strangler Application）的步骤分为转换，共存和毁灭三步：
- 转换（Transform）— 用新形式创立一个新的平行的服务。
- 共存（Coexist）— 放弃老服务，将老服务申请重定向到新服务，新服务逐渐实现老服务的性能。
- 毁灭（Eliminate）— 移除老服务。
扼杀者模式的长处是能够渐进地进行微服务化，而不是一次性地重写整个利用，这样能够升高危险和老本，同时放弃业务的连续性和稳定性。毛病是须要保护两套零碎之间的兼容性和同步性，这可能会减少零碎的复杂度和开发成本。
9. 边车模式
边车模式（Sidecar Pattern）是一种将一些与业务逻辑无关的性能（如日志、监控、配置、平安等）从主应用程序中分离出来，部署在同一个主机或容器中的一个独立的过程或服务中的模式。这样，主应用程序能够专一于本人的外围性能，而边车服务能够提供一些通用的性能，比方数据转换、网络通信、故障解决等。边车服务与主应用程序之间通过本地接口或共享内存来进行通信，从而实现高效和通明的合作。
边车模式的长处是能够升高微服务之间的耦合度，进步微服务的性能、可靠性和灵活性，以及简化微服务的开发和保护。毛病是须要额定的资源和治理老本，以及解决边车与主应用程序之间的通信和协调问题。
10. BFF 模式
BFF 模式是一种为前端定制的后端的模式，它的全称是 Backend for Frontend。BFF 模式的目标是将后端的微服务依据不同的前端渠道和场景进行适配和聚合，提供给前端敌对和对立的 API，从而晋升前端的用户体验和开发效率。BFF 模式能够让前端与后端之间实现更好地解耦和合作。
BFF 模式的长处是能够依据不同的前端需要来定制和优化 API，防止了适度形象或者冗余的 API，进步了网络传输和数据处理的效率。毛病是须要额定的开发和保护老本，每个前端渠道都须要一个对应的 BFF，可能会导致代码反复或者不统一。
利用场景
- 接口剪裁：后端提供的一个接口，对于不同的前端场景来说，需要的字段可能会不同。BFF 的剪裁能力使得后端只须要专一畛域开发，不须要为前端定制不同的 API 接口，不便 API 生命周期的治理。
- 接口聚合：一个前端页面，往往会依赖多个后端接口，这样就须要和后端产生屡次交互。BFF 能够对后端接口进行聚合，并解决依赖关系，使得前端一个页面只须要和后端交互一次。
总结
以上的十种设计模式能帮忙咱们构建扩展性良好的软件系统，然而在生产实践中，咱们还须要依据具体的业务场景和需要来引入适合的微服务设计模式。
最初感激大家浏览，心愿本文能对你有所帮忙.
关注公众号【waynblog】每周分享技术干货、开源我的项目、实战经验、高效开发工具等，您的关注将是我的更新能源！