[Editor's note] Service orchestration is an important aspect of microservice setup. This article provides practical guidance while leveraging ActiveMQ virtual topics to achieve this goal. The article is compiled and presented by OneAPM , the domestic ITOM management platform .
The use of microservices is quite common these days, and the idea of using service orchestration (rather than service orchestration) to interact with microservices is common. This article will describe how to set up service orchestration and extensible events based on service interaction through ActiveMQ virtual topics.
Service Interaction Type
There are two main types of service interaction: synchronous and asynchronous.
In a synchronous interaction, a service consumer makes a request and then prevents other activities from running until the operation is completed and a reply is received. The HTTP protocol is a good example of a synchronous interaction. Typically, this interaction is related to the request-reply interaction type, HTTP protocol (of course, asynchronous requests or messaging can also be used to register and request the result of a callback function, but this is less common).
In an asynchronous interaction, a request from a service consumer does not need to be completed before the operation is completed. Once the request acknowledgement is received, the service user can proceed with other activities. This type supports the use of publish-subscribe mode for interactive communication. For example, service users do not need to call other service operations, only producers need to raise events and wait for interested users to respond.
In addition to these technical considerations, care should also be taken to consider other aspects of service interaction: coupling and responsibility.
If service A wants to interact with service B, should service A call service B (orchestration), or should service B subscribe to the correct time (orchestration)?
There needs to be a central entity in service orchestration (ie, service A in the example) that knows about other services being called. Using an orchestration approach, this responsibility can be assigned to individual services, which are responsible for subscribing to "interesting" events.
If you want to learn more about this topic, check out Building Microservices . Next, this article will focus on how to implement service orchestration using messaging.
Service Orchestration via Messaging
服务编制是通过队列实现消息传递的。队列能够在竞争使用者模式下实现负载均衡，并且确保消息和使用者一一对应。
假设存在一个与“邮件服务”互动的“客服服务”，最简单的实现方法就是使用一个允许“客户服务”给“邮件队列”发送消息的队列。如果“客户服务”需要跟“忠诚值服务”互动，“客户服务”就要给“忠诚值服务”再发一条消息。这种办法下，“客户服务”需要了解“邮件服务”和“忠诚值服务”这两者，并且把正确的消息发给对应的队列。简而言之，整个互动过程都是由“客户服务”编制的。
使用队列的一个好处就是它可以轻松扩展使用者，并开启多个“忠诚值服务”和“邮件服务”，从而将负载均衡地分布于不同的使用者间。
通过消息传递进行服务编排
使用服务编排方式时，“客户服务”却不需要了解“忠诚值服务”和“邮件服务”。因为“客户服务”只要对“客户话题”发出一个事件，“忠诚值服务”和“邮件服务”就会去了解客户事件协议，并订阅正确的话题——话题的发布-订阅语意会确保每个事件同时被分发给两个订阅者。
扩展服务编排
话题执行发布-订阅，而不是竞争使用，这使得使用者的扩展变得更加困难。如果（横向）扩展“忠诚值服务”并在两个实例中进行试验，可以发现它们会收到同样的事件，这样扩展的话并没有什么益处（除非服务是等幂的）。
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