微服务与 SOA

过去的几年来，“微服务”这个术语逐渐得到关注，它描述的是由一系列更小的服务所组成的架构。在 QCon San Francisco 2012 上，Thoughworks 的 James Lewis 针对这个概念发表了演讲，同时还就这个话题与 Martin Fowler 合作撰写了一篇文章。最近，Steve Jones加入了讨论，他认为微服务并不是大家所认为的那样，是什么新东西，而只是SOA 的另一个叫法。为了证明这一点，他对微服务目前的定义和 OASIS SOA 参考模型进行了对比。他遵循了 James 和 Martin 在他们的文章中所列出的要点：

通过服务实现组件化：OASIS SOA 参考模型这样写到：

面向服务架构（Service Oriented Architecture，SOA）这个范型是用来组织和使用分布式能力（capability）的，这些能力可能由不同所有者的域来进行控制。

Steve 指出：

根据 OASIS 可以得出 WTF 实际上也是一种服务， - 为其他人执行任务的功能

• 为其他人提供的任务规范
• 能够为其他人执行任务

在 SOA 中，按照服务的机制，可以将需求和能力组织在一起。

在这个话题上，Steve 对比了 Martin/James 的说法：

服务是进程外的组件，它与组件明确的接口进行交互

围绕业务能力进行组织：这是 Steve 认为 Martin 产生误解的地方，并且相信微服务并不是新的东西。OASIS SOA 参考模型将能力（capability）定义为：

服务提供者所能够提供给服务消费者的一种真实的效果。

Steve 指出区分能力（谁做这项任务）与服务（组织化的结构）是非常重要的。

在过去的十多年间，我们在第一线实践 SOA，与 OASIS SOA RM 这些富有经验的人的共同发现就是 _ 组织化的框架（organising framework）_ 与行为本身是分离的。至关重要的原因就是人们在开始制定服务的时候通常将服务等同于能力（service = capability），这样最终你会有很多很多的服务（如果刻薄一点的话，我可能就会将其称之为微服务了）。

他认为尽管在这个话题上 Martin 的说法是可以的，但是并没有参考过去的重要材料。

这是新鲜的事物吗？我甚至编写过一本书来阐述如何围绕这种方式建模、管理和组建团队。 SOA Manifesto （2009）讨论了 SOA 背后的关键理念（尽管我还是更欣赏 RM），这是由大量的实践者做出的。这里有两个问题，第一就是混淆了服务与能力，第二是在管理方面没有充分识别层级（hierarchies）的重要性。

基于产品而不是项目（Products not Projects）：Steve 说在这个话题上 Martin 和 James 的文章比 SOA RM 介绍的更深入，但是依然没有什么新鲜的东西。

在 Google 上快速搜索一下就能看到在这个问题上已经有了很多的材料，有一些材料比其他的更好，也有一些更棒的产品，但是在这方面的确没有什么新鲜的。我曾经使用过这样一个术语“关注程序而不是项目（Programs not projects）”，并且经常会谈及将完整的生命周期分派给架构师，从而“使其更加具有责任感”。同样，这种说法完全没有错误，而是没有什么新意。多年以来我们就已经知道这会有所帮助，但是它有一个很明显的问题：成本。

智能端点与哑管道（Smart endpoints and dumb pipes）：Steve 完全同意这一原则，但他同样认为这并没有什么新意。他的说法略微有些不同：

在 OASIS SOA RM 中有一个“执行上下文（execution context）”的概念。这是服务被调用及其能力被触发的地方。显然，端点是“智能的”，因为它是用来完成工作的，因此上文中用到了“机制（mechanism）”这个词。“通道”可能是也可能不是哑的（我认为与火星上的漫游者进行对话“通道”是相当智能的），但它们是什么 并没有什么价值。这是在 SOA 中的一项重要发现，并且在 SOA RM 进行了很好的记录。执行上下文是所有内部任务完成的地方，但服务提供了访问能力的入口，能力是交付价值的所在。

去中心化的治理（Decentralized Governance）：在有些方面，Steve 同意 Martin 和 James 的观点，但是……

我认为这是一个好的建议，在管理方面，SOA 比微服务做的更好。正如 OASIS SOA RM 所述， SOA 允许将这些理念应用到所有的 IT 资产上，而不仅仅是根据特定风格实现的资产，事实上，仅仅考虑 IT 资产是商业课程上就讲授过的方式。

微服务与 SOA：在开始的时候，James 和 Martin 的文章似乎并没有参考 SOA（也许参考得不够，也许根本就忽略了）。最近，在与 Steve 进行了交流后，针对这一话题，文章添加了一个侧边栏（sidebar）。不过，Steve 认为这不仅是远远不够的，反而与事实毫不相干：

[…] 这并不是 SOA 的真正定义，而只是介绍了陈旧的“庞大的”ESB 以及 WS-* 术语，REST 拥护者（RESTafarians）在阐述他们的方式为何更好时惯用这样的手法。按照这篇文章的说法，它“清楚（crisply）”地描述了微服务的风格，因此在与 SOA 的对比方面也是有根据的，他们将 SOA 描述为“SOA 意味着太多的事情”。这一点上，我完全不能同意，首先如果能够阐述清楚如何适应非微服务的方式，那微服务可能更多的是一种实现，这一点上 SOA 已经做得很好了，其次，它没有解释什么能够使服务变得“微小（micro）”，服务可能是由规模恰当的团队（12 个人）制定的，也可能是单个人制定的。

最后，Steve 重复了他的观点，那就是微服务并不是什么新鲜的理念，仅仅是一种面向服务交付（Service Oriented Delivery）的方式。在他看来架构师和开发人员最好使用 SOA，因为它的定义更加完备并且现在已经取得了更多的经验。与其将微服务定义为什么新事物，还不如谈论一下“如今”的 SOA。Steve 这样说到：

另外，在文章的脚注中重点提及了 Netflix，实际上它所使用的词汇是“细粒度的 SOA”，另外一个案例（Amazon）讨论的也是 SOA 。

那么您的观点是什么呢？微服务仅仅是 SOA 呢，还是提供了一些根本上有所区别的东西呢？

查看英文原文： Microservices and SOA

感谢张龙对本文的审校。

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