DevOps

对 DevOps 工程师来说，微服务的设计就是在服务投入生产后如何管理服务。编写代码通常是很简单的，而保持代码运行却是困难的，因此应该基于以下 4 条原则开发微服务：

• 微服务应该是独立的。

  它还应该是可独立部署的，多个服务实例可以使用单个软件制品进行启动和拆卸。

• 微服务应该是可配置的。

  当服务实例启动时，它应该从中央位置读取需要配置其自身的数据，或者让它的配置信息作为环境变量传递。配置服务应该无须人为干预。

• 微服务实例需要对客户端透明。

  客户端不应该知道服务的确切位置。相反，微服务客户端应该与服务发现代理通信。这允许应用程序定位微服务的实例，而不必知道微服务的物理位置。

• 微服务应该传达它的健康信息。

  这是云架构的关键部分。一旦微服务实例无法正常运行，发现代理需要绕过不良服务实例。

这 4 条原则揭示了存在于微服务开发中的悖论。微服务在规模和范围上更小，但使用微服务会在应用程序中引入了更多的活动部件，因为微服务是分布式的，并且在它们自己的容器中彼此独立地运行。这引入了高度协调性，应用程序中更容易出现故障点。

从 DevOps 的角度来看，必须预先解决微服务的运维需求，并将这 4 条原则转化为每次构建和部署微服务到环境中时发生的一套标准的生命周期事件。这 4 条原则可以映射到以下运维生命周期步骤：

• 服务装配——如何打包和部署服务以保证可重复性和一致性，以便相同的服务代码和运行时被完全相同地部署。

• 服务引导——如何将应用程序和环境特定的配置代码与运行时代码分开，以便可以在任何环境中快速启动和部署微服务实例，而无须人为干预。

• 服务注册/发现——部署一个新的微服务实例时，如何让新的服务实例可以被其他应用程序客户端发现。

• 服务监控——在微服务环境中，由于高可用性需求，运行同一服务的多个实例非常常见。从 DevOps 的角度来看，需要监控微服务实例，并确保所有故障都围绕失败的服务实例进行路由，并且这些故障都已被记录。