不可变工件封装了尽可能多的服务依赖项，这使得开发者可以最大限度地确信，在整个部署流水线中，测试所使用的包与部署到生产环境中的是一样的。不可变性还使得开发者可以将服务实例视为一次性用品——如果服务出现问题，开发者可以轻松地用一个具有最新状态的正常新实例替换它。在GCE上，这个自愈过程是由开发者所创建的实例组自动完成的。
如果相同代码构建出的是不同的工件——比如，拉取了不同版本的依赖项——那么开发者在部署阶段就会面临更大的风险，而且代码的脆弱性也会增大，因为无意的变更会包含在版本中。不可变性提高了系统的可预测性，因为开发者更易于理解系统的状态和重建应用的历史状态——这对于回滚操作是至关重要的。
不可变性不仅是面向服务工件的，同时还是高效管理虚拟服务器的重要原则。
一种管理服务器状态的方式是随着时间的推移采用累积性修改——安装补丁、升级软件及修改配置。这通常意味着没有地方定义服务器当前的理想状态——也就没有已知的正确状态用于搭建一套新的服务器。这种方法还鼓励对服务器进行线上现场修复，但这却增大了出现故障的风险。这些服务都在遭受配置漂移之苦。
如果每台服务器主机都是稀缺资源，那么这种方式也许还说得通。但在云环境中，每台主机的运行成本和替换成本都是非常低的，因此不可变性是更好的选择。开发者应该使用具有版本控制的基础模板来构建主机，而不是管理主机。开发者应该使用以新版本为基础模板构建的主机来替换掉老的主机，而不是对这些主机进行更新。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论