微服务与SOA不同

Question

我一直在寻找SOA和微服务架构风格的差异 并找到了一个很好的链接https://www.infoq.com/articles/boot-microservices

它说：
作为“面向服务的体系结构”（SOA）的后继者，可以将微服务分类到“分布式系统”的同一系列中，并继承SOA的许多相同概念和实践。但是，它们的区别在于对个别服务的责任范围。在SOA中，服务可能负责处理各种功能和数据域，而微服务的一般指导原则是它负责管理单一数据域以及相应的功能。域。

请帮助我理解：
单数据域的含义（推荐用于微服务）。 是说它必须构建一个单独的微服务来管理单个域/实体（以及与该单个域/实体相关的/复合域/实体）。如果是这种情况，那么即使实现基本功能（企业）应用程序也会有很多（~20到~50）微服务

编辑： 我已经浏览了Difference between Microservices Architecture and SOA链接，但它解释说，它在前两个原则上是相同的，在第三点上是不同的（在SOA中，服务共享模式和契约，而不是类），但这是SOAP契约，但后来有什么区别b / w SOA（使用REST）与微服务（主要使用REST）

Answer 1

我认为这是一个解释问题：

我认为在SOA中service不是物理过程（Windows服务/应用域），而是逻辑边界......并且相同的规则适用于SOA和微服务中最小的自治组件。他们拥有（技术权威和数据所有者，这意味着他们是唯一一个可以改变该数据的状态的组件）一个或多个域属性/字段的集合。

现在，在运行时，我认为如果您不需要分发流程，那么您可以将它们全部部署在同一个流程中（以后需要扩展，分发组件以实现更好的表现）...

有意义吗？

Answer 2

除了Sean所说的，当SOA开始在许多公司投入使用时，微服务就是人们开始称之为API的东西。领域驱动设计的兴起也导致该术语的使用增加。在目前的行业中，两者之间绝对没有区别，人们称它们看似合适。

当你说原则上遵循哲学时你会得到许多微服务时，你是对的。在我看来，无论是SOA还是微服务，对独立服务的抽象应仅依赖于用例，如何部署服务以及有多少团队将并行处理这些服务。如果跨主机部署服务，网络带宽的成本也会增加（尽管容器和DC / OS框架现在正在解决这个问题）。如果它是快速变化的服务，拥有大量的移动部件，那么将大型服务分解为微服务将是有意义的。否则，我会避免过早优化，并将功能打包到单个（或几个大）服务中。

Answer 3

关于“域”的问题，在我看来，我认为这是微服务的一个主要特征：微服务应该管理自己的功能域和数据模型。

假设您的公司内有产品目录应用程序。您可能不希望有许多其他应用程序访问目录持久层并且（再次）抽象目录模型，因为它会加强模型重构/演化。可能会导致这些应用程序之间出现并发问题，导致目录应用程序无法扩展 相反，您可能更愿意维护单个目录应用程序，这将暴露其他应用程序使用的Web服务API（例如REST端点）。

我已在此other related question“微服务= SOA - ESB”中阅读此评论。实际上，ESB与这种微服务特性不兼容：“智能端点和哑点”，这意味着当微服务需要另一个作为依赖时，它应该直接使用它而不需要任何处理管道的路由逻辑/组件。

最后，您可以根据Martin Fowler对微服务视频的介绍来了解这个cheat sheet。

Answer 4

SOA服务就是关于服务级别的组件化。 微服务就是服务水平上的功能组合。

对于不同的问题，它们是两种不同的解决方案。

Answer 5

我发现Microsoft做出了很好的解释：

  

微服务源自SOA，但SOA与微服务不同   建筑。大型中央经纪人，中央协调员等功能   在组织级别，而企业服务总线（ESB）是   在SOA中很典型。但是在大多数情况下，这些都是反模式   微服务社区。实际上，有人认为“   微服务架构是正确完成SOA的。”

Answer 6

用通俗易懂的术语讲，Monolithic类似于一个大容器，其中应用程序的所有软件组件都组装在一起并紧密包装。

面向服务的体系结构实质上是服务的集合。这些服务相互通信。通信可能涉及简单的数据传递，也可能涉及两个或多个协调某些活动的服务。需要一些将服务相互连接的方法。

