转载

Adrian Cockcroft重新审视微服务

2014年八月，在由思科所举办的一场聚会活动中，Adrian Cockcroft为参与者进行了一场关于微服务的演讲。来自于ActiveState的John Wetherill当时也出席了活动，他随后对Adrian就微服务这一主题进行了采访，并根据采访内容在他自己的博客上撰写了一系列帖子。John之后将这段采访内容发布到网上，以下的内容是此次采访中的某些亮点。

John的第一个问题是有关于使用多语言进行开发的，虽然人们都认可这一点对于微服务的重要性，但John从来没有在实际应用中看到实例。

举例来说，Twitter的微服务大部分是由Scala创建的，Hail-O（欧洲的Uber）完全使用Go，而Seneca的微服务框架都是JavaScript编写的。Pivotal宣称Java与Spring是“用于微服务的语言”，而就我所知，Netflix也将Java作为了标准，用于它的Java绑定功能。

因此，John想知道的是，在开发微服务时，是使用多语言的方式更理想，还是专门使用一种单一的语言进行开发更合适？

Adrian首先指出，Netflix实际上就是一个多语言开发的环境，其中有一部分功能是使用Python实现的。那么他们是怎样做到在自己的平台上支持多语言的呢？

……为了支持多语言开发，Netflix进行了一系列的工作。他们开源了一个通用的“边车”（sidecar）进程，称为Prana，它将与平台进行交互。他们还为Memcached（一个c应用程序）、 Elasticsearch 和 Cassandra 创建了自定义的边车，它们将与系统进行聊天式交互，并从它们所监控的所有部分获取数据，并将数据附加到标准的监控工具中。

接下来Adrian谈到了使用多语言开发的原因，这种方式并不仅仅在Netflix中使用，这一点本质上可归结为许多公司中都存在着多种语言的开发并存的这一现实。核心服务或许会使用一种单一的主要语言，而其它语言的存在则出于特定于领域的原因，或许它们能够更好地处理某些当前所遇到的问题。

上周我在进行演讲时，参与的小组成员中有一部分是开发Ruby的，但多数都是开发Node的，而其中也有一部分人使用Java。因此这些开发者们并非来自于统一的语言背景，但要实现这种统一的难度是相当大的，与之相比，人们反而更容易接受维护由多种语言开发的服务。

John的下一个问题是，如果某些公司不具备必须的资源，或是没有得到管理层的支持，那么他们将如何引入微服务，以实现Netflix那样的成果？

Adrian在回答这个问题时首先表示，他也认识到即使在Netflix，事情也并非一蹴而就。而且在当时还不存在任何定义良好的模式或模板可供他们参考：

……我们在2008年时开始着手这一改变，我们阅读了由Google和Amazon所发布的各种核心的白皮书，并且吸收了我们之前所学到的知识。我们最终实现了目标，当然，团队中加入了许多非常有经验的、非常聪明的成员，其中有一部分人的年龄都已经超过50岁了，我们的年龄差不太多。这个系统并不是由一群年青人创建的，我们也不认为自己是世界上最先完成这个工程的人。

在过去7年间，整个IT界发生了很大的变化，许多公司都实施了云端部署与DevOps。公有与私有的平台即服务系统不再是新鲜的概念了，并且各公司能够在各种不同的实现中选择最适合他们的系统。Netflix当初所遇到的各种挑战在2008年或许还是非常复杂的，但如今已经变得不那么复杂了，而许多其他组织与公司也遇到了同样的挑战，并将他们的经验分享给业界。

我还发现了一个现象，即许多传统的大公司都开始了对微服务的探索，并且在深度上远远超出我的想象。请你们看看 DevOps Enterprise会议上的这些视频，这个会议让我异常兴奋。……Nordstrom走上了讲台，宣布“我们已经成功地对速度进行了优化，并且没有额外的成本”。美国国土安全部则谈到了他们在处理绿卡系统的生产环境中如何使用Chaos Monkey（Netflix的一套测试系统）的故事。请注意，我们现在谈论的是你的绿卡申请，美国政府的移民部门在他们的生产环境上运行Chaos Monkey！听到这里时我差点从椅子上摔下去。

Adrian接下来还谈到了其它公司，例如Target和Macy’s，这些公司也谈到了他们在使用微服务方面的经验，以及他们如何启动微服务架构的故事。总的来说，他们希望能够发展得更快，然后他们听说了DevOps这回事，然后有人买了一本Gene Kim所编著的《凤凰项目》（Target买了23本）。他们随后在一些小型项目中进行了一番尝试，看这些技术能够起到作用。

他们对新系统进行了评估，并观察它们的情况，最后他们发现，原本他们要进行一次产品发布，通常要一个季度或六个月时间，而现在他们能够做到一个季度发布上百次。他们的发布频率上升了两个数量级，这也意味着在同一段时间内能够发布的内容比起之前增长了上百倍。这种方式之所以有效，是因为这些工作单元非常小、易于理解、并且易于回滚。在生产环境中发现的问题以及停机现象则比之前少了一个数量级。

正如Adrian所提到的一样，对于Target和Macy's来说，接下来的一个问题在于：它的成本有多高？由于这些公司并没有花费太多成本去创建他们所不需要的东西，也没有购置了大量的机器并让它们在大多数时间中处于闲置状态，因此Adrian在总结中表示，他们所耗费的成本大约是之前的一半。

使用微服务，你可以用同样数量或更少的人完成更多的内容，客户对你交付的产品满意度更高，并且你的发展速度通常会比你之前的团队更高。因此你能够更快地完成工作、完成工作所用的人日也更少，效率也得到了提高，能够更快地推出新功能并让它良好地运行。整个系统变得更加高效，并且减少了资源浪费，这一点也是敏捷的原则所在。

我们将继续关注该采访的下一部分内容，等到下一部分发布之后，我们也会在文章中继续进行总结。

查看英文原文： Adrian Cockcroft: Microservices Revisited

正文到此结束