我正在寻找b/w SOA和Microservices体系结构风格的差异,并找到了一个很好的链接https://www.infoq.com/articles/boot-microservices。
上面写着:
作为“面向服务的体系结构”(,SOA )的继承者,微服务可以被分类在同一个“分布式系统”家族中,并且继承了SOA的许多相同的概念和实践。但是,它们的不同之处在于赋予个人服务的责任范围。在SOA中,服务可能负责处理广泛的功能和数据域,而微服务的一般指导方针是负责管理单数据域以及围绕该域的相应功能。
请帮助我理解:
单一数据域的含义(推荐用于微服务)。这是否意味着必须构建一个单独的Microservice来管理单个域/实体(以及与此单个域/实体相关联/复合域/实体)。因为如果是这种情况,那么即使实现基本功能(企业)应用程序,也会有许多(~20到~50)微服务。
编辑:我已经通过了链接微服务体系结构与SOA的区别,但它解释说,它在前两个原则上是相同的,在第三点上是不同的(在SOA中,服务共享模式和契约,而不是类),但那就是SOAP契约,但是b/w SOA (使用REST)和Microservices (主要是REST)之间的区别是什么?
发布于 2016-10-11 13:35:20
除了Sean所说的,当SOA在许多公司开始使用时,人们开始将微服务称为API。领域驱动设计的兴起也导致了这个词的使用增加。在目前的行业中,两者之间绝对没有区别,人们认为这是他们认为合适的。
你说得对,当你遵循原则上的哲学时,你最终会得到许多微型服务。在我看来,不管是SOA还是微服务,对独立服务的抽象应该只取决于用例、服务将如何部署以及有多少团队将并行地工作。如果服务跨主机部署(尽管容器和DC/OS框架正在解决这个问题),网络带宽的成本也会增加。如果它是快速变化的服务,拥有大量的移动部件,那么将一项大型服务分解为微服务将是有意义的。否则,我将避免过早的优化,并将功能打包到单个(或几个大型)服务中。
发布于 2016-10-11 13:02:48
我认为这是一个解释的问题:
我认为在SOA中,service不是一个物理过程(windows服务/应用程序域),而是一个逻辑边界.同样的规则也适用于SOA和Microservices中最小的自治组件。它们拥有一个或多个域属性/字段集合的一个或多个域属性/字段的集合(技术权威和数据所有者,这意味着它们是唯一可以更改该数据段状态的组件)。
现在,在运行时,我认为如果您不需要分发进程,那么您可以将它们都部署在同一个进程中(稍后需要扩展、分发组件以获得更好的性能).
讲得通?
发布于 2018-08-22 09:48:14
我发现微软给出了一个很好的解释:
微服务来源于SOA,但SOA不同于微服务体系结构。大型中央代理、组织级别的中央协调器和企业服务总线( Enterprise,ESB)等特性在SOA中是典型的。但在大多数情况下,这些都是微观服务社区的反模式。事实上,有些人认为“微服务体系结构是做得对的。”
https://stackoverflow.com/questions/39967784
复制相似问题