面向服务的架构与微服务

时间:2021-03-23 17:55:08

标签: architecture microservices soa

?我看了很多文章,还是看不懂SOA vs Microservices。我仍然认为两者是一样的。 有人可以帮我举个例子或用外行的话说。

2 个答案:

答案 0 :(得分:3)

我想 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 是一个企业范围的概念,旨在通过松散耦合的服务接口将应用程序相互集成,而微服务是一个应用程序范围的概念,旨在将一个应用程序开发为一套小型服务。

这是我对这两个概念的看法,当然,可能存在分歧

答案 1 :(得分:3)

在 Microsoft 和 IBM 介入之前,微服务就是 SOA 的本意,并且使用 SOAP(这很糟糕)和 XML(这很糟糕)以及 UDDI(这很糟糕)和 UML(这是一个糟糕的不必要)。真正的区别在于实现,而不是概念。

<块引用>

“加上 ça change 加上 c'est la meme 选择”

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

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

SOA 和微服务之间的另一个主要区别是 SOA 是标准驱动的,而微服务的定义相当糟糕。这不是批评,而是特色。正因为如此,PHP 程序员可能在没有实用技能的情况下仍然看起来很相关。

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

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