关于不可变架构以及为什么需要不可变架构

2013 年 Chad Fowler 在博客中提出了“不可变架构”的概念。不可变架构（II）能够通过自动化和成功的编程模式为应用程序提供稳定性、高效性和保真度。虽然目前为止还不存在严格定义和标准化的不可变架构，但是基本的想法是使用不可变的编程概念来创建和操作你的架构：一旦实例化了一些东西，就永远不改变它。取而代之的是，你可以通过替换另一个实例来达到改变行为的目的。不可变架构需要你的运行时环境全面自动化。只有这样，计算环境才能拥有一个 API 来全方位地配置和监控它。因此，不可变架构只有在真正的云环境中才有可能完全实现。当然，也可以部分实现不可变架构来获取一些好处，但只有彻底地实现它才有可能获取真正的效率和弹性。

假设我们有一个应用。为了生产交付物，我们需要从源码编译。这就涉及了编译源码、处理和复制资源和其它的一些步骤。最终产生的可交付应用是：

单一不可变单元
编译一次并存储在仓库中
每次改变后通过持续集成系统重新生成

当然应用不会直接运行在硅或者钢铁之上，通常服务器会有 OS Kernel、Libraries、Runtime 和 App Server 这些层。即使是最简单的项目，应用都需要运行在多台机器上，它们被组织成不同的环境，例如开发环境、测试环境和生产环境等等。需要将相同的应用部署到不同的机器上。通常需要系统管理员确保所有的机器都处于相同的状态。接着所有的修改、补丁、升级需要在所有的机器中进行。随着时间的推移，很难再确保所有的机器处于相同的状态，同时越来越容易出错。这就是传统的可变架构中经常出现的问题。这是我们有了不可变架构，它将整个机器环境打包成一个单一的不可变单元，而不是传统方式仅仅打包应用。这个单元包含了之前所说的整个环境栈和应用所有的修改、补丁和升级，这就解决了前面的问题。

手工架构的缺陷

从历史上看，我们认为机器的正常运行和维护是可取的，因为所有的服务和应用都与它们的健康息息相关。在数据中心，由于硬件非常的昂贵，随着时间的推移，我们需要小心翼翼地维护每个单独的服务器来保护我们的投资。从云计算的概念考虑，这显然是一个过时的观点，我们应该放弃它以创造更具弹性、更简单和更安全的服务与应用。种种原因表明，传统长寿的由手工维持的基础设施已经不足以运行现代在云端的分布式服务：

增加操作复杂性。分布式服务体系结构的兴起以及使用了动态弹性导致了需要追踪监控更多东西。在成百数千个实例中使用可变的维护方法来更新和补丁配置是非常困难的，当然也是容易出错和需要耗费一定的时间。
部署慢，易出错。当基础设施是由来自可变维护方法（无论是通过脚本或配置管理工具）产生的雪花组件时，会有更过出错的可能。偏离了一个从源直接控制的过程，意味着准确地知道你的基础设施的状态是不可能的。由于基础设施以不可预测的方式在运行和时间浪费在了追逐配置漂移与调试运行时，保真度就丢失了。
识别错误和威胁，以减轻伤害。长时间运行和可变的系统依赖于识别出错误和威胁来防止损害。现在我们知道，近日高规格的公告和企业公布的损害都已经证明，这些是徒劳的。采用不可变架构和全自动重新生成计算资源，许多错误和威胁，不管是否能被检测到，都可以减轻他们的损害。
消防演习。手工基础设施允许我们以走捷径的方式来自动化，但它会以意想不到的方式来咬我们，例如当一个云提供商重启相关示例来进行更新或者打补丁。如果我们手动简历和维护我们的基础设施，而不是常规的不可变架构自动化，这些事件就会成为消防演习。

不可变架构的优点

不可变架构与自然界如可保持先进的生物系统有诸多相似之处。保真度在人体内的主要机制是恒定的破坏和更换子组件。它强调了免疫系统，它通过破坏细胞来维持健康。它强调了增长系统，它允许不同的子系统随着时间的推移通过破坏和更换而逐渐成熟。人类个体保持了自我和意图感，而底层组件都在不停更换。使用不可变架构的系统管理并没有什么不同。

如果你的应用能够恰当使用并且完全自动化部署和恢复方法，不可变架构带来的好处将会是多方面的：

简化操作。当使用完全自动化部署方式时，你可以使用新版本的组件替换掉旧的来确保你的系统永远保持在最初的良好状态。由于不需要追踪可变维护方法中出现的改变，维护成百上千个实例将会非常简单。
持续部署，极少失败。有了不可变架构，你能够准确知道什么正在运行和它将怎样表现，在生产环境部署升级将是常规的和持续的，同时极少会发生故障。所有的变化都是通过源码控制和持续集成过程追踪的。
减少错误和威胁。服务是建立在一个复杂的硬件和软件的堆栈之上，并且随着时间的推移，事情会出错。通过自动化替换，而不是维护实例，事实上我们将会常规地频繁重新生成实例。这就减少了配置漂移、脆弱性的表面和保持服务水平协议付出的努力水平。
云重启？没问题。有了不可变架构，你就能够知道正在运行的东西，同时你的服务也就拥有了自动恢复方法，云重启正在运行的实例将会在最小的关机时间下被小心处理。

我们必须非常努力地工作来保持一些东西，当这些东西是一个架子上的物理盒子，由于我们手动配置硬件，这是必要的工作。但通过逻辑隔离计算实例可以通过 API 调用在有效率的无限的云中实例化它们，“维护盒子”是智力的枷锁。它将我们的注意力和精力捆绑在错误的东西上。将你的注意力从他们身上移开就能够使你把重点放在你的应用程序的成功身上，而不是被高维护成本和采用新模式的难度不断地拉下来。

感谢郭蕾对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。