微服务与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中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。