从面向服务架构（SOA）学习：微服务时代应该借鉴的5条经验教训
【编者按】本文作者为 Matt McLarty，通过介绍 SOA 的兴衰变化，总结了微服务应该借鉴的5条经验教训。文章系国内 ITOM 管理平台 OneAPM 编译呈现。
SOA 的兴衰变化让我们更了解如何充分利用微服务
正如笔者在上文《微服务架构是敏捷软件架构》中提到的，笔者对微服务架构的第一反应，就是质疑它跟面向服务架构（SOA）有何区别。还有很多人将这两种架构联系在一起。詹姆斯·刘易斯和马丁·福勒在他们的权威博客中包含了一个侧边栏，进行微服务和 SOA 的对比。对此，怀疑派做出的回应是二者之间并无不同。实际上，在“微服务”这个名词出现之前，使用微服务的亚马逊和 Netflix 都谈到它们使用的是面向服务的架构。两年多之后，关于微服务架构是不是 SOA 的争辩带来了大量的文章。
为什么人们这么热衷于对比微服务和 SOA，而且还投入这么大的激情？虽然微服务和 SOA 在很多层面上可以相互区分——架构风格、实施案例、相关技术——但是它们在技术发展全景中起到了同样惊人的作用。它们都有望转变整个格局，而且都成功吸引了一大批拥护者。简单来说，微服务和 SOA 都以架构开始，但是最终都成了一场运动。
可惜啊，现在 SOA 在 IT 业内基本上被视为一场失败的运动，而很多为它投入时间、金钱和精力的人的伤痛依然清晰可见。这就是为什么大家有这么大的热情来对比较微服务和 SOA。要想了解微服务与 SOA 辩论的背景，回顾 SOA 运动的历史非常重要：它的动力是什么，以及最终导致失败的原因是什么。
SOA 的兴衰
1996年,高德纳公司的分析员 Roy Schulte对面向服务架构做出了如下定义：
面向服务架构是一种多层信息处理技术，能帮助企业在多个应用和使用模式之间分享逻辑和数据。
虽然 SOA 很早就获得了这个定义，直到2002年，网络服务出现之后，SOA 才在行业内得到广泛应用。尽管 SOAP/XML 的初衷是为完全不同的企业之间提供服务器到服务器的网络沟通，它们很快就被企业架构师们选择使用，他们一直在评估将网络作为新渠道、并操控新技术的方法。作为一种连接应用、互联网友好、预计能节省大量开支的方法，网络服务在这些企业中迅速风靡。这种方法被贴上了“面向服务架构”的标签，SOA 运动就此诞生。
随着 SOA 运动的兴起，一个新的集成模式出现了，用于推动 SOA 松散的连接原则：企业服务总线（ESB）。很多人现在已经忘了 ESB 模式旨在轻便、无处不在，这与当时通用的轴辐式企业应用集成（EAI）是截然不同的。实际上，ESB 概念本身就是为了应对 EAI 代理的整体式特征带来的问题而生的，例如软件交付变慢，过于依赖其他团队以及可管理性太差等。
最初的 ESB 部署版本是个恰当地集成协作服务节点的网络，让人联想到微服务运动采用的“智能端点哑管道（smart endpoints and dumb pipes）”原则。然而，随着 ESB 的理念得到更加广泛的使用，它引发了一个新的含义。2002年高德纳公司预言 ESB 模式将在2005年被绝大多数公司采用，轴辐式 EAI 中间件的代理商们得以说服很多业内人士，ESB 不是一种模式，而是用于企业软件集成的一个中间件产品。他们把 EAI 代理产品包装成 EBS，消费者们还真的愿意买账。
正如高德纳公司的预言，到了2005年，实施 EBS 成了必不可少的事。IT 公司成立了集中的交付部门来管理 EBS 基础架构，并且参与公司各部门的集成项目。ESB 为那些主张 SOA 的企业架构师提供了改造应用环境任务的立足点。他们利用这个立足点要实现两个目的：控制和保持一致性。
SOA 项目领导为控制需求辩护的理由是要确保那些支撑企业商业目标的服务的开发和使用。这就催生了 SOA 管理的分支运动，由此诞生了自有软件产品类别。建立一致性的努力包括尝试定义标准的企业数据模式，还有一套扩展的代理导向标准（总体的网络服务），旨在减少网络服务平台之间的内部操作。技术模板、规范标准、集中的命令和控制文化，所有这些都让本该轻量化的 EAI 替代者越来越沉重。SOA 迷失了发展方向。
SOA 的设计初衷是加速项目交付，提高 IT 敏捷性，减少集成成本。然而，SOA 使用者，也就是使用发展到现在的 SOA 的人们，发现它实际上带来了更多复杂性和瓶颈，而且部署 SOA 基础构架的费用（基于 ESB、注册和服务平台模板）过多。
到了2009年，人们不再质疑 SOA 方法，而是直接弃用。RESTful Web API——一种连接网络有机进化的应用的方式——作为 SOAP 服务的轻量级备选出现了。云架构的分布式本质对集中的 ESB 拓扑安置是个挑战。从公司层面和文化层面来说，敏捷运动在促进分散化和团队自治。这些因素加起来，和其他因素一起让 SOA 退出了主流。
SOA 经验教训
讨论微服务和 SOA 是否相同是个错误的问题。那有什么关系呢？正确的问题应该是问微服务运动能够从 SOA 借鉴什么。出了什么问题？以下是五条重要的经验教训。
-
坚守目标。SOA 运动在偏离了最初的增加敏捷性和降低成本的目标之后，偏离了正途。实施者们过度关注 SOA 的技术，忽略了他们试图解决的商业问题。2009年发布的 SOA 宣言只是对主流 SOA 运动做出的回应，而不是它的原则的具体体现。虽然业务排列是微服务运动宣称的特征，但是它也面临偏离轨道的风险。已经有实例表明，技术专家总结说，如果他们把应用集装箱化，就是在“实施微服务”了。为了成功实施微服务，在考虑实际可用的技术之前，我们必须专注于目标、希望实现的益处和原则。
-
从成功开始。尽管 SOA 在全盛时期使用率之高空前绝后，但是并没有什么公共实例可以证明它的承诺。很明显，SOA 最开始是由一个行业分析员提出的纯概念模型。与之相反，微服务架构是根据对无数企业的实际软件开发的观察提取出来的。亚马逊和 Netflix 只是这种风格的两个旗手。而且，微服务的范围非常广泛，除了技术之外，还包括模型、原则、文化和企业特征。这样很健康，因为它推崇的不是一个理想化的模型，而是真实模型。随着微服务实施的参考内容变更，模型也应该随之进化。
-
视角很重要。在 SOA 运动中，有很多例子表明，冲突的意愿导致了它偏离正轨。技术管理人员搭建了集权式的帝国，而不是逐渐灌输文化的变更。企业架构师坚持标准化，却没有清晰的目标。代理商们修改 ESB 的定义来适应他们的产品，而不是反过来。依然惋惜 SOA 初始定义被遗弃的架构师，希望能再次重新定义产品的代理商，对 SOA 中间件付出大量投入的企业 IT 商店，这些手持斧头反对 SOA 运动的人，对微服务心怀警惕也是可以理解的。不过，不要因为反对 SOA 的证据就给微服务定罪。思想开明，倾听所有声音，但是要确保检查确认来源。质疑每个人的动机，包括你自己的。
-
寻求和谐，而不是绝对。SOA 最初的目标是平衡的，例如加快产品上市速度，同时降低集成成本。基于集中制的根基，SOA 运动在实践中摒弃了这两个目标，转而追求应用集成的控制和标准化。这是个极端而又失衡的定位。微服务运动的核心就是随着规模扩大，改进软件交付速度，提高系统安全性。这些是和谐的目标。然而，考虑到微服务及其敏捷根源的分散式遗产，也存在实施者偏离正轨，带来过多团队自治，因而牺牲安全性的风险。这在行业内已有前车之鉴。重要的是确保存在制衡力量来支撑目标，并坚持核心原则。
-
模型和原则能够持续，技术却不会。在微服务与 SOA 的争辩中，有一点是达成共识的：微服务架构符合最初 SOA 对软件系统分解为分散耦合服务的愿景。那就是一个模型。而且，最初的 SOA 原则诸如业务排列、依赖最小化和服务契约等，都与微服务的原则一致。二者之间最大的不同在于技术。这具有两面性。技术进化速度非常快。在很大程度上，技术运动都可以归结到新技术带来的原则。对于微服务运动来说，这意味着今天风头正劲的技术明天可能就会过时。各种 Docker 都有得意的日子，但是微服务使用者应该拥抱模型和原则，并且做好技术被淘汰的准备。
微服务运动令人激动。在合成已被证明的原则和新技术、文化实践方面，它的确还很新。它是否是 SOA 的成功版本、进化版本或者反面版本都无关紧要。微服务会出现，留下印记，然后被下一个运动替代，接着是下下一个，永不停歇。目前，微服务运动的成员决定了它将会留下怎样的印记。希望它能从 SOA 运动吸取经验教训，保持和谐状态，从而帮助企业实现大规模的速度与安全的优化。
本文系 OneAPM 工程师编译整理。OneAPM 能为您提供端到端的 Java 应用性能解决方案，我们支持所有常见的 Java 框架及应用服务器，助您快速发现系统瓶颈，定位异常根本原因。分钟级部署，即刻体验，Java 监控从来没有如此简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
