微服务、SOA 和 API对比与分析

转自 : http://www.javashuo.com/article/p-hwrqciix-hv.html

 

摘要

对比微服务架构和面向服务的架构（SOA）是一个敏感的话题，经常引发激烈的争论。本文将介绍这些争论的起源，并分析如何以最佳方式解决它们。而后进一步查看这些概念如何与 API 管理概念结合使用，实现更敏捷、更分散化、更具弹性的企业架构。

1、简介

在对比微服务架构和面向服务的架构（SOA）时，几乎不可能在它们彼此的关系上达成一致意见。若是应用程序编程接口（API） 再加入混战，就会让理解它们的差别变得更加困难。一些人可能会说这些概念彻底不一样，它们各自解决本身的一组问题，并且拥有独特的应用范围。其余人可能更宽厚，认为它们实现了相似的目标，而且具备相同的工做原理。他们可能还会说微服务架构是一种 “细粒度的 SOA” 或 “SOA 的恰当应用”。

2、一种过于简单的观点

难以对比 SOA 和微服务的缘由在于，它们的定义留有很大的解释空间。若是您仅拥有这两个概念的表面知识，可能会以为它们很类似。一些关键方面（好比组件化、解耦和标准化通讯协议）描述了最近几十年的大部分软件举措，因此咱们须要进行更深刻地分析。

考虑如下简单定义：

• 微服务架构是一种构造应用程序的替代性方法。应用程序被分解为更小、彻底独立的组件，这使得它们拥有更高的敏捷性、可伸缩性和可用性。

• SOA将应用程序的功能公开为更容易访问的服务接口，使得在下一代应用程序中使用它们的数据和逻辑变得更容易。

以下图演示了这些定义。SOA 彷佛拥有 企业范围，应用程序在该范围内彼此通讯。SOA 经过应用程序之间的标准化接口来公开服务。微服务架构彷佛拥有 应用程序范围，仅关注一个应用程序内的结构和组件。

这些 SOA 和微服务的定义过于简单。事实上，它们之间的关系要复杂得多。

3、SOA 举措的分裂

在更详细地分析 SOA 时，您能够看到它的原始意图不只仅是将接口公开为 SOAP Web 服务。SOA 基于两种观点，它们知足了不一样的需求。

3.1 集成引导的技术元素

第一种观点包括须要深刻集成到现有系统的复杂的专用数据格式、协议和传输机制中。而后须要使用标准化的机制（好比 SOAP/HTTP 或最近的 JSON/HTTP）来公开它们，使它们更易于在新应用程序中重用。这种观点以下图的左侧所示。此观点的部分或所有一般被称为 企业服务总线 (ESB) 模式。可是，这个词被随意使用，以致于失去了它原有的意义。

执行深刻集成（集成中心或适配器）和以标准化方式（公开网关）将这些集成公开为服务或 API 的需求是必不可少的。这个方面与集成挑战密切相关，与应用程序设计也有一点关联。所以它彷佛与微服务应用程序架构没什么关系。

3.2 业务引导的功能元素

第二种观点来自业务角度。关注点是：当前系统上的接口很大程度上没有什么意义。它们对业务没有意义，它们没有提供下一代应用程序所需的东西。它们的粒度可能太细了，公开了系统内太多的复杂数据模型。所需的数据可能分散在多个系统中。数据模型可能不一样于业务部门使用的术语。

该需求要求重构功能，以便公开一些业务人员可切实构建到将来解决方案中的东西。这种重构要求建立新的应用程序，将跨现有的记录系统的请求绑定在一块儿。在 SOA 参考架构中，这些应用程序一般称为 服务组件（以下图的右侧）。这种观点表达了与应用程序设计（进而与微服务架构）和功能分解为单独组件的过程的关系。

3.3 混合这些观点的挑战

组织在哪一种观点具备更大挑战的见解上存在差别。对于某些组织，他们最大的挑战是集成的多样性和复杂性。对于其余组织，重构和从新布局来实现正确的业务功能是主要的挑战。上图显示了依据您认为哪一种挑战占主导，对这个问题的见解有何不一样。

对许多组织而言，挑战在于两种观点的混合让人感到很痛苦。痛苦的缘由是很难将两种观点合并到单个行动过程当中。集成工具不是执行业务逻辑的正确位置。相反地，您不但愿您的业务应用程序充斥着技术集成问题。

