用罢即弃的微服务

最近， RedMonk 的 James Governor 写了一篇文章，作为他在 Dreamforce 上所做的关于微服务用后即弃的讲话的导言。正如 James 所说，他在最近的一次对话中有一个顿悟的时刻：

虽然经过改善的基础设施的用后即弃是采用容器的显著原因，但是这（用后即弃）对微服务实际上是具有决定意义的。

基本上，现在已经相当充分了解的对待基础设施的放牧牛群与豢养宠物两种方法的区别（由 Randy Bias 、 InfoQ 和其他人讨论的）能够并且应当应用于微服务。

用后即弃经过了很长一段时间的发展——我还记得当我第一次听到谷歌如何处理硬件故障时的惊讶——只需要不时丢弃掉出问题的机器，而不需要立即采取任何行动。在谷歌，这样的软件架构意味着硬件变得可以丢弃了。今天这样的架构思想（理想）正在成为云原生软件的核心设计原则。

不可变更的基础设施的方法正在越来越多地被采用，正是解决可处理性的关键方面。 Chad Fowler 在 2013 年当他的公司第一次改为采用不可变更时，把这看作是解决升级基础设施的很多问题的一种方法，就要表达这些：

需要升级？没问题。构建一个新的、升级了的系统，把旧的丢弃。新的应用程序升级？同样处理。构建一台含有新版本的服务器（或者映像），丢弃旧的。

尽管象 Mitchell Hashimoto 在我们 2014 年的虚拟专家讨论中所说的，不可变更不是包治百病的灵丹妙药：

这有好处，也有缺点。总而言之，我相信这是更有力的选择，是前进的正确道路，但是重要的是要明白这不是银弹，而且会引入之前没有的问题（在解决其它问题时）。

当前不可变更集中在基础设施的级别，James 相信该模式可用于堆栈中更高的层次。引用另一篇来自 Stephen O’Grady 的更早的 RedMonk 的文章，其中 Stephen 问道，将来什么是基础设施的最基本单元？

容器和 Docker 通常把操作系统及其下面的一切看作共享的基质，普遍的基础，不过是数据中心提升的平台。对容器而言，构造的基本单元是应用程序。这才是唯一真正独特的组成元素。

在过去几年其他人也做出了类似的判断，微服务应当是用罢即弃的，而不必把它等同于不可变更。例如，Kief Morris 在此前的一篇文章中表达了下面的观点，虽然不是专门针对微服务的，但是仍然是相关的：

随着软件的持续发布，只需一次性编译应用程序的特定版本为可部署的工件，你就知道在所有环境中部署和运行的是一致性构建的应用程序，这样做越来越可靠。使用不可变更的服务器，针对基础映像做每一项改动，然后你就知道从那个映像创建的所有实例都是一致的。

我们今年早些时候报导了 Salesforce’s Pat Helland 如何认为不可变更改变了微服务和其它许多事情：

许多种计算都是“只追加的”。观测一直（或很长时间）被记录。衍生的结果进行计算（或定期预先计算）。而且：胆小鬼才标准化。

所以尽管不可变更和微服务是别人思考和实施了一段时间的，James 提到的关于用罢即弃的顿悟仍然是相对较少讨论的话题。尽管象 Galen Gruman 和 Alan Morrison 所说，这当然是微服务和不可变更的基础设施符合逻辑的演变：

请把 MSA 想成应用内（in-app）的几乎即插即用的对本地和外部的分散的服务的整合。这些服务预料会改变，一些最终变成可以丢弃的。当服务关注的焦点较小时，开发、理解、管理和整合也都变得简单，它们只做必要的事，在不需要时就可以删除或者忽略。

James 这样总结：

所以微服务必须是用罢即弃的。如果一个微服务失效或者被更好的服务取代，那就简单地处理掉旧的。

也许‘必须’是过于强烈的说法了？也许这是其他微服务开发者已经发觉自己正在使用或者正在转向采用的模式。

查看英文原文： Disposable Microservices

感谢张龙对本文的审校。

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