微服务扩展新途径：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 工程师编译整理。OneAPM 能为您提供端到端的 Java 应用性能解决方案，咱们支持全部常见的 Java 框架及应用服务器，助您快速发现系统瓶颈，定位异常根本缘由。分钟级部署，即刻体验，Java 监控历来没有如此简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客

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