微服务的三种通信方法

在微服务架构的世界中，我们通过一系列服务构建应用。集合中的每项服务都符合以下标准：

• 松散耦合
• 可维护和可测试
• 可以独立部署

微服务架构中的每个服务都解决了应用中的业务问题，或至少支持一个。一个团队对应用中的一个或多个服务负责。

微服务架构可以解锁许多好处。

• 它们通常更容易构建和维护
• 服务是围绕业务问题组织的
• 它们可以提高生产力和速度
• 它们鼓励自主、独立的团队

这些好处是微服务越来越受欢迎的一个重要原因。但有一些可能会破坏这些好处的坑。如果不小心掉进去了，你将得到一个不断产生技术债的架构。

微服务之间的通信就是一个坑，假如不提前考虑就会造成严重的破坏。

该体系结构的目标是创建松散耦合的服务，并且通信在实现这一目标中起着关键作用。在本文中，我们将重点关注在微服务架构中进行通信的三种方式，每一种都有其自己的利弊和权衡。

HTTP通信

选择服务如何相互通信时，最直接的方式往往是 HTTP。事实上，我们可以提出一个案例，即所有通信渠道都来自这个渠道。但是除此之外，服务之间的 HTTP 调用是服务到服务通信的可行选择。

如果我们的架构中有两个服务，它可能看起来像这样： ServiceA 可以请求并调用 ServiceB 来获取另一条信息。

function process(name: string): Promise<boolean> { 
    /** do some ServiceA business logic 
        .... 
        .... 
    */ 
    /** 
     * call ServiceB to run some different business logic 
    */ 
    return fetch('https://service-b.com/api/endpoint') 
        .then((response) => { 
            if (!response.ok) { 
                throw new Error(response.statusText) 
            } else { 
                return response.json().then(({saved}) => { 
                    return saved 
                }) 
            } 
        }) 
} 

这是一段很容易理解的适合微服务架构的代码。 ServiceA 提供了一个业务逻辑。它运行其代码然后调用 ServiceB 来运行另一个业务逻辑。在这段代码中，第一个服务在返回之前完成等待第二个服务完成。

这里有两个服务之间进行同步的 HTTP 调用。这是一种可行的通信模式，但它确实在两种服务之间建立了耦合。

另一个选择是异步 HTTP。这可能是这样的：

function asyncProcess(name: string): Promise<string> { 
    /** do some ServiceA business logic 
        .... 
        .... 
    */ 
    /** 
     * call ServiceB to run some different business logic 
    */ 
    return fetch('https://service-b.com/api/endpoint') 
        .then((response) => { 
            if (!response.ok) { 
                throw new Error(response.statusText) 
            } else { 
                return response.json().then(({statusUrl}) => { 
                    return statusUrl 
                }) 
            } 
        }) 
} 

这种变化是微妙的。现在， ServiceB 不返回 saved 属性，而是返回一个 statusUrl。这意味着此服务现在正在接收来自第一个服务的请求，并且立即返回一个URL。此 URL 可用来检查请求的进度。

将两种服务之间的通信从同步转换为异步，第一个服务不再停留等待第二个服务完成，然后再返回其工作。

通过这种方法可以使服务彼此隔离，并且耦合松散。

缺点是需要在第二个服务上创建额外的 HTTP 请求，它从外部进行轮询，直到请求完成。这也引入了客户端的复杂性，因为必须检查请求的进度。

但是，异步通信允许服务直接保持松散耦合。

消息通信

另一种通信模式是基于消息的通信。

与HTTP通信不同，所涉及的服务不直接相互通信。相反，服务将消息推送到其他服务订阅的消息代理。这消除了许多与 HTTP 通信相关的复杂性。

它不需要服务知道该如何相互交流，它消除了直接相互调用的服务需求。相反，所有服务都知道消息代理，并且它们将消息推送到该代理。其他服务可以订阅代理中自己关心的消息。

（编辑：ASP站长网）