微服务与SOA的区别是什么？

在这一点上，微服务已经有好几年的上升趋势。这是有道理的，因为最著名的微服务成功案例属于游戏中最大的科技巨头——Netflix、亚马逊、Uber和eBay。

通过采用微服务，那些大型科技公司突然变得更加灵活。因此，通过提高部署速度和发布频率，它们可以更快地扩展。看到公共领域的潜在发展，开发人员开始将他们的单片应用程序解耦，并进行到云的迁移。

微服务的前身面向服务的体系结构（SOA）并不是很好。SOA与微服务一样，旨在将组织从monolith应用程序引起的问题中解放出来。然而，如果没有我们今天拥有的工具和既定的最佳实践，SOA在很大程度上被认为是失败的。

在本文中，我们将研究面向服务的体系结构与微服务，并讨论SOA作为一个巨大失败的名声是如何不准确的。

如果这是您第一次遇到整个SOA与微服务之争，我们建议您首先查看我们的微服务概述。

否则，请继续阅读，进一步了解SOA和微服务之间的异同。

面向服务的体系结构与微服务：SOA经常被一个糟糕的说辞困住

当SOA在20世纪90年代出现时，它被认为是一种革命性的创新。

后来，当微服务出现时，开发人员对此持怀疑态度，许多评论家认为必须定义这两种体系结构之间的关键区别，倾向于将不熟悉的内容进行分类。

因此，开发人员开始比较SOA架构和微服务这两种方式，这导致了对微服务的广泛抵制。毕竟，SOA未能解决它承诺要解决的所有问题。

老实说，SOA是替罪羊。事实上，SOA架构面临的主要问题是人。或者更确切地说，是人们在实施过程中所犯的错误，其中有些错误包括：

• 未能使服务与业务目标保持一致
• 在确保文化能够处理SOA之前采用SOA。
• 在理解使用分布式应用程序时的复杂性和范围之前，先实施SOA策略。
• 在没有战略计划的情况下工作。

这些例子只是众多SOA计划失败原因中的一小部分。

然而，由多个面向功能的服务组成的松耦合应用程序的思想从根本上说是正确的。

多年来，开发人员一直在不断完善这一理念，最终以“微服务”这个时髦词重新命名

事实是，微服务是SOA架构的一种形式，因此，它们的共同点比您最初设想的要多。但是，这种联系不应该成为你决定采用微服务的因素。毕竟，根据上世纪90年代可用系统的技术能力来做决定并没有多大意义。这就像避免使用移动工具，因为十年前它们还不那么可靠。

今天的微服务是从每一个SOA成功和失败中吸取教训的产物。开发人员和架构师能够吸取这些教训，并利用它们对微服务进行微调，使之能够兑现SOA无法兑现的承诺。

什么是SOA？

SOA或面向服务架构（service-oriented architecture）是一种架构设计风格，旨在将单片应用程序分解为一系列应用于特定业务目标的较小模块。

如果你认为SOA听起来很像微服务，那你绝对是对的。

然而，SOA模块并不是由它们的大小来定义的。

相反，它们的范围从小型应用程序服务到大型企业服务。SOA依赖消息传递协议（如AMQP或SOAP）在服务之间进行通信。

为什么SOA失败了？

SOA无法完成解决与单片体系结构相关的各种问题的任务。

在某些方面，SOA是一块巨石。虽然与微服务一样，SOA是由几个较小的服务组成的，但是SOA体系结构仍然是相对粗粒度的，服务之间具有高度的依赖性。

因此，soa容易出现许多与单片体系结构相同的问题，包括在开发人员进行更改时强制进行应用程序范围内的重建的相互依赖性。

此外，SOA中的通信通过企业服务总线或ESB进行。ESB采用的是单片结构，其特点是通信速度慢，最终往往成为单点故障。

从本质上讲，SOA没有在部署速度、问题解决、生产率等方面提供足够的显著改进来证明风险的合理性。

尽管如此，SOA还是为微服务铺平了道路，并代表了一块踏脚石，将我们从低效的整体带到了今天灵活、可伸缩的体系结构。

