微服务架构的横切关注点设计模式
image.png
作为一项服务，您必须实现各种横切关注点，例如指标、向异常跟踪器报告异常、日志记录、分布式跟踪、健康检查、外部化配置和安全性。此外，服务可能需要处理服务发现和实施断路器。每次添加新服务时编写代码从头开始设置它们是没有意义的。
通过在微服务机箱上构建服务，您可以更快地开发服务。微服务底盘将在下一节中进一步详细解释。
必须根据各种属性（例如数据库的网络位置、外部端点、消息队列和凭据）为不同的环境配置服务。
根据服务运行的环境，这些属性有不同的值。将特定环境的配置属性值硬连接到可部署服务中意味着必须为每个新环境重新构建它。相反，一个服务应该构建一次，然后通过部署管道部署到多个环境中。
将不同的配置设置硬连线到源代码中并使用它们也是不合逻辑的。同样，我们不应将凭证等敏感数据存储在配置属性中，而应存储在HashiCorp Vault或AWS Parameter store等秘密存储机制中。通过外部化配置模式，我们可以在运行时为服务提供适当的配置属性。
外化配置
在外部化配置机制中，配置属性值在运行时传递给服务实例。有两种主要方法：
- 推送模型 ——配置属性通过操作系统环境变量或配置文件传递给服务实例。
- 拉模型 - 配置属性由服务实例从配置服务器读取。
基于推送的外部化配置
推送模型依赖于部署环境和服务的协作。当部署环境创建服务实例时，它会提供配置属性。它可以将配置属性作为环境变量传递，或者部署环境可以通过配置文件提供属性。当服务实例启动时，会读取配置属性。
image.png
部署架构和服务就如何提供配置属性达成一致非常重要。
基于推送的外部化配置的缺点
- 运行服务可能难以重新配置，部署基础设施可能不允许您在不重新启动运行服务的情况下更改其外部化配置。
- 配置属性值有可能分散在众多服务的定义中。
由于这些缺点，您可能需要考虑使用基于拉的模型。
基于拉的外部化配置
作为拉取模型的一部分，服务实例从配置服务器读取其配置属性。当服务实例启动时，它会查询配置服务以获取其配置。用于访问配置服务器的配置属性，例如网络位置，通过基于推送的配置机制，例如环境变量，提供给服务实例。
image.png
配置服务器可以通过多种方式实现，包括：
- 版本控制系统，例如 Git
- SQL 和 NoSQL 数据库
- 专门的配置服务器，例如 Spring Cloud 配置服务器、存储敏感数据（如凭证）的 Hashicorp Vault 和 AWS 参数存储。
使用配置服务器有几个好处：
- 集中配置 ——配置属性都在一个地方，因此它们更易于管理。
- 敏感数据的透明解密 — 加密敏感数据（例如数据库凭据）是一种安全最佳实践。配置服务器实现在将属性返回给服务之前解密属性，否则，客户端需要知道密钥才能解密它们。
- 动态重新配置 ——使用轮询，服务可以检测更新的属性值并重新配置自己。
基于拉的外部化配置的缺点
- 配置服务器是另一个需要设置和维护的基础设施，除非它由基础设施提供。
有许多开源框架，例如Spring Cloud Config，可以更轻松地运行配置服务器。
微服务机箱模式
微服务底盘是一组解决许多横切关注点的框架，例如
- 外化配置
- 健康检查
- 应用程序指标
- 服务发现
- 断路器
- 分布式跟踪
- 异常跟踪
image.png
它显着减少了您必须编写的代码量。您可以配置微服务机箱以满足您的需求。您可以专注于使用微服务底盘开发服务的业务逻辑。
Spring Boot和Spring Cloud是微服务底盘框架的两个例子。使用 Spring Boot，您可以外部化配置，使用 Spring Cloud，您可以设置断路器。
微服务底盘模式的缺点
- 对于用于开发服务的每种语言/平台组合，您都需要一个微服务底盘框架。
服务网格模式
使用微服务机箱是实现各种横切关注点的好方法，但它的缺点是您需要为您使用的每种编程语言提供一个。
解决此问题的一种方法是在服务之外以所谓的服务网格实现其中的一些功能。服务网格是一种网络基础设施，可促进服务与其他服务和外部应用程序之间的通信。
服务网格实现了各种关注点，例如断路器、分布式跟踪、服务发现、负载平衡和基于规则的流量路由。
使用服务网格使微服务底盘更加简单。与应用程序代码紧密耦合的问题，例如外部化配置和健康检查，只需要在微服务机箱中实现。
image.png
服务网格的一些实现包括Istio、Linkerd和Consul。
服务网格使开发人员不必处理各种横切关注点。
