面向服务的架构与微服务

Question

？看了很多文章，还是看不懂SOA vs Microservices。我仍然认为两者是一样的。 谁能帮我举个例子或用外行的话。

Answer 1

我想 SOA 对不同的人意味着不同的东西，所以很难说明微服务和面向服务的架构之间的所有差异，这对我们所有人来说都是正确的，所以我会说一下我对这两种方法的理解.

SOA

首先：在我的理解中，SOA 是一种软件架构风格（面向服务的架构）。

SOA 适用于需要集成不同应用程序（例如：人力资源、计费、物流......）的企业环境。这种集成必须通过使用 service interfaces 来实现 - 这就是它面向服务的原因。

由于这些服务接口使用通用的通信标准，SOA 可以促进应用程序之间的解耦，使开发更容易、更快捷。 SOA 没有定义在集成系统时使用哪种协议，但最常见的可能是通过 HTTP 请求和消息传递。此外，它没有定义它必须是同步还是异步服务接口，您可以使用同步、异步或两者兼而有之。

有一些架构模式可以帮助企业实施 SOA 生态系统，但最常见的是 ESB - 企业服务总线。市场上有一些大玩家拥有实现这种模式的产品，例如：Oracle 的 Oracle Service Bus、IBM 的 IBM Integration Bus（Oracle 有一系列产品专注于面向服务的架构，称为 Oracle SOA Suite）。

总结：SOA 是一个企业范围的概念，它使现有应用程序能够通过松散耦合的接口相互通信，该接口可以使用多种协议、消息传递、同步和异步接口，因此一个应用程序可以公开其功能以在其他应用程序中重用。

微服务

微服务是一种架构风格，旨在将应用程序开发为一组小型独立服务。

看到了吗？它说必须将一个应用程序开发为一组小型服务。

这种方法有什么好处？嗯：

1. 由于它们很小，因此更易于维护
2. 它们是松散耦合的（当然，这取决于您如何设计生态系统）
3. 它们是可独立部署的，这意味着您可以扩展应用程序的一部分，而无需扩展另一部分。

当然，也有一些缺点，所以不要相信有人说每个应用程序都应该以这种架构风格开发：分布式系统增加了复杂性(!!!)

微服务架构风格没有定义微服务如何相互交互。它可以像 SOA 一样通过 HTTP 请求、消息传递、文件等。此外，它没有定义一个应用程序（不要与微服务混淆）如何与另一个应用程序交互 - 为此，我们可以研究企业范围SOA 的。

澄清这些陈述在微服务架构中的含义：

• 应用程序 - 一套小型、独立、松散耦合的服务
• 微服务 - 套件的服务

区别

虽然 SOA 是一个企业范围的概念，旨在通过松散耦合的服务接口将应用程序相互集成，但微服务是一个应用程序范围的概念，旨在将一个应用程序开发为一组小型服务。

这是我对这两个概念的观点，当然，可能存在分歧

Answer 2

微服务是 SOA 在微软和 IBM 参与之前的本意，它用 SOAP（这很糟糕）和 XML（这很糟糕）和 UDDI（更糟糕）和 UML（这是不必要）。真正的区别在于实现，而不是概念。

"plus ça change plus c'est la meme selected"

一个很大的区别是“ESB”，即“企业服务总线”，它基本上是一个跨越整个组织的消息传递系统。我们仍然使用这个概念，但现在我们称它为 Kafka，它可以正常工作*。

如今，微服务主要服务于基于 REST 的 API，因为事件驱动架构已经演变为 DDD，尽管在所有非平凡的应用程序中都需要它，但对于大多数 PHP 和 Python 程序员来说，这太难理解了**

SOA 和微服务之间的另一个主要区别是 SOA 是由标准驱动的，而微服务的定义相当不明确。这不是批评，而是特色。因此，尽管没有有用的技能，PHP 程序员仍有可能显得相关。

最后的区别是焦点。 SOA 专注于接口，而微服务专注于“微”位——将单体巨结构分解为更小更易于管理的组件。在很多方面，与大多数 OO 语言相比，微服务更接近于纯 OO - 特别是如果您有一个不平凡的应用程序（即使用事件源而不是 REST API 的应用程序***）。

• * 其他消息系统仍然存在，只是，但大多数情况下它只是 Kafka
• ** 如果您不使用它，那是因为您的应用程序很琐碎，而不是因为您有一个不需要它的非平凡应用程序。
• *** 事件溯源并不排除使用 REST，您始终可以使用通过队列调用您的服务的事件处理程序使您的服务适应事件总线。但是，您会越来越接近旧的 SOA 模型。