大多数 SOA 程序的目标都是实现功能方面。它们想得到可以轻松访问的、可用来更有效地构建新应用程序的业务相关服务。可是，许多组织耗尽了精力，或者更常见的是预算不足，而技术集成难题仍未解决。在大型企业中，SOA 一般被认为是失败的。这种想法多是对的，由于它们未能提供最终的业务价值，尽管付出了巨大努力来改进记录系统的可访问性。可是，在较小的公司（或大型公司中更受限的环境）中，SOA 经常声称真正取得了业务成功，由于它们可快速克服集成问题，并将此转变为功能收益。

这两种 SOA 观点使得与微服务的对比变得很困难。

4、API 与 SOA 公开的服务的对比

API 一般表明着低级编程代码接口。在最近几年，这个词被再次挪用，用来表示经过 HTTP 提供的简单接口。一般它等同于 REST 接口，这些接口使用 JSON 数据格式（有时为 XML）来提供数据，使用 HTTP 动词 PUT、GET、POST 和 DELETE 来描述建立、读取、更新和删除操做。与早期 SOA 中更流行的基于 SOAP 的 Web 服务标准相比，这些协议和数据格式在使用上更加简单。另外，它们更适合 JavaScript 等在建立 API 请求时经常使用的语言。

可是，SOA Web 服务与 API 之间的区别不是由协议和数据格式来定义的，由于两者没有一致地使用它们。区别在于 API 和 SOA 服务背后的意图。一个关键区别是它们的经济学原理。

4.1 可重用的 SOA

在 SOA 程序中，公开服务旨在公开每一个业务功能，以便服务可获得尽量多的重用。这样，每一个新项目就不须要经历再次与后端系统执行集成的痛苦。典型的用户是尝试将全新的用户界面放在旧记录系统上的内部应用程序。在这样作时，集成很是困难，并且会花费很大一部分的 IT 项目预算。若是能够经过可重用的接口公开公司的全部核心功能，就能够大大削减项目成本。SOA 旨在节省成本，而不是创造新收入。

API 拥有不一样的出发点，它假设集成已被简化。这种简化是经过早期的一项 SOA 举措或经过升级后端系统提供更容易使用的现代接口来实现的。新的挑战是为潜在的用户设计一个有吸引力的接口。API 是为可能使用它们的上下文而设计的。例如，它们很是适合提供一种特定类型的移动应用程序所需的数据。

4.2 API 管理的黎明

随着智能电话使用量增加，API 的受欢迎程度也在迅速增加。智能电话运行着丰富的客户端应用程序，创造了一种颠覆性的新业务渠道。所以，应用程序开发人员须要简单地访问后端功能和数据；他们须要 API。API 变成一种畅销的产品，API 提供者为吸引开发人员的注意而展开激烈的竞争。API 的关注点不是 SOA 所关注的重用和成本节省。它的关注点是可以使用性以及参与 API 经济中的竞争。API 是一种畅销产品。

与 SOA 服务相比，这一动态变化改变了对 API 的技术需求。API 须要复杂的门户，以便开发人员可以发现和试验 API。它们还须要一些机制来供开发人员注册使用和付费购买 API。API 提供者须要可以设置支付计划来适应各类 API 使用率。由于 API 是公开的，因此公开网关须要强大的安全功能。全部这些特性都须要是自助服务，并且最重要的是简单。此变化引入了一种如今称为 API 管理的全新 IT 功能。

为此，API 的关注点是做为某种向外部用户公开的功能；API 与内部 SOA 服务之间的分界线已变得很明确。随着 API 管理技术日渐成熟，API 已带来了诸如易用性和自我管理等收益。结果，许多公司如今还但愿使用 API 技术和协议来公开公司内部的服务，以下图所示。SOA Web 服务和 API 之间的界线如今已经变得有些模糊，并且几乎可有可无。它们在起源、向哪些用户公开和使用的数据模型上不一样，但许多 SOA “服务” 也能够描述为内部 API。

现在，API 这个词一般用于指代任何经过 REST (HTTP/JSON) 或 Web 服务（SOAP/HTTP） 公开的接口。API 一般按其范围进行分类，好比公共 API 或企业 API。维持 SOA 举措的企业有时会为内部、企业级 API 保留 “服务” 这个词。

