专栏首页物流IT圈使用消息系统集成和扩展微服务

使用消息系统集成和扩展微服务

  服务之间交互的风格有两种:同步和异步。所谓同步交互,服务调用者会发出一个调用请求,并且堵塞等到操作完成得到响应,HTTP协议是一个很好的同步交互案例,通常是以请求/响应的同步风格为主;而异步交互风格,服务调用者发出一个请求,但是不会等待被调用的服务操作的完成,也就是不会等到接受到响应,而是只要请求一旦确认被接受,服务调用者就继续做其他事情,这种交互典型是发布/订阅(publish/subscribe)风格,服务调用者也就是消费者不再是直接调用另外一个服务的操作,而是产生了一个事件,希望赶兴趣的消费者能够响应react。

orchestration与choreography区别

这两种都是消息系统的不同风格,都属于异步方式的一种。

orchestration是一种类似管弦乐编曲一样的业务流程调用风格,也就是一个 服务A和一个服务B交互,如果服务A负责调用服务B,这就是orchestration;而如果是服务B只订阅了相关事件,这就是choreography,一种类似舞蹈编排的调用风格。

在服务orchestration中,会存在一个中央实体(如服务A自己),它会知道其他哪些服务被调用,而使用choreography方式,这种职责委托给独立的服务,它们只负责订阅感兴趣的事件就可以了。

orchestration业务流程风格

在微服务项目中,服务代码经常修改,orchestration方式的服务交互属于点对点的异步交互,这样微服务之间造成相互依赖,导致修改一个服务,影响一个业务流程上的其他服务调用。如下图:

这种方式在实现跨几个服务的业务事务时增加了很多复杂性。因为业务事务跨几个服务,处理失败变得非常小心,这个服务失败会对整个业务流程事务有影响吗?如果有,那么事务就得退出,返回一个有意义的错误给调用者,另外一方面,当系统从失败中恢复时,我们需要让这个业务事务继续成功处理完成。

orchestration在消息系统实现中是采取队列方式,虽然在业务上造成服务之间依赖,但是由于队列方式比较易于扩展,只要增加队列的消费服务的数量,队列会在这多个消费者之间做负载平衡。

上图中Customer服务通过Email队列发送消息给Email服务,通过Loyalty Point队列发送给Loyalty Point服务,Email服务可以有多个,Loyalty Point服务也有多个实例,队列会在这些多个服务实例之间做负载平衡。

choreography的发布/订阅风格

choreography编舞风格能够限制业务事务的边界,上游服务发送事件,而下游服务订阅这些事件,这就提供足够的隔离,如下图通过这种事件流方式实现微服务集成:

这种与orchestration不同在于:以客户注册过程来举例,在orchestration业务流程方式下,当一个新的客户注册,客户服务会实现整个客户的创建流程:保存新客户的细节资料,调用下游其他服务,这样客户会收到一个欢迎的电子邮件,获得他的第一个成员积分点。

而在基于事件的choreography风格下:新客户只是发出创建事件customer_created 给下游服务,如下:

app.post('/', function(req, res) {   customers.push(req.body);   var event = { 'type':'customer_created', 'data':req.body };   publish(event);   res.sendStatus(200); });

客户创建的事务就局限在了客户服务中,只是简单地发布新的客户事件并让全世界都知道,任何下游服务能够订阅这个事件流,当这种事件一旦被发布,订阅者会异步收到通知,比如email服务:

http.listen(3001, function() {   eventStore.subscribe('customer_created',   function(customer) {     sendWelcomeEmail(customer);   });   console.log('email service listening on *:3001'); });

Email服务订阅了客户创建的事件。

choreography风格在消息系统中使用topic实现发布/订阅模型,如下图:

如果我们只是增加Loyalty Point服务实例,并不能扩展处理能力,因为这两个Loyalty Point服务会收到相同的事件。

所以,处理这种事件流的发布/订阅方式我们可以采取分布式日志如Apache Kafka来实现。

本文分享自微信公众号 - 物流IT圈(exiter18)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Spring Web 应用的最大败笔

    开发人员在使用Spring应用是非常擅长谈论依赖注入的好处。不幸的是,他们不是那么真的利用它的好处,如单一职责原则,分离关注原则。如果我们一起来看看大部分Spr...

    物流IT圈
  • 多研究些架构,少谈些框架

    微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系...

    物流IT圈
  • 三件事能让你的微服务更具有弹性

    建立一个分布式微服务系统的优点是能够应对承受故障发生以及弹性使用网络资源,弹性的定义很简单,如果传统的monolith发生故障,里面的一切就不能运行了,而微服务...

    物流IT圈
  • 微服务相关

    是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。

    java攻城狮
  • CRM重构之——微服务设计导读(一)

    在介入正题前,想谈一下如何阅读,因为技术类的文章虽好,但需要一定的门槛,而且会比较枯燥,读后可能很快就会忘记读了什么,只记得读过。 导读 阅 带着兴趣 带着兴趣...

    企鹅号小编
  • 安防摄像机监控网页无插件视频直播综合管理平台EasyNVS如何对服务设备信息进行修改

    运维产品是平安城市发展到一定阶段的必然产物,用户花了大量经费来建设平安城市,随着前端、网络、存储、共享平台、实战平台、智能分析平台等建设的日趋完善,运行维护工作...

    EasyNVR
  • 微服务的团队应对之道|TW洞见

    这两年,微服务架构火了。在国内,从消费级互联网应用,到企业级应用;从金融领域,到电信领域;从新开发系统到已经开发了十几二十年的遗留系统;一夜之间,好像所有的团队...

    ThoughtWorks
  • 「分布式系统前沿技术」专题:微服务架构何去何从?

    分布式技术的发展,深刻地改变了我们编程的模式和思考软件的模式。值 2019 岁末,PingCAP 联合 InfoQ 共同策划出品“分布式系统前沿技术 ”专题, ...

    孙玄@奈学教育
  • 服务发现的基本原理

    服务发现并没有怎样的高深莫测,它的原理再简单不过。只是市面上太多文章将服务发现的难度妖魔化,读者被绕的云里雾里,顿觉自己智商低下不敢高攀。

    老钱
  • 响应式微服务架构设计

    使用微服务架构最关键的一个原则就是将系统划分成一个个相互隔离、无依赖的微服务,这些微服务通过定义良好的协议进行通信。而响应式微服务架构,又有其独特的设计原则和理...

    用户1682855

扫码关注云+社区

领取腾讯云代金券