优化架构设计的 10 个微服务最佳实践

Posted 2021-07-19 IT大咖说

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了优化架构设计的 10 个微服务最佳实践相关的知识，希望对你有一定的参考价值。

微服务从根本上改变了服务器端引擎的架构方式。微服务不是托管应用程序所有业务逻辑的单个巨大单体代码库，而是反映分布式系统模型，其中一组应用程序组件协同工作以交付业务需求。通过遵循十个基本的微服务最佳实践，您可以实现一个高效的微服务生态系统，避免不必要的架构复杂性。

◆ 微服务架构的好处

当从单体应用到微服务架构的迁移正确完成时，应该实现以下好处：

您应该能够使用您选择的语言开发微服务，按照自己的节奏独立发布，并独立扩展。
由于组织中的不同团队可以独立拥有某些微服务，因此上线时间应该更快，因为并行开发具有更多的重用性。
您可以获得更好的故障隔离，因为可以包含一个特定微服务中的错误，因此生态系统的其余部分不会受到影响。

但是，如果在构建微服务时没有遵循适当的原则，您最终可能会像这样纠缠不清。

这变得非常难以维护，因为它需要与多个团队进行大量协调才能进行更改、发布或实现容错。

充分利用微服务是一门科学，涉及一些学科。下面的微服务最佳实践和设计原则将帮助您构建松散耦合、分布式和优化以提供最佳价值的微服务。

◆ 10 个微服务最佳实践

1.单一职责原则

就像代码一样，一个类应该只有一个改变的理由，微服务也应该以类似的方式建模。构建可能因多个业务环境而发生变化的臃肿服务是一种不好的做法。

示例：假设您正在构建用于订购披萨的微服务。您可以考虑基于每个支持的功能构建以下组件，如 InventoryService、OrderService、PaymentsService、UserProfileService、
DeliveryNotificationService 等。InventoryService 将仅具有获取或更新比萨类型或配料库存的 API，同样其他人将携带 API因为它们的功能。

2. 为您的微服务拥有一个单独的数据存储

如果您使用所有微服务共享的单体数据库，它就会违背拥有微服务的目的。该数据库的任何更改或停机都会影响使用该数据库的所有微服务。为您的微服务需求选择合适的数据库，根据其维护的数据定制基础架构和存储，并让它专属于您的微服务。理想情况下，任何其他需要访问该数据的微服务只能通过具有写访问权限的微服务公开的 API 来访问它。

3.使用异步通信实现松耦合

为避免构建紧密耦合组件的网格，请考虑在微服务之间使用异步通信。

a: 异步调用您的依赖项，示例如下。

示例：假设您有一个调用服务 B 的服务 A。一旦服务 B 返回响应，服务 A 就会向调用者返回成功。如果调用者对服务 B 的输出不感兴趣，那么服务 A 可以异步调用服务 B 并立即成功响应调用者。

b: 更好的选择是使用事件在微服务之间进行通信。您的微服务将向消息总线发布一个事件，指示状态更改或失败，并且任何对该事件感兴趣的微服务都会接收并处理它。

示例：在上面的披萨订单系统中，可以使用异步通信在客户订单被提交后向客户发送通知，或者在订单完成和交付时发送状态消息。通知服务可以侦听订单已提交的事件并处理向客户发送的通知。

4.通过使用断路器实现容错快速失败

如果您的微服务依赖于另一个系统来提供响应，并且该系统需要很长时间才能响应，那么您的整体响应 SLA 将受到影响。为了避免这种情况并快速响应，您可以遵循的一个简单的微服务最佳实践是使用断路器使外部调用超时并返回默认响应或错误。断路器模式在以下参考资料中进行了解释。这将隔离您的服务所依赖的失败服务，而不会导致级联故障，使您的微服务保持良好的健康状态。您可以选择使用Netflix 开发的Hystrix等流行产品。这比使用 HTTP CONNECT_TIMEOUT 和 READ_TIMEOUT 设置更好，因为它不会启动超出配置的额外线程。

5. 通过 API 网关代理您的微服务请求

与系统中的每个微服务都执行 API 身份验证、请求/响应日志记录和限制功能不同，让 API 网关预先为您执行这些操作会增加很多价值。调用您的微服务的客户端将连接到 API 网关，而不是直接调用您的服务。这样，您将避免从您的微服务进行所有这些额外调用，并且您的服务的内部 URL 将被隐藏，让您可以灵活地将流量从 API 网关重定向到您的服务的更新版本。当第三方访问您的服务时，这更加必要，因为您可以限制传入流量并在来自 API 网关的未授权请求到达您的微服务之前拒绝它们。

6. 确保您的 API 更改向后兼容

只要不破坏现有调用者，您就可以安全地对 API 进行更改并快速发布它们。一种可能的选择是通知您的调用者，让他们通过集成测试为您的更改提供一个签名。但是，这很昂贵，因为所有依赖项都需要在环境中排列，并且会因大量协调而减慢您的速度。更好的选择是对您的 API 进行契约测试（contract testing）。您的 API 的使用者提供关于他们对您的 API 的预期响应的契约。作为提供者，您将这些契约测试集成为您的构建的一部分，这些将防止破坏性更改。使用者可以针对您作为使用者构建的一部分发布的存根进行测试。通过这种方式，您可以通过独立测试契约更改更快地投入生产。

7. 为您的微服务版本进行重大更改

并非总是可以进行向后兼容的更改。当您进行重大更改时，请公开端点的新版本，同时继续支持旧版本。消费者可以在方便时选择使用新版本。然而，拥有太多版本的 API 会给维护代码的人带来噩梦。因此，通过与您的客户合作或在内部将流量重新路由到较新版本，采用一种循序替换的方法来弃用旧版本。

8. 拥有托管微服务的专用基础设施

你可以让设计最好的微服务满足所有的检查，但是如果托管平台的设计不好，它的表现仍然很差。将您的微服务基础架构与其他组件隔离，以获得故障隔离和最佳性能。隔离微服务所依赖的组件的基础设施也很重要。

示例：在上面的披萨订单示例中，假设库存微服务使用库存数据库。不仅库存服务拥有专用主机很重要，库存数据库也需要拥有专用主机。

9.创建一个单独的发布系列

您的微服务需要有自己独立的发布工具，该工具不与组织内的其他组件绑定。这样您就不会互相踩踏，也不会浪费时间与多个团队协调。

10. 创造组织效率

虽然微服务为您提供了独立开发和发布的自由，但对于横切关注点需要遵循某些标准，这样每个团队就不会花时间为这些问题创建独特的解决方案。这在分布式架构（例如微服务）中非常重要，您需要能够连接拼图的所有部分以查看整体图。因此，企业解决方案对于 API 安全、日志聚合、监控、API 文档、机密管理、配置管理、分布式跟踪等都是必要的。