API 这个词表示 SOA 的 “服务公开” 方面的一次进化。它使用更简单的协议，更加精于公开自己，包括开发人员门户、策略控制和自我管理。

5、微服务：一种替代性架构

在考虑对比微服务和 SOA 以前，须要理解微服务架构的含义。从基本角度讲，微服务是构建 应用程序的替代性架构。它们提供了更好的方法来解耦应用程序边界 内的组件。事实上，若是将微服务称为 “微型组件”，它们的实际性质会更加明确。

应用程序的边界保持相同。以下图所示，尽管应用程序在内部被分解为不一样的微服务组件，但从外部来看，应用程序还是相同的。基于微服务的应用程序公开的 API 的数量和粒度不该与将 API 构建为孤立应用程序有任何不一样。微服务中的第一个词“微型” 表示内部组件的粒度，而不是公开的接口的粒度。

在应用程序内从逻辑上分离组件不是一个新概念。多年以来，大量不一样的技术被开发出来，用于实现整个应用程序的各部分的干净分离。应用服务器可在其内部长期运行多个应用程序组件，以下图中的中图所示。微服务更进一步，在这些应用程序组件之间进行了绝对隔离。它们变成网络上单独运行的流程，以下图中的右侧所示。为了实现解耦，您还应分割您的数据模型来与微服务保持一致。

6、微服务的优点

彻底独立的微服务组件有助于实现彻底自主的全部权，带来如下优点：

• 敏捷性和生产力：开发微服务的团队能够彻底理解代码库。他们能够在快得多的周期中与其余组件独立地构建、部署和测试代码库。由于微服务组件只是网络上的另外一个组件，因此您能够采用最适合所需功能的语言或框架来编写它，并采用最合适的持久性机制。

  这种方法可显著减小要编写的代码量，使维护获得显著简化。它能够确保团队可以根据须要采用新技术或现有技术的新版本，而不是等待应用程序域的剩余部分跟上节奏。对于微服务粒度的定义，微服务组件应足够简单，以便在必要时在其下一次迭代中重写。

• 可伸缩性：微服务开发团队能够在运行时与其余组件独立地扩展微服务组件，实现资源的高效使用和对工做负载变化的快速反应。从理论上讲，一个组件的工做负载能够转移到对任务最合适的基础架构上。它还能够与剩余组件独立地从新放置，以便充分利用网络位置。精心编写的微服务提供了非凡的按需可伸缩性，这一领域的早期创新者和采用者已证实这一点。这些微服务也获得了最佳布置，以便充分利用弹性功能，以富有成本效益的方式访问大量资源的原生云环境。

• 恢复能力：独立的运行时能够当即提供与其余组件中的故障独立的恢复能力。借助当心地解耦的设计，好比避免同步依赖关系和使用断路器模式，能够编写每一个微服务组件来知足本身的可用性需求，而不是在整个应用程序域中引入这些需求。容器等技术和轻量型运行时使微服务组件可以快速且独立地失败，而不是让全部不相关的功能区域都失效。一样地，它们是以一种高度无状态的方式编写的，以即可以当即从新分布工做负载并几乎同时地调出新运行时。

这些优点的示例是组织转而使用微服务的一些最多见的缘由。

7、选择微服务时要考虑的关键因素

在决定是否将应用程序编写为微服务时，必须理解如下因素，以确保您的组织准备好处理它们：

• 新技术模式。微服务是一种彻底不一样的应用程序构建方法。由于它们在网络上，因此它们须要网络上的一组全新的组件。一些支持技术已经存在，包括服务发现、工做负载编排、容器管理和日志框架。可是，您必须将它们放入一个紧密结合的集合中，这须要大量实验、技能和经验。您必须肯定知足您的需求的完美的微服务设置的构成要素，它们可能与其余企业的微服务不一样。

• 应用程序适合性。微服务并不适合每一个应用程序。目前微服务社区中的一种悖论是，让新的、相对简单的、具备高度凝聚性数据模型的应用程序采用微服务的概念，这样作不会得到任何优点。另外，将一个复杂的现有应用程序重构到微服务架构中是一项繁重的工做。

  若是不是在旧版或新式应用程序上，您会什么时候使用微服务？一种 建议是，在以传统方式编写的应用程序达到复杂性的拐点以前，不要使用微服务。可是，要让此方法发挥做用，则须要从一开始就编写一个适当构建的应用程序，并选择在正确的时刻执行过渡。

