Architecture 面向服务的体系结构与微服务

？我看了很多文章，仍然不理解

SOA

vs

Microservices

。我仍然认为两者是一样的。

---

有人能帮我举个例子吗？或者用外行的话来说。

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

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

SOA适合于需要集成不同应用程序（例如：人力资源、计费、物流等）的企业环境。这种集成必须通过使用

服务接口来实现，这就是为什么它是面向服务的

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

有一些架构模式可以帮助企业实现SOA生态系统，但最常见的是ESB-企业服务总线。市场上有一些大公司的产品实现了这种模式，例如：Oracle的Oracle服务总线、IBM的IBM集成总线（Oracle有一系列产品，专注于面向服务的体系结构，称为Oracle SOA套件）

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

微服务
微服务是一种体系结构风格，旨在将应用程序开发为一套小型、独立的服务

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

这种方法的好处是什么？嗯：

因为它们很小，所以更易于维护
它们是松散耦合的（当然，这取决于您如何设计生态系统）
它们是可独立部署的，这意味着您可以扩展应用程序的一部分，而无需扩展另一部分
当然，也有一些缺点，所以不要相信有人说每个应用程序都应该以这种体系结构风格开发：分布式系统增加了复杂性（！！！）

微服务体系结构样式并不定义微服务之间的交互方式。它可以像SOA一样，通过HTTP请求、消息传递、文件等实现。此外，它没有定义一个应用程序（不必与微服务混淆）如何与另一个应用程序交互——为此，我们可以研究SOA的企业范围

要澄清这些语句在微服务体系结构中的含义：


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

区别
SOA是一个企业范围的概念，旨在通过松散耦合的服务接口将应用程序彼此集成，而微服务是一个应用范围的概念，旨在将一个应用程序开发为一套小型服务

这是我对这两个概念的观点，当然，也可能会有分歧
在微软和IBM介入之前，微服务就是SOA的本意，它的膨胀让SOAP（糟糕）和XML（糟糕）以及UDDI（更糟糕）和UML（不必要）都无法识别。真正的区别在于实现，而不是概念

“加上变化加上我选择的”

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

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

SOA和微服务之间的另一个主要区别是SOA是标准驱动的，而微服务的定义相当糟糕。这不是批评，而是特色。正因为如此，PHP程序员尽管没有任何有用的技能，但仍然有可能表现出相关性

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


*
其他消息传递系统仍然存在，但大部分都是卡夫卡
**
如果你没有使用它，那是因为你的应用程序很琐碎，而不是因为你有一个不需要它的非琐碎应用程序
***
事件源并不排除REST的使用，您始终可以使用通过队列调用服务的事件处理程序使您的服务适应事件总线。但是，您正越来越接近旧的SOA模型
非常感谢马修斯。很有帮助