微服务的三种通信方法

如果我们的应用在 Amazon Web Services 中，可以用简单通知服务(SNS)作为消息代理。现在 ServiceA 可以将消息推送到 ServiceB 监听的 SNS 主题。

function asyncProcessMessage(name: string): Promise<string> { 
    /** do some ServiceA business logic 
        .... 
        .... 
    */ 
    /** 
     * send message to SNS that ServiceB is listening on 
    */ 
    let snsClient = new AWS.SNS() 
    let params = { 
        Message: JSON.stringify({ 
            'data': 'our message data' 
        }), 
        TopicArn: 'our-sns-topic-message-broker' 
    } 
 
    return snsClient.publish(params) 
        .then((response) => { 
            return response.MessageId 
        }) 
} 

ServiceB 侦听 SNS 主题上的消息，当收到一个关心的消息时，就会执行它的业务逻辑。

这引入了它自己的复杂性。请注意，ServiceA 不再接收状态 URL 检查进度。这是因为我们只知道消息已经被发​​送，而不知道 ServiceB 是否已经收到了它。

这可以通过许多不同的方式解决。一种方法是将 MessageId 返回给调用者。可以用它来查询 ServiceB，它将存储它收到的消息的 MessageId。

注意，使用此模式的两个服务之间仍然存在一些耦合。例如，ServiceB 和 ServiceA 必须就消息结构的定义以及其中包含什么达成一致。

事件驱动的通信

最后一种模式是事件驱动模式。这是另一种异步方法，它看起来完全消除了服务之间的耦合。

与消息传递模式不同，事件驱动方法不需要服务必须知道公共消息结构。服务之间的通信通过各个服务产生的事件进行。

此处仍然需要消息代理，因为各个服务会将其事件写入其中。但是与消息方法不同，消费服务不需要知道事件的细节，它们对事件的发生做出反应，而不是产生能会或可能不会传递的信息。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!