微服务扩展新途径:Messaging

【编者按】服务编排是微服务设置的一个重要方面。本文在利用 ActiveMQ 虚拟话题来实现这一目标的同时,还会提供实用性指导。文章系国内 ITOM 管理平台 OneAPM 编译呈现。

目前,微服务使用已十分普遍,利用服务编排(而不是服务编制)来进行微服务互动的想法也很常见。本文将讲述如何通过 ActiveMQ 虚拟话题来设置服务编排和基于服务互动的可扩展事件。

服务互动类型

服务互动类型主要有两种:同步和异步。

在同步互动中,服务使用者会发出请求,然后在操作完成、收取回复前阻止其他活动运行,HTTP 协议就是一个很好的同步互动例子。通常情况下,这种互动与请求-回复互动类型、 HTTP 协议都是相关的(当然,也可以利用异步请求或消息传递来登记、请求回调函数的结果,不过这种做法不太常见)。

在异步互动中,服务使用者发出的请求不用在操作完成后才可以运行。一旦请求确认被收到,服务使用者就可以接着做其他的活动。这种类型支持互动沟通采用发布-订阅模式,例如:不需要服务使用者调用其他服务操作,只需要生产者提出事件,等待感兴趣的使用者做出反应即可。

除了这些技术层面的考虑,还应该注意考量服务互动的其他层面:耦合和责任。

如果服务 A 要和服务 B 互动,是要服务 A 来调用服务 B(编制),还是让服务 B 去订阅正确的时间(编排)呢?

在服务编制中需要有一个中心实体(即例子中的服务 A),去了解被调用的其他服务。利用编排方法,可以将这个责任分配给个体服务,由它们来负责订阅“有意思的”事件。

如果想要了解更多关于本话题的内容,请查阅 Building Microservices。接下来,本文将集中讨论如何使用消息传递实现服务编排。

通过消息传递进行服务编制

服务编制是通过队列实现消息传递的。队列能够在竞争使用者模式下实现负载均衡,并且确保消息和使用者一一对应。

假设存在一个与“邮件服务”互动的“客服服务”,最简单的实现方法就是使用一个允许“客户服务”给“邮件队列”发送消息的队列。如果“客户服务”需要跟“忠诚值服务”互动,“客户服务”就要给“忠诚值服务”再发一条消息。这种办法下,“客户服务”需要了解“邮件服务”和“忠诚值服务”这两者,并且把正确的消息发给对应的队列。简而言之,整个互动过程都是由“客户服务”编制的。

使用队列的一个好处就是它可以轻松扩展使用者,并开启多个“忠诚值服务”和“邮件服务”,从而将负载均衡地分布于不同的使用者间。

通过消息传递进行服务编排

使用服务编排方式时,“客户服务”却不需要了解“忠诚值服务”和“邮件服务”。因为“客户服务”只要对“客户话题”发出一个事件,“忠诚值服务”和“邮件服务”就会去了解客户事件协议,并订阅正确的话题——话题的发布-订阅语意会确保每个事件同时被分发给两个订阅者。

扩展服务编排

话题执行发布-订阅,而不是竞争使用,这使得使用者的扩展变得更加困难。如果(横向)扩展“忠诚值服务”并在两个实例中进行试验,可以发现它们会收到同样的事件,这样扩展的话并没有什么益处(除非服务是等幂的)。

ActiveMQ 虚拟话题解决方案

因此需要一种融合了话题和队列的综合形式,充分发挥这两个功能:既能够利用“客户服务”的发布-订阅来发布事件,确保所有服务都能收到该事件;也可以通过竞争的使用者,使个体服务实例实现负载均衡并进行扩展。

实现该形式的方法有很多,可以利用 Camel 和 ActiveMQ :

  • 第一个方法就是用一个简单的 Camel 路由来吸收“客户话题”事件,并把它们同时发送给“忠诚值队列”和“邮件队列”。这是很容易实现的,不过每当有新服务对“客户服务”事件感兴趣时都需要重新更新 Camel 路由。而且,如果在代理之外单独运行 Camel 路由,把消息从某一话题转入到其事先设定好的队列中去,就会带来不必要的网络开销。
  • 上述方法的一个改进方案,就是在 ActiveMQ 代理流程中使用 ActiveMQ Camel plugin 来运行 Camel 路由。这样的话,虽然仍需要在订阅者发生变更时更新 Camel 路由,但是路由是在代理过程中发生的,因此不会产生网络开销。
  • 不过还有更好的方案,就是将订阅该话题的队列 W/O 全部进行编码,但是要借用 ActiveMQ 虚拟话题的声明法(这也是撰写本文的主要原因)。

ActiveMQ 虚拟话题是将订阅队列发布到话题中的方法,通过一个简单的命名惯例——所要做的就是确定话题或队列的命名惯例,无论是自定义的还是默认的都可以。

举个例子:

  • 可以先创建一个与 VirtualTopic.> 表达式相匹配的话题名,如 VirtualTopic.CustomerTopic,
  • 然后让“忠诚度服务”调用 Consumer.LoyaltyPoint.VirtualTopic.CustomerTopic 队列,
  • 那么消息代理就会将 VirtualTopic.CustomerTopic 话题中的所有事件都转发给
    Consumer.LoyaltyPoint.VirtualTopic.CustomerTopic 队列。
  • 然后可以通过开启多个服务实例来扩展忠诚度服务,所有实例都从 Consumer.LoyaltyPoint.VirtualTopic.CustomerTopic 队列中调用。
  • 同样的,之后再用同样的命名惯例为邮件服务创建队列:Consumer.Email.VirtualTopic.CustomerTopic,这个功能允许用户以特定方式来简单命名话题和队列,并且无需编码就能订阅。

结论

以上所述只是最近出版的著作 Camel Design Patterns 里介绍的多种模式之一。正因为经常将Camel 与 ActiveMQ 一起使用,书中也就收录了一些 ActiveMQ 模式内容。

另外,用编排扩展微服务还可以通过事件驱动来实现,这里就是一篇介绍这种方法的推荐文章。

本文转自 OneAPM 官方博客

原文地址:https://dzone.com/articles/scalable-microservices-through-messaging

上一篇:如何在Ruby中编写微服务?


下一篇:战略性情绪分析的5大数据来源