微服务，又名微服务架构，是一种架构样式，将应用程序构造为围绕业务领域建模的小型自治服务的集合。

详细说明微服务和SOA之间的主要区别：

• 服务粒度：微服务架构中的服务组件通常是单用途的服务，可以真正非常好地完成一件事。借助SOA，服务组件的大小范围可以从小型应用程序服务到大型企业服务。实际上，在SOA中以大型产品甚至子系统为代表的服务组件是很常见的。

• 组件共享：组件共享是SOA的核心宗旨之一。实际上，组件共享就是企业服务的全部内容。 SOA增强了组件共享，而MSA则尝试通过“有界上下文”来最大程度地减少共享。有界上下文是指将组件及其数据耦合为具有最小依赖性的单个单元。由于SOA依靠多种服务来满足业务请求，因此基于SOA构建的系统可能会比MSA慢。

• 中间件与API层：微服务体系结构模式通常具有所谓的API层，而SOA具有消息传递中间件组件。 SOA中的消息传递中间件提供了MSA中未提供的许多其他功能，包括中介和路由，消息增强，消息和协议转换。 MSA在服务和服务使用者之间有一个API层。

• 远程服务：SOA体系结构依赖于消息传递（AMQP，MSMQ）和SOAP作为主要的远程访问协议。大多数MSA依赖于REST和简单消息传递（JMS，MSMQ）这两种协议，并且MSA中发现的协议通常是同质的。

• 异构互操作性：SOA通过其消息传递中间件组件促进了多种异构协议的传播。 MSA尝试通过减少集成选择的数量来简化体系结构模式。如果要在异构环境中使用不同协议集成多个系统，则需要考虑SOA。如果可以通过相同的远程访问协议公开和访问所有服务，则MSA是更好的选择。

Source

Answer 7

SOA与微服务不同。 SOA是功能部件，它需要一个消息服务中间件来进行组件之间的交互。为了节省您一些冗长的理论，让我使用最近使用的一些软件作为说明。

最近我有一个财务解决方案。该解决方案分为两个相互通信的子解决方案。

第一个被称为融合银行贸易创新（FBTI），而另一个被称为融合银行企业渠道（FBCC）。这些解决方案由单独的团队开发，并作为不同的解决方案出售，但可以作为一个解决方案一起工作。没有FBTI不能使用FBCC。 FBCC是客户与之交互的（客户端界面），而FBTI是银行与之交互的管理仪表板。

这两个功能之间的通信是使用消息服务中间件（例如IBM Message queue（MQ））实现的。 FBCC将消息发送到队列，并被FBTI挑选，这就是他们的通信渠道。

另一方面，微服务是基于任务的。组件之间的交互通过Web服务成为可能。我将以称为Prestashop电子商务解决方案的解决方案为例。

下载prestashop时，所有功能都分为单独的模块，例如，如果您想更改主页的标题，则有一个用于它的模块。单独有一个用于导航栏的模块，与页脚模块不同。该解决方案有300多个模块。还有诸如“管理产品”，“类别”，“购物车”等模块。请参见下图

此解决方案的模块化性质为其他prestashop合作伙伴提供了开发不同模块的渠道，这些模块可以替换prestashop中的默认模块，即您可以从合作伙伴处购买另一个模块来替换购物车，运输计算器之类的默认模块。

最后，SOA概念主要用于两个或多个解决方案之间的交互，而微服务概念则用于解决方案中两个或多个任务之间的交互。

Answer 8

微服务架构不是发明。诸如Amazon，Netflix和eBay之类的企业使用分而治之的策略在功能上将其整体应用程序划分为较小的单元，并解决了许多问题。随着这些公司的成功，许多其他公司开始采用这种方式作为重构其应用程序的通用模式。最终，该模式被称为微服务架构。 MSA中没有引入任何全新的内容。 MSA是SOA的逻辑演进，并支持现代业务用例。

SOA：

• 基于“尽可能多地共享”架构方法的思想
• 强调业务功能的重用
• 通用治理和标准
• 为其部署的所有服务的通用平台

微服务：

• 基于“尽可能共享”架构方法的思想
• 强调“有限上下文”的概念
• 放松治理，更加关注人员协作和选择自由
• 更多关注去耦