Architecture SOA和微服务能否共存？

通常有文档记录从整体构建基于微服务的体系结构。在基于SOA的体系结构中也可以使用微服务吗？

很多人将微服务视为SOA 2.0，所以如果我没有弄错你的问题，你肯定可以在一个项目中使用这两种体系结构…

简单地说，微服务是SOA的子集。您可以参考以下内容，它们仍然遵循SOA设计原则：

通过服务实现组件化

围绕业务能力进行组织

产品而非项目

智能端点和哑管道

分权治理

分散数据管理

基础设施自动化

失效设计

进化设计

如果您指的是实现ESB的SOA体系结构，那么使用ESB并不一定使您符合SOA，除非您在服务设计和建模期间遵守服务的服务特征/服务设计原则。因此，让我们分离服务和ESB。从根本上讲，ESB只是SOA的几个非功能性元素的实现

---

选择单一应用程序是从微服务开始的一个基本现象。然而，我坚信微服务可以应用到更多的业务场景中。

是的，您完全可以在同一环境中使用这两种体系结构。原因如下：

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

因此，在实践中，您经常会看到类似的情况—在相同的通用SOA中有许多应用程序体系结构样式：

---

希望这有所帮助。

SOA中的ESB用于根据需要执行协议转换/req-resp转换。由于微服务通常被视为智能端点哑管道，在微服务体系结构中，我们可以在哪里处理这些情况？Netflix在其API网关中执行协议转换，但它是否以这种方式遵循SEDP原则？SOA和微服务中的重要原则是减少耦合，避免状态更改的同步通信，因为方面消息传递可以帮助实现异步持久通信。。。你用什么工具不是重点。。。有意义吗？我想了解MSA中的哪个组件可用于处理req/resp转换。根据web中的大多数文章，它是API网关层，而不是ESB。以防万一，有人使用此层在MSA中执行相同的操作，他们是否违反了SEDP原则？这取决于上下文，消息传递不是万能的，有些场景需要使用同步通信（出于许多原因，如业务流、开发约束、现有代码和体系结构…）我看不出有什么理由不应该混合使用消息传递和同步通信，只要注意您正在引入的耦合方面，并在必要时制定一个过渡的缓解计划……我同意，仅使用ESB并不能保证良好的SOA设计的质量。然而，几乎一致认为ESB不用于MSA。如果没有，为什么？在这种情况下，MSA中的哪个组件/层可以处理X格式/协议转换等？在MSA中，我们遵循“智能端点和哑管道”，即转换/协议转换是各自的服务责任。换句话说，转换/翻译也可以作为一个可重用的实用程序服务。虽然MSA不推荐ESB，但同时也不要求删除ESB。在逻辑和紧密耦合的情况下，它会创建ESB与企业系统的依赖关系，您可以始终将ESB视为MSA的一部分。基本上，我们可以说，如果您正在从基于微服务的应用程序中交互任何外部服务或应用程序，那么如果传输协议不同，最好使用ESB。否则，如果集成系统/服务使用同构协议，则使用API网关。