流行术语为那些逐步形成的、需要一个好的“标签”来方便交流的概念提供了一个上下文。微服务就是这样的一个新“标签”，它定义了一个领域，这个领域我自己也发现了，并且现在已经使用了一段时间。我慢慢认识到，相关文章和会议所描述的东西，我已经从自己过去几年的个人经历中引申出来。行业和专家对微服务的讨论让 Netflix、亚马逊、谷歌等已经成功实现微服务的公司成为了焦点，而我有一些个人经验，可以为成功实现微服务提供一些启发。

以下是任何架构都遵循的三个标准和常见的业务驱动力：

·提高敏捷性——及时响应业务需求，促进企业发展

·提升用户体验——提升客户体验，减少客户流失

·降低成本——降低增加产品、客户或业务方案的成本

实际上，在日常工作中，所有人都试图这样做。SOA 创建了一种业务一致的软件框架，使企业可以达成上述目标。已经出现了几家大型的软件供应商，宣称他们的产品套件可以推动企业实现 SOA。

如果没有合适的人员、文化和投入，那么 SOA 会无法实现业务价值。微服务同 SOA 并没有根本的不同，它们的目标和目的是相同的，但微服务方法更精炼。事实上，简单来说，微服务就是可扩展的 SOA。对于迫切需要由单体实现转变成分布式、去中心化的服务平台并为许多应用程序提供服务的应用程序 / 系统，微服务提供了这种可能。微服务是独立的，它拥抱敏捷，并允许应用程序随企业的数字化转型进化。微服务的成功取决于服务独立性和灵活度。

我会将微服务定义为“一种实现 SOA 的方法，它通过构建细粒度的服务支持分布式的、按功能域组织的业务能力”。没有哪种模式是魔法棒或银弹。你应该专门针对一个企业构思和定制模式。企业应该重点解决那些可以为建立自适应平台的架构提供支持的必要事项。

非常不幸的是，一些企业在实现 SOA 时失败了——因为他们没有充分分析他们的业务能力模型，认为开发 Web 服务就是 SOA，或者从大型供应商那里购买一个 SOA 套件就实现了 SOA，或者他们没有能力阐述 SOA 同其业务驱动力 / 目标的一致性。

例子

我经历过的一个例子也许可以说明这一点。在以前的一个岗位上，企业的目标是提高敏捷性、提升用户体验以及降低成本。我们决定构建一个标准的多租户 SOA 平台。我们选择的方法是开发细粒度的服务，以便我们能够经常修改，并将便于管理的小变更部署到平台。如果今天我们采用了同样的方法，那么我们会称其为微服务架构。当时还没有这个术语，但它就是有效。

服务根据业务能力建模，初次发布进展顺利。这是些基于 JMS 的 XML 同步服务，主要用于为面向代理商、Web 和语音通道应用程序的索赔平台提供其所需的业务能力。它为我们提供了敏捷性，使我们可以频繁部署小变更，使我们的应用程序可以完美支持 A/B 功能。

当需求逐步增加（需求总是会增加）时，由于应用程序同消费者之间集成复杂度很高，所以难以实现方案的快速发布。集成、功能测试、产品发布需要紧密协作。随着业务开始扩展，与初次发布相比，变更多了 10 多倍，而且，由于交付周期中的大部分任务都是手工的，所以推向市场的时间无法达到企业预期。很快，糟糕的微服务自动化和生命周期管理导致了“交付熵（delivery entropy）”，我们的目标一个也实现不了了。