六种常用的微服务架构设计模式 创建微服务模式的基本最佳实践（上篇）

​​在了解了六种常用的微服务架构设计模式，并从中选择了对组织最有意义的模式之后，您可能觉得这就足够了。但是，为了让整个体系正常运行，并且发挥微服务架构的功能，您的组织需要采用许多基本的最佳实践。本文将为您介绍这些最佳实践：

一、抗脆弱软件

抗脆弱软件系统通常含有多个主控数据源，但其架构通常不会寻求唯一真实数据源的存在，也不会使用特定的一致性模型。更改数据的方法通常有很多种，这些方法可能会产生级联影响，这些级联影响很难去理解或响应。

针对抗脆弱软件，重要的是要建立一种可预测性的意识，以便能够在高可扩展性基础上运行复杂的基础设施。确保您的软件在面对所有可能的失败情况时都具有健壮性是至关重要的。您不能指望您的基础设施是有容错性的。

这将导致微服务开发者朝着鼓励在广泛的系统故障面前不间断操作的实践前进。尽管“混沌工程”的概念（Netflix率先提出）已经存在了一段时间，但其关键的经验教训直到微服务的出现才被广泛采用。“抗脆弱性”是思维方式和具体实践的结合，其中一些关键的实践包括以下7点：

1）12-factor应用原则是有用的，但不应该过度使用。例如Pivotal Cloud Foundry企业级PaaS平台的体系结构最初就是基于这些原则构建的，但是在现实世界中，经历了无数的可能性，以致于最近在一些极其极端的方面松懈了。尽管如此，12-factor应用原则中的大多数还是适用于任何情况的（例如，将日志记录为事件流）。

2）使用智能默认值。如果配置文件或环境变量由于某种原因不可用，软件应该使用合理的默认值初始化为操作状态。

3）管理工作目录和临时文件。当应用程序试图写入不存在的目录或应用程序没有访问权限时，您必须修复多少次错误？如果应用程序需要访问给定的文件或目录时，请确保访问它的代码检查访问权限，并在需要时创建该文件。

4）避免竞争条件和协调启动顺序。通常，软件在足够简单的情况下，应该是可以单独启动的，然后再去寻求与其他组件聚合。现如今，许多应用程序都需要一个特定的启动顺序（例如，首先启动数据库，然后是应用服务器），而这并不是必要的。在连接不可用的情况下，不要出错，无论如何都要启动，并尝试在备份超时的时候重新连接。

5）使引导程序稳健。你可能从这些项目中感受到同一个目标。这个目标就是确保软件组件可以无错误地启动（无论运行时环境如何），并且随着时间的推移，寻求达到理想状态。这种方法的好处是广泛而明显的，但是基本的原则应该是，操作人员永远不需要了解软件的内部。

6）使用断路器。这是一种模式。在微服务部署中，断路器模式通常作为高性能进程间通信框架的一部分实现，如Hystrix或Finagle，这种模式可以检测故障并提供逻辑来防止故障再次发生。换句话说，该模式检测一个错误条件，并阻止组件尝试重试“注定出错”的操作，直到错误条件解决为止。

7）使用超时值。与使用智能默认值类似，任何外部通信都应该包含超时值。如果在端到端方案中涉及到许多服务，则必须考虑超时“预算”。例如，调用链中第三个调用的超时值不应该与第一个调用的超时值相同或者更长，否则，您会让组件在链条下游仍然在处理已经在边缘上终止的调用。

二、HealthZ

微服务的一个常见模式是“healthZ”，或者换句话说，应用提供一个健康状态检查的端点（Spring Boot中的/health，/healthz作为该模式的通用名称）。此检查应表明两件事：

1）这个应用程序认为它是健康的吗？（“是”返回：200，“否”返回：5xx）。

2）它认为目前的状态会带来什么？它将返回一组基本信息（例如JSON），这组信息描述其内部依赖项的当前状态。这些应该对操作员（而不是开发人员）是可读的，并且是不言而喻的，例如“数据库：正在连接”。

请注意，健康状态和正确的操作状态是不同的：在容器框架中，组件可以正常运行，但还没有“准备好”为流量提供服务（例如，数据库尚未连接），这是很常见的。HealthZ端点应该指出什么时候真的出了问题，而不是说有一个临时的操作点。

三、“无限”（线性）扩展

微服务模式非常注重可伸缩性，通常会使用术语“无限”扩展。当然，这并不意味着真正的无限扩展。相反，它是一个概念的简写，这个概念对如何使用一个给定的软件实现线性伸缩模型有一个清晰的理解。通常，这集中在扩展的硬限制上：数据存储和状态管理。对于微服务，这鼓励开发人员考虑他们正在使用的数据和存储模式，并寻找一种方法来执行支持高规模的任务。例如，高可扩展性的事务支持可以通过使用最终一致的集群存储来实现，而不是依赖于RDBMS（RDBMS，即关系数据库管理系统，Relational Database Management System）提供的事务边界。一般来说，这是一个很好的实践。虽然没有必要过度考虑这一点，但是确定存储层的用途并确保使用“最适合这项工作的工具”是有价值的。

四、最小化依赖项

当您频繁部署许多更改时，确保组件对外部系统的依赖性最小（例如，通过使用队列进行通信，而不是同步请求/响应模式），这一点很重要。虽然微服务模式使得这一点几乎是强制性的，但一般来说，使每个组件尽可能自给自足是有用的。同样，不要过度考虑这一点，但一个好的经验法则是尽量使部署的每个单元都尽可能独立。

未完待续，其余四个最佳实践将在下篇文章中进行分享，尽情关注。

未经同意，本文禁止转载或摘编。​​​​