设为首页 - 加入收藏 酒泉站长网 (http://www.0937zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 证实 什么
当前位置: 首页 > 运营中心 > 建站资源 > 优化 > 正文

微服务的三种通信方法

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

?微服务的三种通信方法

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

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

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

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

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

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

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

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

HTTP通信

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

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

  1. function?process(name:?string):?Promise?{?
  2. ????/**?do?some?ServiceA?business?logic?
  3. ????????....?
  4. ????????....?
  5. ????*/?
  6. ????/**?
  7. ?????*?call?ServiceB?to?run?some?different?business?logic?
  8. ????*/?
  9. ????return?fetch('https://service-b.com/api/endpoint')?
  10. ????????.then((response)?=>?{?
  11. ????????????if?(!response.ok)?{?
  12. ????????????????throw?new?Error(response.statusText)?
  13. ????????????}?else?{?
  14. ????????????????return?response.json().then(({saved})?=>?{?
  15. ????????????????????return?saved?
  16. ????????????????})?
  17. ????????????}?
  18. ????????})?
  19. }?

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

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

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

  1. function?asyncProcess(name:?string):?Promise?{?
  2. ????/**?do?some?ServiceA?business?logic?
  3. ????????....?
  4. ????????....?
  5. ????*/?
  6. ????/**?
  7. ?????*?call?ServiceB?to?run?some?different?business?logic?
  8. ????*/?
  9. ????return?fetch('https://service-b.com/api/endpoint')?
  10. ????????.then((response)?=>?{?
  11. ????????????if?(!response.ok)?{?
  12. ????????????????throw?new?Error(response.statusText)?
  13. ????????????}?else?{?
  14. ????????????????return?response.json().then(({statusUrl})?=>?{?
  15. ????????????????????return?statusUrl?
  16. ????????????????})?
  17. ????????????}?
  18. ????????})?
  19. }?

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

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

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

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

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

消息通信

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

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

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章