SOA 和微服务可以共存吗？答案

【问题标题】：Can SOA and Microservices co-exist?SOA 和微服务可以共存吗？
【发布时间】：2017-01-28 05:00:45
【问题描述】：

通常记录从单体构建基于微服务的架构。是否也可以在基于 SOA 的架构中使用微服务？

【问题讨论】：

【解决方案1】：

是的，您绝对可以在同一个环境中同时拥有这两种架构。原因如下：

微服务架构在很大程度上受到 SOA 的启发，因此两者使用的原则自然非常相似，并且两者之间经常存在混淆。但是，您应该注意这些范例的范围不同。 微服务架构是一种以特定方式设计应用程序的方法，而 SOA 旨在为不同领域的多个异构应用程序（通常在企业环境中）之间的通信建立秩序，通过适当的中间件避免点对点通信，从长远来看，通常可以减少集成工作并提高投资回报率。 SOA 不仅是一种架构方法，而且提供了一种全新的方法来优化企业中的 IT 领域。它通常需要对流程和层次结构进行更改，因为 SOA 治理机构需要在某个时候就位以理想地执行企业策略。

因此，在实践中，您会经常看到这样的情况 - 同一个通用 SOA 中的许多应用程序架构样式：

希望这会有所帮助。

【讨论】：

基本上，如果您正在与基于微服务的应用程序交互任何外部服务或应用程序，最好使用 ESB，如果传输协议不同。否则，如果集成系统/服务使用同构协议，则使用 API 网关。

【解决方案2】：

简单来说，微服务是 SOA 的子集。你可以参考下面的9 characteristics of Microservice，他们还是遵循SOA设计原则的：

通过服务组件化

围绕业务能力组织

产品不是项目

智能端点和哑管道

去中心化治理

去中心化数据管理

基础设施自动化

为失败而设计

进化设计

如果您指的是实现 ESB 的 SOA 架构，那么使用 ESB 并不一定会使您符合 SOA，除非您在服务设计和建模期间遵守服务的服务特性/服务设计原则。因此，让我们将服务和 ESB 解耦。从根本上说，ESB 只是 SOA 中少数非功能性元素的一种实现。

选择单体应用程序是开始使用微服务的基本现象。但是我坚信微服务可以应用于更多的业务场景。

【讨论】：

我同意单独使用 ESB 并不能保证良好的 SOA 设计。然而，几乎一致的说法是在 MSA 中不使用 ESB。如果不是，为什么以及在那种情况下，MSA 中的哪个组件/层可以处理格式/协议转换等？
在 MSA 中，我们遵循“智能端点和哑管道”，它表示转换/协议转换是各自的服务职责。换句话说，转换/翻译也可以作为可重用的实用服务。尽管 MSA 不推荐 ESB，但同时它也没有强制要求移除 ESB。在导致 ESB 与您的企业系统依赖的逻辑和紧密耦合情况下，您始终可以将 ESB 视为 MSA 的一部分。

【解决方案3】：

很多人都将微服务与 SOA 2.0 联系起来，所以如果我没有正确回答您的问题，那么您肯定可以在一个项目中同时使用这两种架构...

【讨论】：

SOA 中的 ESB 用于根据需要执行协议转换/req-resp 转换。由于微服务通常被视为 Smart Endpoint-Dumb Pipes，在微服务架构中我们可以在哪里处理这些情况？ Netflix 在他们的 API 网关中执行协议转换，但它是否遵循 SEDP 原则？
SOA 和微服务的重要原则是减少耦合，避免状态变化的同步通信，因为消息传递可以帮助实现异步持久通信......你使用什么工具并不是重点...有意义吗？
我想了解 MSA 中的哪个组件可用于处理 req/resp 转换。根据 Web 中的大多数文章，它是 API 网关层，而不是 ESB。以防万一，有人在 MSA 中使用这一层来执行相同的操作，他们是否违反了 SEDP 原则？
这取决于上下文，Messaging 不是灵丹妙药，在某些情况下您将需要使用同步通信（出于多种原因，例如业务流程、开发约束、现有代码和架构......）我看不出你为什么不应该混合使用消息传递和同步通信，只要注意你所引入的耦合方面，并在需要时制定缓解计划以进行过渡......