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

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

1、抗脆弱软件

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

针对抗脆弱软件，重要的是要创建一种可预测性的意识，以便可以在高可扩展性基础上运行复杂的基础设施。确保您的软件在面对全部可能的失败状况时都具备健壮性是相当重要的。您不能期望您的基础设施是有容错性的。

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

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

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

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

4）避免竞争条件和协调启动顺序。一般，软件在足够简单的状况下，应该是能够单独启动的，而后再去寻求与其余组件聚合。现现在，许多应用程序都须要一个特定的启动顺序（例如，首先启动数据库，而后是应用服务器），而这并非必要的。在链接不可用的状况下，不要出错，不管如何都要启动，并尝试在备份超时的时候从新链接。

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

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

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

2、HealthZ

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

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

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

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

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

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

4、最小化依赖项

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

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

未经赞成，本文禁止转载或摘编。​​​​