转载

用罢即弃的微服务

最近， 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读者交流群用罢即弃的微服务）。

正文到此结束

所属分类：编程技术

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。