首页 文章

微服务与SOA不同

提问于
浏览 次
4

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

它说：
作为"Service Oriented Architecture"（SOA）的后续产品，微服务可以归类于"distributed systems"的同一系列，并继承了许多相同的SOA概念和实践 . 但是，它们的区别在于对个别服务的责任范围 . 在SOA中，服务可能负责处理各种功能和数据域，而微服务的一般准则是它负责管理 single data domain 以及该域周围的相应功能 .

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

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

soa microservices

6 回答

  • 0

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

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

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

    合理？

    回复于
  • 0

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

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

    回复于
  • 3

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

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

    我在这篇other related question "Microservices = SOA - ESB"中读过这篇评论 . 实际上，ESB与这种微服务特性不兼容："Smart endpoints and dumb points"这意味着当微服务需要另一个作为依赖时，它应该直接使用它而不需要任何处理管道的路由逻辑/组件 .

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

    回复于
  • 3

    SOA服务就是关于服务级别的组件化 . 微服务就是关于功能组合的全部服务水平 .

    它们是针对不同问题的两种不同解决方案

    回复于
  • 0

    我找到了一个很好的解释Microsoft：

    微服务源自SOA，但SOA与微服务架构不同 . 大型中央代理，组织级别的中央协调器和企业服务总线（ESB）等功能在SOA中是典型的 . 但在大多数情况下，这些都是微服务社区中的反模式 . 事实上，有些人认为“微服务架构是正确的SOA” .

    回复于
  • 1

    enter image description here

    通俗地说，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

    回复于

相关问题