什么是微服务？

微服务的简单定义是；松散耦合、可独立部署的服务的集合。每个服务都是为执行特定的任务或功能而设计的，并且包含执行该功能所必需的所有组件。

在微服务体系结构中发现的所有服务都是细粒度的，并且使用诸如REST之类的语言无关api彼此通信。这里的好处是，开发人员可以使用最适合该工作的语言来开发服务，而api则在幕后工作，为用户创建一个有凝聚力的前端体验。

这种灵活性解决了许多与monolithis和SOA相关的最大问题，提供了SOA无法实现的快速部署、可伸缩性和容错性。

微服务和SOA有什么相似之处？

面向服务的体系结构类似于微服务，因为它们都是专注于执行一个特定功能的服务集合。

两者的范围都比一个完整的整体架构小，而且都需要一种内部文化，在这种文化中，分散化和跨职能协作是规范。

SOA和微服务还让开发人员可以自由地使用他们选择的任何编程语言。

这允许他们选择最适合该服务用例的编程语言。

SOA与微服务：关键区别

微服务和SOA都是面向服务的体系结构，旨在解决与单片体系结构相关的许多问题。虽然它们有一个共同的目标，但微服务和SOA有一长串的不同之处。

下面是您应该注意的SOA和微服务的快速比较：

数据存储

SOA类似于单片应用程序，因为它们通常共享一个关系数据库。随着应用程序的增长，它的数据特征和处理需求可能是异构的。

此时，一刀切的数据解决方案已不再理想。相反，在微服务体系结构中，每个服务都可以利用自己的数据存储，允许开发人员选择最符合服务所使用数据的存储和处理要求的存储类型。

规模和范围

微服务专注于实现一个功能并很好地执行该功能。因此，与SOA服务相比，微服务在规模和范围上往往要小得多。这为新人才的入职带来了巨大的好处。

服务易于理解且独立。因此，新开发人员不需要了解所有应用程序的整个范围。相反，SOA服务可以由具有许多相互依赖关系的多个功能、单个数据库和ESB组成。这就要求新的人才不仅要充分理解服务，还要充分理解应用程序的相互依赖性。

通信

微服务和SOA服务的通信方式也非常不同。微服务通过与语言无关的协议进行通信，通常是通过网络。虽然这会增加远程呼叫的数量，进而增加开销，但它会导致通信速度更快，具有很高的抗故障能力。

另一方面，SOA通过ESB进行通信。虽然这会降低开销，但会降低通信速度。它本身也是一个单点故障，有可能导致整个应用程序中的所有通信中断。

松耦合和高内聚

耦合性和内聚性差异的原因与上述的规模、范围和沟通差异有关。微服务具有极低的耦合性和高内聚性。它们通过关注单个业务功能来实现这一点，因为处理其功能、消息传递和数据存储（包括部署它们所需的操作系统）所需的所有组件都封装在一个容器中。这就产生了可以独立构建、部署和测试的服务。

微服务低耦合和独立设计的另一个主要优点是，一个服务中的故障不太可能导致系统中其他地方的故障。此外，当确实发生错误时，很容易找到并隔离故障源。

这些特性在部署时非常有用，因为错误更新可以很容易地回滚、解决和重新部署。

SOA服务的范围要大得多，具有更多的相互依赖性，通信和数据存储在服务之外处理。这需要重建和重新部署整个应用程序，从而导致部署时间缓慢和级联失败。

结论是什么：SOA与微服务？

最终，这种面向服务的体系结构与微服务的思想并没有太大的影响力。

微服务在避免早期困扰SOA的问题方面取得了长足的进步。但他们拥有的技术优势，比90年代的尖端技术有了飞跃性的进步。当然，今天的开发人员可以回顾过去，从之前的开发人员犯下的错误中吸取教训。

也就是说，启动微服务迁移仍然需要许多与推出SOA计划相同的文化和规划需求。考虑采用微服务的组织必须在过早介入之前进行尽职调查。