我学到的 6 个设计技巧

断路器可以有以下三种状态：

1. 关闭：断路器将请求路由到微服务，并统计给定时段内的故障数量，如果超过阈值，它就会触发并进入打开状态。
2. 打开：来自微服务的请求会快速失败并返回异常。在超时后，断路器进入半开启状态。
3. 半开：只有有限数量的微服务请求被允许通过并进行调用。如果这些请求成功，断路器将进入闭合状态。如果任何请求失败，断路器则会进入开启状态。

优点

• 提高微服务架构的容错性和弹性
• 阻止引发其他微服务的级联故障

缺点

• 需要复杂的异常处理
• 日志和监控
• 应该支持人工复位

何时使用断路器

• 在微服务间使用同步通信的紧耦合的微服务架构中
• 如果微服务依赖多个其他微服务

何时不宜使用断路器

• 松耦合、事件驱动的微服务架构
• 如果微服务不依赖于其他微服务

可用技术示例

API 网关，服务网格，各种断路器库（Hystrix， Reselience4J， Polly）。

外部化配置

每个业务应用都有许多用于各种基础设施的配置参数（例如，数据库、网络、连接的服务地址、凭据、证书路径）。此外在企业应用程序通常部署在各种运行环境（Local、 Dev、 Prod）中，实现这些的一个方法是通过内部配置。这是一个致命糟糕实践，它会导致严重的安全风险，因为生产凭证很容易遭到破坏。此外，配置参数的任何更改都需要重新构建应用程序，这在在微服务架构中会更加严峻，因为我们可能拥有数百个服务。

更好的方法是将所有配置外部化，使得构建过程与运行环境分离，生产的配置文件只在运行时或通过环境变量使用，从而最小化了安全风险。

优点

• 生产配置不属于代码库，因而最小化了安全漏洞。
• 修改配置参数不需要重新构建应用程序。

缺点

• 我们需要选择一个支持外部化配置的框架。

何时使用外部化配置

• 任何重要的生产应用程序都必须使用外部化配置。

何时不宜使用外部化配置

• 在验证概念的开发中。

可用技术示例

几乎所有企业级的现代框架都支持外部化配置。

消费端驱动的契约测试

在微服务架构中，通常有许多有不同团队开发的微服务。这些微型服务协同工作来满足业务需求（例如，客户请求），并相互进行同步或异步通信。消费端微服务的集成测试具有挑战性，通常用 TestDouble 以获得更快、更低成本的测试运行。但是 TestDouble 通常并不能代表真正的微服务提供者，而且如果微服务提供者更改了它的 API 或 消息，那么 TestDouble 将无法确认这些。另一种选择是进行端到端测试，尽管它在生产之前是强制性的，但却是脆弱的、缓慢的、昂贵的且不能替代集成测试（Test Pyramid）。

在这方面消费端驱动的契约测试可以帮助我们。在这里，负责消费端微服务的团队针对特定的服务端微服务，编写一套包含了其请求和预期响应（同步）或消息（异步）的测试套件，这些测试套件称为显式的约定。对于微服务服务端，将其消费端所有约定的测试套件都添加到其自动化测试中。当特定服务端微服务的自动化测试执行时，它将一起运行自己的测试和约定的测试并进行验证。通过这种方式，契约测试可以自动的帮助维护微服务通信的完整性。

优点

• 如果提供程序意外更改 API 或消息，可以被快速的自动发现。
• 更少意外、更健壮，特别是包含大量微服务的企业应用程序。
• 改善团队自主性。

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!