微服务从SOA中汲取的5个教训(译文)

（声明：本文为译文，只供学习和交流使用。因为水平有限，只要到达意会便好，如果感兴趣，建议还是看英文原版，会有更多启示，原文地址： https://www.infoworld.com/article/3080611/application-development/learning-from-soa-5-lessons-for-the-microservices-era.html。之前一直纠结于SOA和微服务的异同，也看了很多文章却不得要领，读了本文之后有一种豁然开朗的感觉，所以分享出来）

SOA的兴衰历史可以教给我们很多关于如何充分利用微服务的启迪

正如我在前一篇文章中提到的，“微服务体系结构是敏捷软件体系结构”(http://www.infoworld.com/article/3075880/application-development/microservice-architecture-is-agile-software-architecture.html)，我最初对微服务体系架构的反应是质疑其与面向服务的体系架构（SOA）有何不同。我不是唯一一个把这两种架构风格联系起来的人。在James Lewis和Martin Fowler的博客文章中，有一个专栏对微服务和SOA进行了对比。对此，持怀疑态度的人声称二者没有差别。事实上，有影响力的微服务采纳者Amazon和NETFLIX都把它们的体系结构称为面向服务的术语，然后才发明了“微服务”。两年多之后，关于微服务架构是SOA还是非SOA的争论产生了大量的文章。

为什么人们如此热衷于比较微服务和SOA，为什么会有这么多激情？虽然微服务和SOA可以在许多层面上区别开来——架构风格、实现实例、相关技术——但在技术领域中，它们扮演的角色却惊人的相似。两人都承诺要转型，他们成功地吸引了追随者，并且由他们吸引了更多的追随者。简而言之，虽然微服务和SOA都是从架构开始的，但它们最终变成了一场运动。

呜呼哀哉，时至今日SOA通常被看作是企业IT中的一个失败的运动，对于许多投资它的人来说，创伤仍然在隐隐作疼。这就是人们对微服务与SOA的比较产生浓厚兴趣的原因。人们在微服务领域看到了SOA类似的承诺，他们也担心类似的失望。为了理解微服务与SOA争论的背景，重要的是回顾SOA运动的历史：什么推动了它的发展，什么最终导致了它的偏离轨道。

SOA的兴衰

在1996年，Gartner的分析师Roy Schulte对面向服务的体系架构定义如下：

面向服务的体系架构是一种多层次计算风格，帮助组织在过个应用程序和使用模式中分享逻辑和数据。

尽管有了这种早期的定义，直到2002年，帮随着Web服务的出现SOA才在业界得以普及。虽然SOAP/XMLWeb服务最初是为了在不同的组织之间进行服务器-服务器间的网络通信，但它们很快被企业架构师所选择，他们正在评估如何利用Web作为一个新的渠道，并希望在任何可能的地方使用新技术。作为一种对互联网友好的连接应用程序的方式，同时节省了大量成本的情况下，Web服务在这些企业中如火如荼地进行着。这种方法采用了“面向服务的体系结构”标签，SOA运动诞生了。

随着SOA运动的启动，一种新的集成模式应运而生，以促进SOA的松耦合原理：企业服务总线（ESB）。现在，许多人已忘记ESB模式层计划是轻量级的和无处不在的，与当时常见的辐射状的企业应用集成（EAI）代理形成直接对比。事实上，ESB概念本身是对由EAI的单一性质所引起的问题的反应，例如较慢的软件交付、太多的跨团队依赖性和差劲的可管理性。

最初的ESB部署愿景是相互协作的服务节点间的集成网络，这让人联想到微服务运动采用的“智能端点和哑管道(简单通讯)”原则。然而，随着ESB概念的普及，它产生了新的含义。依仗Gartner2002时关于ESB模式将在2005的大多数企业中实现的预测，(辐射状)EAI中间件供应商成功说服业界中许多企业：ESB不是模式，而是用于企业应用集成的中间件产品。他们把自己的EAI代理产品重新包装为ESB，而顾客们也欣然接受了。

正如Gartner 所预言的，实施ESB在2005几乎成了当务之急。企业IT组织专门成立了集中式交付团队，由其来管理ESB基础设施，并参与贯穿公司的多个集成项目中。ESB变成了支持SOA的企业架构师的支点，使他们进行转型任务的应用环境中得以立足。他们使用这个立足点有两个新的目的：管理(控制)权和一致性。

为了确保支撑组织业务目标的服务的开发和使用，SOA项目负责人证明他们需要管理权。这导致了SOA治理的子运动，从而产生了自己的软件产品类别。建立一致性的努力包括尝试定义规范的企业数据模型和不断扩展的一组由供应商驱动的标准（统称WS-*），旨在减轻Web服务平台之间的互操作性。随着技术模板、规范性标准和集中指挥控制文化的出现，对EAI的轻量级替代方案变得越来越重。SOA由此偏离了它的轨道。

SOA最初的承诺是加速项目交付，提高IT敏捷性，降低集成成本。然而，SOA采用者（采纳了偏离轨道的SOA的人）发现它实际上增加了复杂性并引入了瓶颈，并且实现SOA基础设施（基于ESB、注册表和服务平台模板）的成本过高。

到2009，人们不仅质疑SOA方法，而且还标明了它的死亡。REST Web API是一种使Web端应用程序有机地结合起来的样式，它是一种轻量级的替代SOAP服务的工具。云基础设施的分布式本质对中心化ESB拓扑结构的布局提出了挑战。在组织上和文化上，敏捷运动推动了权力下放和团队自治。多种其他因素的组合使得SOA运动脱离了主流。

从SOA中吸取教训

询问微服务和SOA是否相同的本身就是错误的问题。这有什么关系？正确的问题应该是问微观服务运动可以从SOA运动中学到什么。出了什么问题？忍受了什么？这里有五个重要的教训：

1. 忠于/坚持目标。当迷失于增加敏捷性，减少成本等最初目标时，SOA运动逐渐偏离了轨道。实施者们在SOA的技术方面花费了太多的精力，却忽视了他们最开始时要解决的问题-业务问题。当《SOA宣言》在2009年发布时，它是对主流SOA运动的反应，而不是对SOA自身原则的一种体现。虽然业务调整是一个不变的特征，但微服务运动仍有偏离的风险。已经有技术人员得出结论，如果他们简单地将应用程序封装起来，那么他们就是“做微服务”。为了成功地使用微服务，我们必须关注目标、预期的利益和原则，然后才考虑有可能使用的技术。

2. 始于成功。尽管SOA在其全盛时期得到了难以置信的关注，但很少有公开的案例研究展示了它的承诺。有趣的是，SOA最初是由行业分析师定义的纯粹概念模式。相反，微服务架构源自于在众多组织中观察到的真实软件开发模式。亚马逊和Netflix只是风格的两个旗手。此外，经过深思熟虑，微服务架构的范围是广泛的，除了技术之外，还包括模式、原则、文化和组织特征。这是健康的，因为它关切现实而非理想主义模式。随着参考微服务实现的改变，模型将会进化。

3. 观点至关重要。在SOA运动中，相互冲突的意图的大量例子导致SOA误入歧途。技术主管们建立集中地帝国，而不是逐步推广文化变革。企业架构师们在没有明确目标的情况下却坚持标准化。供应商们改变了ESB的定义来适应他们的产品，而不是用相反的方式。对于那些仍然对原始SOA定义失去信心的架构师来说，对于那些希望重新将产品重新品牌化的厂商，对于IT企业大量投资于SOA中间件的企业而言，这些曾用斧头来对抗SOA运动的人们，面对微服务的警惕是可以理解的。但是，不要用针对SOA的证据来谴责微服务。敞开胸怀，倾听一切，但一定要检查你的来源。质疑每个人的动机，包括你自己的动机。

4. 寻求和谐，而不是绝对。SOA以和谐的目标开始，例如加速上市时间，同时降低整合成本。受阻于集中的根源，SOA在实践中却放弃了这两个目标，转而寻求管理权和规范应用集成。这是一个过激的和失衡的定位。微服务运动的实质是随着规模的增大，提高软件交付速度，提高系统安全性。这些都是和谐的目标。然而，鉴于微观服务的去中心化的文化及其灵活的本性，存在着实施者可能过多强调团队自主性而危及安全性的风险。这个行业已经有这样的例子了。重要的任务是时刻保持平衡的以支持目标并遵守运动的核心原则。

5. 模式和原则长存，技术则不是。在微服务与SOA的争论中，有一点是共识：微服务体系架构与原始SOA愿景相匹配，即将软件系统分解为松散耦合的服务。这是一种模式。此外，其它原始的SOA原则，如业务对齐、依赖最小化和服务契约也是微观服务原则。巨大的差异在于技术。这既是祝福又是诅咒。技术快速发展。技术运动在很大程度上归结为新技术所证实的原理。对于微服务运动来说，这意味着今天耀眼的新技术将在明天消失。“每个码头工人都有自己(退休)的一天”，微服务也不例外，但微观服务的采纳者应该接受模式和原则，同时也为技术过时做好准备。

微型服务运动令人兴奋。以结合新技术和文化实践的进行综合验证作为原则，它是“合法”的新事物。讨论SOA是否做得很好，SOA的演进，或反SOA都是离题的。微服务必将到来，留下它的标记，并被下一个取代，然后是下一个，如此反复。在目前，它是由微服务运动的成员来确定标记是什么样子的。从SOA运动中吸取这些教训将有助于保持和谐，可以帮助组织实现规模发展下的速度和安全。