MICROSERVICES - 它们之间的通信

Question

我有一个关于微服务架构的问题。我正在设计一个基于微服务的系统。我读过几篇文章，我想我理解这个想法。但是，我不知道微服务应该如何相互通信，而它们有不同的业务职责...... 我的意思是，如果我有一个预订火车票的系统，我会将后端应用程序划分为模块：

• 客户端（登录、注销、注册）
• 预订（为用户预订火车座位，为用户获取所有预订）
• 连接详情 （搜索连接，获取连接详情）
• 火车 （关于火车的信息——座位号、等级等）

现在，我只能认为，如果用户搜索连接模块 ConnectionsDetails 与火车模块通信并询问特定的火车详细信息。但是其他微服务如何通信呢？如果用户想登录 - 她/他直接询问客户模块，如果她/他想获得她的所有预订 - 直接询问预订模块等......

所以我的问题是，如果模块做不同的事情，它们应该如何通信？如果我的问题是微不足道的或愚蠢的，我很抱歉，我只是从微服务开始。

编辑： 我并不是说我可以使用什么工具进行交流。我的问题是关于逻辑的。在我展示的示例中，如果客户端可以直接询问另一个微服务，为什么一个微服务可以询问另一个微服务？正如我之前所说，如果他们做不同的事情，他们应该如何沟通（关于他们应该确切地问对方什么）？

Answer 1

找到正确的上下文、边界和通信渠道是微服务架构中最困难的部分之一。它是关于找到您需要的数据、关系如何以及哪个服务负责什么（负责意味着唯一允许更改它的人）。看看Blog from Martin Fowler。

微服务不是模块。每个服务都应该是关于开发和部署的独立服务。是的，他们可以相互交流，但客户也可以单独与他们交流。微服务方法也是关于使用正确的工具来解决问题。所以每个服务都可以用不同的编程语言来实现。他们可以使用不同类型的存储，如 RDMBS、NoSQL 或键值存储。它们将单独缩放 - ConnectionsDetails 的实例很多，而 Reservations 的实例更少，例如

如果一项服务不可用会怎样？每个服务都应该尽可能容错，并在没有其他可能的情况下尝试优雅地减少它的服务。您应该考虑通过选择正确的边界、使数据独立并可能引入缓存来最小化服务之间所需的通信。不要忘记CAP theorem，微服务方法使其更加可见。这里有一些slides about resilience 可能会有所帮助。不要在服务之间共享同一个数据库或复制所有内容。

“如果模块做不同的事情，它们应该如何通信？”。您应该选择一种独立于语言的通信方式，并根据您的问题选择同步或异步方法。作为一种独立于语言的格式，JSON 或 XML 是最常见的。同步通信可以基于REST，异步通信基于消息传递。身份验证（“客户端”）通常是 REST 服务，通过电子邮件发送预订的票更多的是消息驱动的异步服务。

Answer 2

我认为这是关于经典 SOA 与微服务的主要问题。

我猜你可以找到许多相反的答案。

所以恕我直言： 如果在您的架构服务中相互通信，它们就不是微服务，因为它们之间存在依赖关系。

如果每个微服务都具有所有需要的功能（或者说组件）并且不相互依赖或相互通信，那么它们就是微服务。

因此，在您的示例中，您有 4 个组件。 客户、预订、连接详情、火车。

但是，微服务可能不需要完全匹配它们。 正如你所说的“如果用户搜索连接”...... 所以“搜索连接”是一种微服务，它包括所有需要的组件（客户端、连接详细信息、火车）并且是独立的。

最后，组件（而非微服务）如何相互通信取决于您。借助微服务，您可以奢侈地使用直接 POJO，而无需任何转换、协议、传输层。 或者，您可以让沟通更加正式，这会让您更接近传统 SOA 而不是微服务。