• 不一样的设计范例。微服务应用程序架构须要不一样的设计方法。要从微服务方法得到最佳结果，您可能须要：

  1. 接受最终的一致性模型，而不是您所习惯的事务性交互。

  2. 理解如何处理没有中央操做数据存储的事件源应用程序。

  您还须要：

  1. 若是须要利用重要的快速可伸缩性优点，请确保您的应用程序逻辑是无状态的。

  2. 若是将您本身与下游组件分离，则须要熟悉异步通讯的细微的潜在反作用。

  3. 理解实现断路器模式的逻辑后果。

  4. 认识到 HTTP/JSON 通讯相比于进程中通讯的错误处理限制。

  5. 考虑链式交互中的网络延迟。

• DevOps 成熟性。微服务须要一种成熟的交付能力。持续集成、部署和全自动测试都必不可少。编写代码的开发人员必须负责代码的生产部署。构建和部署链须要重大更改，以便为微服务环境提供正确的关注点分离。

8、微服务如何融入到 SOA 环境和集成挑战中

若是咱们 SOA 的心理模式注重集成方面，那么微服务是彻底分离的。它是编写集成架构尝试链接的应用程序的一种替代方法，如图 1所示。

可是，若是咱们的 SOA 的心理模式注重将应用程序从新布局为对业务更有意义的 “服务组件”，图 2 中的右侧显示的服务组件可能看起来更像微服务组件。微服务架构如今可视为 SOA 的一次进化。为了演示这一点，让咱们对比一下两个极端。

首先，考虑一家新的创业公司，该公司对一种彻底在线的产品（好比社交媒体或交易）有一种新想法。由于它最初没有现有的架构可用，因此该公司必须建立一套新应用程序来知足该业务的独特方面。而后，该公司能够选择将非核心增值业务的部分业务外包，并使用软件即服务 (SaaS) 应用程序来提供客户关系管理功能。

从很大程度上讲，该公司的格局可能会从头创建。主要关注点多是它在一个持续可用的环境（绿场的概念）中以极少的宕机时间快速添加新功能的能力。该公司可能想根据没法预测的客户需求来实现灵活的伸缩（即扩展和精减）。它可能但愿实现一种全天候的、高度可用的在线存在感。

微服务架构是该公司的许多格局的逻辑选择，如图 6所示。

新应用程序可能位于单个微服务框架中，该框架提供了非功能性能力，好比可伸缩性、可用性和资源管理。您可能预料到低级集成问题不多，由于全部微服务组件和所涉及的 SaaS 应用程序都将使用常见的协议（好比 HTTP/JSON API）进行通讯。SOA 公开宝贵的功能的一个关键目标是，为了它能够在整个企业中获得结合使用。在这个示例中，精心实现的 SOA 和微服务架构之间的界线已变得模糊。若是想象一下 SOA 的完美实现，它可能看起来和这个示例同样，但只有新公司可以建立这种性质的架构。

本文不会探讨 SOA “服务组件” 是否在大小上与微服务组件至关。微服务组件的粒度和它们的分组方式彻底是另外一个话题。

如今咱们来考虑一个相反的示例，一家已经发展起来的大型公司，几十年来它已经创建了本身的 IT 格局。这个企业多是一家传统的银行或保险公司，可能拥有数百或者甚至数千个重要应用程序是使用可追溯到数十年前的技术构建的。该企业内可能拥有严格的部门划分，好比医疗、养老金和通常保险，或者零售和投资银行。每一个业务部门可能都拥有专门处理其核心业务的独立应用程序。这些部门还可能有一套应用程序，好比对于人力资源，其应用程序会尽量共享。

该公司多是经过并购竞争对手发展起来的。在该格局中，您会发现应用程序之间存在大量的数据重复。根据最初为客户服务的公司，客户账户可能分散在许多系统中。同一个客户在多个系统中的关联性可能不是很直观。这些后端应用程序一般很难在内部进行更改。在此环境中，SOA 的一项艰巨任务就是将后端系统从新想象为对将来的业务需求更有用的某种东西。

