加入收藏 | 设为首页 | 会员中心 | 我要投稿 通化站长网 (https://www.0435zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > 建站资源 > 优化 > 正文

微服务的三种通信方法

发布时间:2019-08-31 07:39:05 所属栏目:优化 来源:佚名
导读:在微服务架构的世界中,我们通过一系列服务构建应用。集合中的每项服务都符合以下标准: 松散耦合 可维护和可测试 可以独立部署 微服务架构中的每个服务都解决了应用中的业务问题,或至少支持一个。一个团队对应用中的一个或多个服务负责。 微服务架构可以

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

  1. function asyncProcessMessage(name: string): Promise<string> { 
  2.     /** do some ServiceA business logic 
  3.         .... 
  4.         .... 
  5.     */ 
  6.     /** 
  7.      * send message to SNS that ServiceB is listening on 
  8.     */ 
  9.     let snsClient = new AWS.SNS() 
  10.     let params = { 
  11.         Message: JSON.stringify({ 
  12.             'data': 'our message data' 
  13.         }), 
  14.         TopicArn: 'our-sns-topic-message-broker' 
  15.     } 
  16.  
  17.     return snsClient.publish(params) 
  18.         .then((response) => { 
  19.             return response.MessageId 
  20.         }) 

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

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

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

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

事件驱动的通信

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

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

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

在形式上,这通常被称为“仅事件驱动的通信”。下面的代码和消息传递方法类似,但推送到SNS的事件是通用的。

  1. function asyncProcessEvent(name: string): Promise<string> { 
  2.     /** do some ServiceA business logic 
  3.         .... 
  4.         .... 
  5.     */ 
  6.     /** 
  7.      * call ServiceB to run some different business logic 
  8.     */ 
  9.     let snsClient = new AWS.SNS() 
  10.     let params = { 
  11.         Message: JSON.stringify({ 
  12.             'event': 'service-a-event' 
  13.         }), 
  14.         TopicArn: 'our-sns-topic-message-broker' 
  15.     } 
  16.  
  17.     return snsClient.publish(params) 
  18.         .then((response) => { 
  19.             return response.MessageId 
  20.         }) 

注意,我们的 SNS 主题消息是一个简单的 event 属性。每个服务都同意以这种格式将事件推送到代理,这使得通信松散耦合。服务可以监听他们关心的事件,并且提供为响应它们而需要运行的逻辑。

此模式使服务的耦合松散,因为事件中不包含任何有效负载。此方法中的每个服务都会响应事件的发生并运行其业务逻辑。在这里,我们通过 SNS 主题发送事件。也可以使用其他事件,例如文件上传或数据库行更新。

结论

这些是基于微服务的架构中所有可能的通信模式吗?当然不是。基于同步和异步模式进行通信的方式还有很多种。

但是这三个突出了支持同步与异步的优缺点。在选择时要考虑耦合因素,但也需要考虑开发和调试的具体情况与注意事项。

(编辑:通化站长网)

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