soa - 微服务与 SOA 不同

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

去年关闭。




Improve this 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

除了 Sean 所说的之外，当 SOA 开始在许多公司中使用时，人们开始调用 API 微服务。领域驱动设计的兴起也导致该术语的使用增加。在目前的行业中，两者完全没有区别，人们认为合适就可以了。

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