activeMQ消息中间件

Posted 2021-04-24 与JAVA邂逅的点滴

废话不多说，直接进入今天的主题：activeMQ消息中间件。

众所周知，开发一个企业级的网站后台需要提供大量的服务组件。而SOA（Service-Oriented-Architecture）很好的将传统的垂直型网站后台架构转换成基于服务的网站后台架构。也就是说，编写一组后台服务组件，无论何种形式的前台都可以调用这一组后台服务组件。（也就是说，后台开发了一组WebService，将各个服务抽取出来，PC端，android端，ios端等等  无论何种语言类似于python，java，c++，php语言开发的前端都能调用这一组服务）所以就不需要再次开发service层了。

虽然SOA架构很方便，但是使用了这种SOA架构的网站后台，当服务组件变多时，各个服务组件之间的调用也将会变多。举个例子说明一下：

现在有商品服务A，还有添加索引库服务B，现在需要完成这样一个功能：服务A 添加完一条商品时，调用服务B同步索引库。

要实现这个功能，以目前的知识有2种方案：

1. 在服务A的代码中直接写服务B的代码，完成此功能。
   

   缺点：代码耦合程度高，业务拆分不明确。（原因：大型企业中例如服务A有它自己的开发团队进行维护和开发，同理服务B也是，所以这个方案虽然完成了功能但是造成了业务混乱和高耦合的代码）。

2. 服务A中的代码不涉及服务B的具体实现，只是使用服务B的接口调用服务B,完成此功能。

   缺点：代码耦合程度高，服务启动顺序需要注意。（一般大型企业后台网站架构服务组件过多，如果各个服务之间都有调用关系，那么如果启动顺序错误造成控制台报错，虽然能运行，但是这种错误很容易造成未知的很严重后果。）

   
   

所以以上2种方案已经不能解决这个时代的问题了。

所以想要服务组件之间低耦合，业务拆分明确的话，第三种方案就必须引入消息中间件。

常见的消息中间件有：activeMQ，rabitMQ，kafka。

那么今天想要介绍的是activeMQ这款消息中间件。它是由java语言开发的，并且是Apache出品的。它现今在市面上占据了百分之50的使用率。并且在linux上部署异常简单，甚至比在linux上搭建个jdk还要简单很多。简单的上传解压缩，再改hosts（本地测试如果不改host的话很容易出现503错误）就可以调用这款中间件了。

现在要想完成这个功能，第三种方案是这样的：

当服务A添加完一条商品进入数据库之后，这条商品会有一个Item Id，然后服务A将这个item Id 发送入activeMQ 消息中间件，服务B从activeMQ中得到这个item Id，随后根据这个item Id 在数据库中查找这条商品记录并且将它导入索引库。

在这个过程中服务A是生产消息的，所以它是生产者provider，服务B是消耗消息的，所以它是消费者consumer。消息中间件是队列，provider可以不断生产消息，consumer如果监听了这个队列，那么它会不断的消耗队列中的消息。

所以当服务A添加完一条商品后，只是简单的将商品id放入消息队列，并没有涉及服务B的任何代码。而B是监听这个消息队列的，当它收到这个商品id时，就完成服务B的功能，所以如果服务B哪天瘫痪了，这样也并不会对服务A造成任何影响。

这样就让服务A和服务B的代码耦合程度降到了最低，业务拆分的最明确。

这便是activeMQ的2种方式的其中一种方式：Queue方式。另外一种则是Topic方式。 

Queue方式是多对一的。也就是provider可以至少有1个，而consumer只能有一个。

Topic方式是多对多的。也就是provider和consumer都可以至少有1个。

所以如果其它服务也需要新添加商品的id时，就可以选择Topic模式了。

最后，默认在Queue方式中，如果provider生产的消息没有被consumer消费，那么此条消息会持久化到服务器中。而Topic方式中，生产者生产的消息如果没有被consumer消费，那么消息就不能持久化。（其实还是有方式让消息持久化的）。