从面向服务架构（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 借鉴什么。出了什么问题？如下是五条重要的经验教训。

1. 坚守目标。SOA 运动在偏离了最初的增长敏捷性和下降成本的目标以后，偏离了正途。实施者们过分关注 SOA 的技术，忽略了他们试图解决的商业问题。2009年发布的 SOA 宣言只是对主流 SOA 运动作出的回应，而不是它的原则的具体体现。虽然业务排列是微服务运动宣称的特征，可是它也面临偏离轨道的风险。已经有实例代表，技术专家总结说，若是他们把应用集装箱化，就是在“实施微服务”了。为了成功实施微服务，在考虑实际可用的技术以前，咱们必须专一于目标、但愿实现的益处和原则。

2. 从成功开始。尽管 SOA 在全盛时期使用率之高旷古绝伦，可是并无什么公共实例能够证实它的承诺。很明显，SOA 最开始是由一个行业分析员提出的纯概念模型。与之相反，微服务架构是根据对无数企业的实际软件开发的观察提取出来的。亚马逊和 Netflix 只是这种风格的两个旗手。并且，微服务的范围很是普遍，除了技术以外，还包括模型、原则、文化和企业特征。这样很健康，由于它推崇的不是一个理想化的模型，而是真实模型。随着微服务实施的参考内容变动，模型也应该随之进化。

3. 视角很重要。在 SOA 运动中，有不少例子代表，冲突的意愿致使了它偏离正轨。技术管理人员搭建了集权式的帝国，而不是逐渐灌输文化的变动。企业架构师坚持标准化，却没有清晰的目标。代理商们修改 ESB 的定义来适应他们的产品，而不是反过来。依然可惜 SOA 初始定义被遗弃的架构师，但愿能再次从新定义产品的代理商，对 SOA 中间件付出大量投入的企业 IT 商店，这些手持斧头反对 SOA 运动的人，对微服务心怀警戒也是能够理解的。不过，不要由于反对 SOA 的证据就给微服务定罪。思想开明，倾听全部声音，可是要确保检查确认来源。质疑每一个人的动机，包括你本身的。

4. 寻求和谐，而不是绝对。SOA 最初的目标是平衡的，例如加快产品上市速度，同时下降集成成本。基于集中制的根基，SOA 运动在实践中摒弃了这两个目标，转而追求应用集成的控制和标准化。这是个极端而又失衡的定位。微服务运动的核心就是随着规模扩大，改进软件交付速度，提升系统安全性。这些是和谐的目标。然而，考虑到微服务及其敏捷根源的分散式遗产，也存在实施者偏离正轨，带来过多团队自治，于是牺牲安全性的风险。这在行业内已有前车可鉴。重要的是确保存在制衡力量来支撑目标，并坚持核心原则。

5. 模型和原则可以持续，技术却不会。在微服务与 SOA 的争辩中，有一点是达成共识的：微服务架构符合最初 SOA 对软件系统分解为分散耦合服务的愿景。那就是一个模型。并且，最初的 SOA 原则诸如业务排列、依赖最小化和服务契约等，都与微服务的原则一致。两者之间最大的不一样在于技术。这具备两面性。技术进化速度很是快。在很大程度上，技术运动均可以归结到新技术带来的原则。对于微服务运动来讲，这意味着今天风头正劲的技术明天可能就会过期。各类 Docker 都有得意的日子，可是微服务使用者应该拥抱模型和原则，而且作好技术被淘汰的准备。

微服务运动使人激动。在合成已被证实的原则和新技术、文化实践方面，它的确还很新。它是不是 SOA 的成功版本、进化版本或者反面版本都可有可无。微服务会出现，留下印记，而后被下一个运动替代，接着是下下一个，永不停歇。目前，微服务运动的成员决定了它将会留下怎样的印记。但愿它能从 SOA 运动吸收经验教训，保持和谐状态，从而帮助企业实现大规模的速度与安全的优化。

本文系 OneAPM 工程师编译整理。OneAPM 能为您提供端到端的 Java 应用性能解决方案，咱们支持全部常见的 Java 框架及应用服务器，助您快速发现系统瓶颈，定位异常根本缘由。分钟级部署，即刻体验，Java 监控历来没有如此简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客

原文地址：http://www.javaworld.com/article/3080611/application-development/learning-from-soa-5-lessons-for-the-microservices-era.html