一、简介在比较微服务架构和面向服务的架构(SOA)时，几乎不可能就它们之间的关系达成一致。当应用程序编程接口(API)加入竞争时，理解它们之间的差异变得更加困难。有些人可能会说这些概念完全不同，每个概念都解决自己的一组问题并具有独特的应用范围。其他人可能会更宽容，认为他们实现了相似的目标并且具有相同的工作原理。他们也可能会说微服务架构是“细粒度的SOA”或“状态良好的SOA”。2.过于简化的观点之所以难以比较SOA和微服务，是因为它们的定义留下了很大的解释空间。如果您对这两个概念只有粗浅的了解，它们可能看起来很相似。几个关键方面（例如组件化、解耦和标准化通信协议）描述了过去几十年的大多数软件计划，因此我们需要更深入地分析它们。考虑以下简单定义：微服务架构是构建应用程序的另一种方式。应用程序被分解成更小的、完全独立的组件，这使得它们更加敏捷、可扩展和可用。SOA将应用程序的功能公开为更易于访问的服务接口，从而更容易在下一代应用程序中使用它们的数据和逻辑。下图演示了这些定义。SOA似乎有一个企业范围，在这个范围内应用程序相互通信。SOA通过应用程序之间的标准化接口公开服务。微服务架构似乎具有应用范围，只关注应用程序中的结构和组件。这些SOA和微服务的定义过于简单化。事实上，他们之间的关系要复杂得多。3.SOA计划的碎片化当更详细地分析SOA时，您会发现它的初衷不仅仅是将接口公开为SOAPWeb服务。SOA基于两个视角，它们满足不同的需求。3.1以集成为导向的技术要素第一个观点涉及复杂的专有数据格式、协议和传输机制，需要与现有系统进行深度集成。然后需要使用标准化机制（例如SOAP/HTTP或最近的JSON/HTTP）公开它们，使它们更容易在新应用程序中重用。此视图显示在下图的左侧。这种观点的部分或全部通常称为企业服务总线(ESB)模式。然而，这个词用得太随便了，以至于失去了它本来的意思。执行深度集成（集成中心或适配器）并以标准化方式将这些集成公开为服务或API（公开网关）的需求势在必行。这方面与集成挑战密切相关，也与应用程序设计有一定关系。所以它似乎与微服务应用程序架构没有任何关系。3.2业务指导的功能要素第二种观点来自于业务的角度。令人担忧的是，当前系统上的接口在很大程度上毫无意义。它们对业务没有意义，也不能提供下一代应用程序所需的东西。它们可能过于细粒度，在系统中暴露了太多复杂的数据模型。所需的数据可能分散在多个系统中。数据模型可能与企业使用的术语不同。此要求需要重构功能以公开业务人员可以实际构建到未来解决方案中的内容。这种重构需要创建新的应用程序，将跨现有记录系统的请求联系在一起。在SOA参考架构中，这些应用程序通常称为服务组件（下图右侧）。这种观点表达了与应用程序设计（以及因此与微服务架构）的关系以及将功能分解为单个组件的过程。3.3混合这些观点的挑战组织对哪种观点更具挑战性的看法各不相同。对于一些组织来说，他们最大的挑战是集成的多样性和复杂性。对于其他组织而言，重构和重新安排以实现正确的业务功能是一项重大挑战。上图显示了根据您认为占主导地位的挑战，对这个问题的看法有何不同。许多组织面临的挑战是两种观点的痛苦混合。痛苦的原因是难以将两种观点合并为一个单一的行动过程。集成工具不是执行业务逻辑的正确位置。相反，您不希望您的业务应用程序充满技术集成问题。大多数SOA程序的目标是实现功能方面。他们需要易于访问的业务相关服务，以便更有效地构建新的应用程序。然而，许多组织耗尽了精力，或者更常见的是，预算耗尽，而技术集成挑战仍未解决。在大型企业中，SOA通常被认为是失败的。这种想法可能是正确的，因为尽管为提高记录系统的可访问性做出了巨大努力，但它们仍无法提供最终的商业价值。然而，在较小的公司（或在较大公司的更受限制的环境中），SOA通常声称真正的业务成功，因为它们迅速克服了集成问题并将其转化为功能收益。这两个SOA视角使得与微服务的比较变得困难。4.API与SOA暴露服务的对比API通常代表低级编程代码接口。近年来，该术语已被重新用于表示通过HTTP提供的简单接口。通常它等同于使用JSON数据格式（有时是XML）提供数据的REST接口，使用HTTP动词PUT、GET、POST和DELETE来描述创建、读取、更新和删除操作。这些协议和数据格式比早期SOA中更流行的基于SOAP的Web服务标准更易于使用。此外，它们更适合创建API请求时常用的JavaScript等语言。然而，SOAWeb服务和API之间的区别不是由协议和数据格式定义的，因为两者并不一致地使用它们。区别在于API和SOA服务背后的意图。一个关键的区别是它们的经济原理。4.1可重用的SOA在SOA方案中，暴露服务的目的是暴露各个业务功能，使服务尽可能的被重用。这样，每个新项目都不需要再次经历与后端系统集成的痛苦。典型的用户是试图在旧的记录系统上放置全新用户界面的内部应用程序。这样一来，集成就很困难，并且会消耗很大一部分IT项目预算。如果一个公司的所有核心功能都可以通过可重用的接口暴露出来，那么项目的成本就可以大大降低。SOA是为了节约成本，而不是创造新的收入。API有一个不同的起点，它假定集成已被简化。这种简化是通过早期的SOA计划或通过升级后端系统以提供更易于使用的现代界面来实现的。新的挑战是为潜在用户设计一个有吸引力的界面。API是为可能使用它们的上下文而设计的。例如，它们非常适合提供一种特定类型的移动应用程序所需的数据。4.2API管理的曙光随着智能手机使用量的增长，API的普及程度也在增长。运行富客户端应用程序的智能手机创造了一个颠覆性的新业务渠道。因此，应用程序开发人员需要轻松访问后端功能和数据；他们需要API。API成为最畅销的产品，API提供商为争夺开发人员的注意力展开了激烈的竞争。API的重点不是SOA所关注的重用和成本节约。它的重点是可用性和API经济中的竞争。API是畅销书。与SOA服务相比，这种动态改变了API的技术要求。API需要复杂的门户供开发人员发现和试验API。他们还需要一些机制让开发人员注册使用API并为API付费。API提供商需要能够设置付款计划以适应各种API使用率。由于API是公开的，因此公开网关需要强大的安全功能。所有这些功能都需要自助服务，最重要的是，要简单。这一变化引入了一种全新的IT功能，现在称为API管理。为此，API的重点是作为向外部用户公开的某种功能；API和内部SOA服务之间的分界线已经变得清晰。随着API管理技术的成熟，API带来了易用性和自我管理等优势。于是，现在很多公司也想通过API技术和协议来暴露公司内部的服务，如下图所示。如今，SOAWeb服务和API之间的界限变得有些模糊，几乎不相关。它们的来源不同，它们向哪些用户公开，以及它们使用的数据模型，但许多SOA“服务”也可以描述为内部API。如今，术语API通常用于指代通过REST(HTTP/JSON)或Web服务(SOAP/HTTP)公开的任何接口。API通常按其范围进行分类，例如公共API或企业API。维护SOA计划的企业有时会为内部企业级API保留“服务”一词。术语API表示SOA的“服务公开”方面的演变。它使用更简单的协议，更善于暴露自己，包括开发者门户、策略控制和自我管理。5.微服务：另一种架构在考虑比较微服务和SOA之前，有必要了解微服务架构的含义。从根本上讲，微服务是构建应用程序的另一种架构。它们提供了一种更好的方法来解耦应用程序边界内的组件。事实上，如果将它们称为“微组件”，微服务的实际性质会变得更加清晰。应用程序的边界保持不变。如下图所示，虽然应用在内部被分解为不同的微服务组件，但从外部看应用是一样的。基于微服务的应用程序公开的API的数量和粒度应该与将API构建为孤立的应用程序没有任何不同。微服务中的第一个词“微”指的是内部组件的粒度，而不是暴露接口的粒度。在应用程序中逻辑分离组件并不是一个新概念。多年来，已经开发了许多不同的技术来实现整个应用程序的各个部分的干净分离。一个应用服务器可以在自身内部长期运行多个应用组件，如下图中间图所示。微服务更进一步，在这些应用程序组件之间提供绝对隔离。这些成为在网络上运行的独立进程，如下图右侧所示。为了实现解耦，您还应该对数据模型进行分区以与微服务保持一致。六、微服务的优势完全独立的微服务组件有助于实现完全自主所有权，带来以下优势：敏捷性和生产力：开发微服务的团队可以充分理解代码库。他们可以在更快的周期内独立于其他组件构建、部署和测试代码库。因为微服务组件只是Web上的另一个组件，所以您可以使用最适合您需要的功能的语言或框架来编写它，并使用最合适的持久化机制。这种方法显着减少了要编写的代码量并显着简化了维护。它确保团队可以根据需要采用新技术或现有技术的新版本，而不是等待应用程序领域的其余部分赶上来。对于微服务粒度的定义，微服务组件应该足够简单，以便在必要时在下一次迭代中重写。可扩展性：微服务开发团队可以在运行时独立于其他组件扩展微服务组件，从而实现资源的高效利用和对工作负载变化的快速反应。理论上，组件的工作负载可以卸载到最适合任务的基础设施。它还可以独立于其余组件进行重新定位，以充分利用网络位置。正如该领域的早期创新者和采用者所证明的那样，编写良好的微服务提供了非凡的按需可扩展性。这些微服务也处于最佳位置，可以充分利用弹性功能并经济高效地访问资源丰富的庞大云原生环境。弹性：独立的运行时提供独立于其他组件故障的即时弹性。通过谨慎的解耦设计，例如避免同步依赖和使用断路器模式，每个微服务组件都可以编写为满足其自身的可用性要求，而不是在整个应用程序域中引入这些要求。容器和轻量级运行时等技术使微服务组件能够快速独立地发生故障，而不是关闭所有不相关的功能区域。因此，它们以高度无状态的方式编写，以便可以立即重新分配工作负载，几乎可以同时启动新的运行时。这些好处的例子是组织转向微服务的一些最常见原因。7.选择微服务时要考虑的关键因素在决定是否将应用程序编写为微服务时，必须了解以下因素以确保您的组织已准备好处理它们：新技术模式。微服务是一种完全不同的构建应用程序的方法。因为它们在网络上，所以它们需要网络上的一整套新组件。一些支持技术已经存在，包括服务发现、工作负载编排、容器管理和日志框架。但是，您必须将它们放入一个有凝聚力的集合中，这需要大量的实验、技巧和经验。您必须确定什么构成了满足您需求的完美微服务设置，这可能与其他企业微服务不同。应用适用性。微服务并不适合所有应用程序。微服务社区当前的悖论之一是，具有高度内聚数据模型的相对简单的新应用程序采用了微服务的概念，但这样做并没有获得任何优势。此外，将复杂的现有应用程序重构为微服务架构需要大量工作。如果不在遗留或现代应用程序上，您什么时候会使用微服务？一个建议是在以传统方式编写的应用程序达到复杂性的拐点之前不要使用微服务。但是，要使这种方法起作用，您需要从一开始就编写一个结构正确的应用程序，并选择在正确的时间执行转换。不同的设计范式。微服务应用架构需要不同的设计方法。要从微服务方法中获得最佳结果，您可能需要：您还需要：如果您需要利用重要的快速可扩展性优势，请确保您的应用程序逻辑是无状态的。如果您将自己与下游组件分离，则需要熟悉异步通信潜在的微妙副作用。了解实施断路器模式的逻辑结果。认识到与进程内通信相比，HTTP/JSON通信的错误处理限制。考虑链式交互中的网络延迟。采用最终一致性模型，而不是您习惯的事务性交互。了解如何处理没有中央操作数据存储的事件源应用程序。DevOps成熟度。微服务需要成熟的交付能力。持续集成、部署和全自动测试都是必不可少的。编写代码的开发人员必须负责代码的生产部署。需要对构建和部署链进行重大更改，以便为微服务环境提供正确的关注点分离。8.微服务如何适应SOA环境和集成挑战如果我们的SOA心智模型侧重于集成方面，那么微服务是完全独立的。它是编写集成架构尝试连接的应用程序的替代方法，如图1所示。但是，如果我们的SOA心智模型侧重于将应用程序重新排列为对业务更有意义的“服务组件”，则服务组件图2右侧所示的组件可能看起来更像是微服务组件。微服务架构现在可以看作是SOA的演进。为了证明这一点，让我们对比一下这两个极端。首先，考虑一家对完全在线产品（如社交媒体或交易）有新想法的新创业公司。由于最初没有可用的现有架构，该公司不得不创建一套新的应用程序来解决业务的独特方面。然后，该公司可以选择将其部分非核心增值业务外包，并使用软件即服务(SaaS)应用程序来提供客户关系管理功能。在很大程度上，公司的景观可能是从头开始构建的。主要关注点可能是它能够在持续可用的环境（绿地概念）中以极少的停机时间快速添加新功能。公司可能希望根据不可预测的客户需求进行灵活扩展（即向上和向下扩展）。它可能希望实现24/7、高度可用的在线状态。微服务架构是许多公司环境的合理选择，如图6所示。新应用程序可能位于单个微服务框架内，该框架提供非功能性功能，例如可扩展性、可用性和资源管理。您可能希望低级集成问题很少，因为所有微服务组件和涉及的SaaS应用程序都将使用HTTP/JSONAPI等通用协议进行通信。SOA的一个关键目标是公开有价值的功能，以便它可以在整个企业中一起使用。在此示例中，良好实施的SOA和微服务架构之间的界限已经模糊。如果您想象一个SOA的完美实现，它可能看起来像这个例子，但只有新公司才能创建这种性质的架构。本文不探讨SOA“服务组件”在规模上是否与微服务组件相当。微服务组件的粒度以及它们的分组方式完全是另一个话题。现在让我们考虑相反的例子，一家大型、成熟的公司已经建立了数十年的IT环境。该企业可能是一家传统的银行或保险公司，并且可能拥有数百甚至数千个使用可追溯至数十年的技术构建的重要应用程序。业务内部可能有严格的划分，例如医疗保健、养老金和一般保险，或零售和投资银行业务。每个业务部门可能都有专用于其核心业务的独立应用程序。这些部门也可能有一套应用程序，例如人力资源，其中应用程序尽可能共享。公司可能通过收购竞争对手而发展壮大。在这种情况下，您会发现应用程序之间存在大量重复数据。根据最初为客户提供服务的公司，客户帐户可能分散在许多系统中。同一客户跨多个系统的关联可能不是很直观。这些后端应用程序通常很难在内部进行更改。在这种环境中，SOA的艰巨任务之一是将后端系统重新设想为对未来业务需求更有用的系统。集成挑战也很复杂。它可能需要集成工具（如图7所示）以允许从后端应用程序访问数据和功能，尽管存在协议、传输和数据格式方面的挑战。主要由于历史原因，这种集成方法通常被称为“SOA”，尽管它只解决了一半的SOA挑战。之所以将其标记为SOA，是因为集成是大??多数SOA计划解决的第一个领域。在许多情况下，这就是他们在可用资金范围内所做的一切。然而，企业需要通过SOA实现的另一个方面是将数据和功能转换为更多以业务为中心的功能。他们需要确定如何满足移动等新渠道的需求，这些渠道需要与传统应用程序完全不同的服务粒度。为实现这些方面，公司需要提供当前系统可能无法提供的一定级别的响应能力、可用性和可扩展性。必须编写应用程序以支持快速敏捷更改、提供极大的可扩展性和出色的可用性的风格来适应这些新渠道。很容易看出为这些新应用程序使用微服务架构的吸引力。如图7所示，大型企业最初使用微服务的重点是新的参与系统应用程序。SOA概念可能受到早期以集成为中心的工作的影响。因此，微服务通常被视为有别于SOA，提供更高的敏捷性、可扩展性和响应能力，但在许多情况下，这些取决于SOA集成阶段的基础工作。9.未来结合微服务、SOA和API从架构的角度来看，SOA有3个关键要素：深度集成使老化的系统能够公开其数据和功能，以便可以使用接口发现它；服务公开标准化并简化了这些接口向更广泛的受众公开的方式；服务组件进一步将接口组合成更有价值的业务资产；底层功能和数据作为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，简化了公开、消费、管理，在某些情况下还简化了业务功能的货币化。新的应用程序架构，包括微服务架构，允许开发人员密切关注业务逻辑，不断将基础架构细节推送到他们的环境中。这些开发风格的组合有助于以更敏捷的风格构建解决方案，帮助应用程序获得新水平的弹性可扩展性和容错能力。
