这是微服务架构系列文章的第 3 篇
高可用性、可扩展性、故障恢复能力和性能是微服务的特征。 您可以使用微服务架构模式来构建微服务应用程序，从而降低微服务失败的风险。
模式分为三层：
应用模式
应用程序模式解决了开发人员面临的问题，例如数据分解、数据维护、测试、用户界面和一些可观察性模式。
让我们回顾一下这些应用程序模式的基础知识。
分解模式
选择如何将单体系统分解为服务
- 按业务能力分解——服务是围绕业务能力组织的。
- 按子域分解——服务是围绕域驱动设计的子域组织的。
数据模式
- 数据一致性——每个服务使用一个单独的数据库以确保松散耦合。为了跨服务的数据一致性，必须使用 Saga 模式。
- 查询——每个服务使用数据库的另一个问题是某些查询需要连接来自多个服务的数据。不可能对服务的数据库执行分布式查询，因为它的数据只能通过其 API 访问。必须使用其中一种查询模式来检索分散在多个服务中的数据。
- API 组合——对一项或多项服务进行 API 调用并汇总结果。
- 命令查询职责分离 (CQRS) — 数据保存在一个或多个可以轻松查询的副本中。
测试模式
单个微服务更容易测试，因为它们比单体应用程序小得多。在测试不同服务是否协同工作时，重要的是要避免使用同时检查多个服务的复杂、缓慢和不稳定的端到端测试。
- 消费者驱动的合同测试——确保服务满足客户的期望。
- 消费者端合约测试——确保服务的客户端可以与之通信。
- 服务组件测试——隔离服务并对其进行测试。
用户界面模式
显示与不同服务相对应的数据及其显示方式是不同团队的责任。
- 服务器端页面片段组合——每个团队开发一个 Web 应用程序，为他们的服务实现的页面区域生成 HTML 片段。 UI 团队通过在服务器端聚合特定于服务的 HTML 片段来开发页面模板。
- 客户端 UI 组合——每个团队创建一个客户端 UI 组件，为他们的服务实现屏幕区域，例如 AngularJS 指令。通过组合多个特定于服务的 UI 组件，UI 团队实现页面骨架来构建屏幕。
可观察性模式
为了有效地运行应用程序，了解其运行时行为并解决请求失败等问题非常重要。
- 审计日志——审计日志记录每个用户的操作。审计活动日志通常用于协助客户支持、确保合规性和检测可疑活动。
- 应用程序指标——监控和警报是生产环境的关键组成部分。有一系列指标，例如 CPU、内存和磁盘的利用率，到服务请求的延迟和执行的请求数。指标由提供警报和可视化的指标服务收集。
应用基础架构模式
它们适用于也会影响开发的基础设施问题，例如通信、可观察性、可靠性和安全模式。
横切关注点模式
我们必须先了解关注点，才能理解横切关注点。关注点是基于其功能的系统的一部分。有两种担忧：
- 核心关注点——它代表主要需求的单一和特定功能，例如业务逻辑。
- 横切关注点——与次要需求相关的关注点。横切关注点是适用于整个应用程序的关注点，例如安全性和日志记录。
- 外部化配置——在运行时，它向服务提供配置属性值，例如数据库凭据和网络位置。
- 微服务底盘——微服务底盘是处理一系列问题的一个或一组框架，例如外部化配置、健康检查、应用程序指标、服务发现、断路器和分布式跟踪。您可以使用微服务机箱更有效地开发服务的业务逻辑。
- 服务模板——开发人员可以通过复制源代码模板快速开始开发新服务。顾名思义，模板是一个简单的可运行服务，它实现了构建逻辑和横切关注点以及示例应用程序逻辑。
通讯模式
基于微服务的应用程序是分布式系统。微服务架构严重依赖进程间通信（IPC）。
- 远程过程调用 (RPI) — 使用请求/回复协议发出服务请求。
- 特定于域的协议 - 对于服务间通信，例如使用 SMTP/IMAP 的电子邮件，或使用 RTMP/HLS/HDS 的媒体流，请使用特定于域的协议。
- 消息传递——使用异步消息传递进行服务间通信，例如 AMQP
可观察性模式
可观察性模式提供了对应用程序行为方式的洞察。诊断微服务架构的问题要困难得多。在最终将响应返回给客户端之前，请求可以在多个服务之间反弹。
- 日志聚合——将服务活动日志写入可以执行搜索和警报的集中式日志服务器。
- 异常跟踪——应将异常报告给异常跟踪服务，该服务对异常进行重复数据删除、警告开发人员并跟踪其解决方案。
- 健康检查 API — 提供一个返回服务健康状况的端点。
- 分布式跟踪——为每个外部请求提供一个 ID，并在请求在服务之间流动时对其进行跟踪。
可靠性模式
当服务不可用时，如何保证它们之间的可靠通信？
- 断路器——断路器可用于保护跨服务调用。当一定数量的下游资源请求未能达到一定阈值时，断路器会打开。如果断路器打开，系统将很快出现故障。一段时间后，客户端会发送一些请求来检查下游服务是否已经恢复。如果有正常响应，将在健康恢复后再次发送请求。
安全模式
用户通常由微服务架构中的 API 网关进行身份验证。然后必须将用户的身份和角色传递给它调用的服务。一个常见的解决方案是使用访问令牌模式。 API 网关将访问令牌（例如 JWT（JSON Web 令牌））传递给服务，服务可以验证令牌并获取有关用户的信息。
基础架构模式
它们解决了与开发之外的基础设施有关的问题，例如部署、发现和与外部 API 的通信模式。
部署模式
部署微服务有几种模式。传统上，服务以特定语言的方式打包。有两种现代部署方法。
- 虚拟机或容器——虚拟机或容器可用于部署服务。
- 无服务器部署——无服务器平台在您上传服务代码后执行它。自动化的自助服务平台是部署和管理服务的最佳方式。
发现模式
通常，服务需要相互通信。单体应用程序使用语言级方法或过程调用来调用其服务。传统上，分布式系统在固定的、众所周知的位置（主机和端口）运行，因此可以通过 HTTP/REST 或其他一些机制访问服务。然而，大多数基于微服务的现代应用程序都在虚拟化或容器化环境中运行，其中服务实例的数量及其位置会动态变化。
- 自注册——服务向服务注册中心注册自己
- 客户端发现——服务客户端从服务注册表中检索服务实例，然后在它们之间进行负载平衡。
- 3rd Party Registration — 第三方自动向服务注册中心注册服务实例。
- 服务器端发现——服务发现由路由器完成，路由器接收来自客户端的请求。
外部 API 模式
微服务提供的 API 粒度通常与客户端所需的不同。微服务提供的 API 通常是细粒度的，因此客户端必须与多个服务交互。每个客户端需要不同数量的数据，网络性能对每个客户端的影响也不同。
- API Gateway — API Gateway 实现了一项服务，该服务是从外部 API 客户端进入基于微服务的应用程序的入口点。它执行请求路由、API 组合和其他功能，例如身份验证、速率限制、缓存等。
- 前端的后端(BFF)——为每种类型的客户端创建一个单独的 API 网关。每个移动、浏览器和公共 API 团队都将拥有自己的网关，而 API 网关团队拥有公共层。
在以后的文章中，我们将详细介绍每种模式。
原文：https://medium.com/@learncsdesign/microservices-design-patterns-91fe56a…