从面向服务架构（SOA）学习：微服务时代应该借鉴的5条经验教训

可惜啊，现在 soa 在 it 业内基本上被视为一场失败的运动，而很多为它投入时间、金钱和精力的人的伤痛依然清晰可见。这就是为什么大家有这么大的热情来对比较微服务和 soa。要想了解微服务与 soa 辩论的背景，回顾 soa 运动的历史非常重要：它的动力是什么，以及最终导致失败的原因是什么。

面向服务架构是一种多层信息处理技术，能帮助企业在多个应用和使用模式之间分享逻辑和数据。

正如高德纳公司的预言，到了2005年，实施 ebs 成了必不可少的事。it 公司成立了集中的交付部门来管理 ebs 基础架构，并且参与公司各部门的集成项目。esb 为那些主张 soa 的企业架构师提供了改造应用环境任务的立足点。他们利用这个立足点要实现两个目的：控制和保持一致性。

soa 的设计初衷是加速项目交付，提高 it 敏捷性，减少集成成本。然而，soa 使用者，也就是使用发展到现在的 soa 的人们，发现它实际上带来了更多复杂性和瓶颈，而且部署 soa 基础构架的费用（基于 esb、注册和服务平台模板）过多。

讨论微服务和 soa 是否相同是个错误的问题。那有什么关系呢？正确的问题应该是问微服务运动能够从 soa 借鉴什么。出了什么问题？以下是五条重要的经验教训。

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

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

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