集成挑战也很复杂。它可能须要集成工具（如 图 7 所示），使得人们在存在协议、传输和数据格式上的挑战的状况下，仍能访问来自后端应用程序的数据和功能。主要出于历史缘由，这种集成作法一般被打上 “SOA” 的标签，尽管它仅关注一半的 SOA 挑战。它被标为 SOA 是由于集成是大多数 SOA 举措处理的第一个区域。在许多状况下，这是他们在可用资金范围内完成的所有工做。

可是，公司须要使用 SOA 实现的另外一个方面是，将数据和功能改造为更加以业务为中心的功能。他们须要肯定如何知足移动等新渠道，这些渠道须要使用与传统应用程序彻底不一样的服务粒度。为了实现这些方面，公司须要提供当前系统中可能没有的响应能力、可用性和可伸缩性。必须编写应用程序，以一种特殊风格知足这些新渠道，这种风格支持快速的敏捷变动，提供了极高的可伸缩性，并且提供了卓越的可用性。

人们很容易看到对这些新应用程序使用微服务架构的吸引力。如 图 7 所示，大型企业中对微服务的初始使用专一于新的互动参与体系应用程序。SOA 概念可能被早期的以集成为中心的工做所影响。所以，微服务一般被视为不一样于 SOA，它提供了更高的敏捷性、可伸缩性和响应能力，但在许多状况下，这些取决于 SOA 的集成阶段的基础工做。

9、在将来将微服务、SOA 和 API 组合在一块儿

从架构的角度讲，SOA 有 3 个关键元素：

深刻集成使老化的系统可以公开其数据和功能，以便使用一个接口来发现这些数据和功能；

服务公开标准化并简化这些接口向更普遍的受众公开的方式；

服务组件将接口进一步组合到更宝贵的业务资产中；

这 3 种元素仍会存在于将来的架构中，但它们必定会分散在整个格局中，如图 8所示。

9.1 深刻集成

一些系统仍须要集成中心所提供的深刻集成功能，以便将它们的基础功能和数据公开为 API。其余系统可能可以在升级到新版本时直接提供 API。当 SOA 倾向于将深刻集成功能整合到一个集中化功能中时，关键区别就会显现出来。更高级的工具和技术应支持集成，以便更频繁地与应用程序全部者进行联合，如 图 8 中的集成中心的位置所示。

9.2 服务公开

此外，全部系统只要想要保持关联，都须要提供 API。应用程序级 API 须要一个轻量型的控制层，如 图 8 中的 API 网关所示。这个控制层是来自 SOA 的服务公开概念的一种演化。它已变成更普遍、更分散化的 API 公开。

API 网关和管理功能多是整个企业的一种通用资源。它是 “分散化的”，应用程序团队能够自行发布 API，一样也能够自行订阅他们所需的 API，而再也不须要一个额外的团队。您能够在整个企业中以标准方式得到标准化的流量管理和监视、日志记录、审计和安全性机制，同时保留业务人员所需的敏捷性。这些相同的 API 网关也可用来帮助管理与业务合做伙伴和外部 SaaS 功能的交互。

9.3 服务组件

传统的、更加孤立的应用程序仍适合一些实现。可是，微服务提供了一种构建某些类型的应用程序的替代方法，提供了传统应用程序没法提供的敏捷性、可伸缩性和恢复能力。微服务应用程序在互动层最多见，这一层最须要它们的具体特征，支持建立新的特定于渠道的功能和面对互联网的 API。

10、结束语

对于 SOA 打算实现的目标，至少有两种不一样的观点。SOA 与微服务架构之间的直接对比可能充满困难。SOA 的概念存在于现代架构中，但已经过多种方式发生了演变。集成工具、模式和标准也已发生演变，因此功能和数据更容易公开。服务公开已演变为 API，简化了公开、使用、管理，在某些状况下，还能够从业务功能中牟利。新应用程序架构（包括微服务架构）使得开发人员可以更密切地关注业务逻辑，不断将基础架构细节推送到他们所在的环境。这些开发方式的组合有助于以更敏捷的风格构建解决方案，有助于应用程序得到全新的弹性可伸缩性和容错水平。