消息消费者容器

消息消费模式我们已经非常熟悉，本文介绍一种新的使用方式，在某种情况下，尤其是消费者比较多的情况下，也不失为一种解决办法

消息消费者容器这个名字是我自定义的，因为实在找不到一个好的名字来描述这个功能，所以就先这样使用吧。
我相信大家对消息队列已经很熟悉，不熟悉的同学可以找资料脑补一下。一般情况下我们使用消息队列的模式是启动一个进程订阅一个消息，当有新消息时直接消费就可以了，消息监听与消费是在一起的。其实这种模式也没有什么疑问，过去我都是这样使用的，一直都很好，知道有一天遇到了一项目…
先不介绍项目，先简单介绍下模式；消息消费者容器的使用模式只是在原来的基础上做了一些改进，将消息监听与消息消费两者分离；消息监听采用多线程的模式，每个线程监听一个队列，这样就可以实现同时监听多个消息队列；当有消息到来时，对应的线程会通过JNI调用外部消息消费者应用，并将结果返回给消息容器，实现消息订阅监听与消息消费的分离，注意这里外部消息消费者应用，与消息监听程序处于不同的进程中。
何为消息消费者容器？ 经过上面的介绍大概有了一定的概念，就是一个常驻的程序，用于监听多个消息队列，采用多线程的方式，在线程内部调用外部消息消费者程序；消息消费只是其中的一个主要功能，容器还包含了统一的日志处理机制、统一的异常处理机制、应用自动下载与更新；使用容器的思想可以很好的对消息的消费过程进行统一的管理，借助应用管理和配置平台，可以实现队列与消费者程序的动态配置等。
现在来介绍下项目背景，看后就知道为什么采用这种模式，这个项目是业务整合性质的，需要将多个业务部门的业务统一管理起来，实现信息的共享和统一管理，每个部门背景不同，所用技术不同，所以就造成了如下两个比较明显的特点：
1. 服务程序数量多，包含数几百个的不同的独立应用需要启动和运行，应用的实现方式、所用技术不同，二次开发难度较大；
2. 基于时间和消息驱动，当然时间驱动模式最终还是以消息驱动实现。想象一下为了管理这么多异构的应用，保证每个都能正确的运行确实是个不小的挑战；如果对每个应用都进行消息驱动改造，工作量比较大，并且需要的技术比较多，有使用JAVA语言的，有的是C#, 还有的是C++, 甚至Python等， 改动起来难度比较大；好在这些程序大部分都是独立运行的，可以接收外部参数，少量的程序需要改造后就能够满足使用。
受容器思想的启发，基于上述现状，我们想到了JNI，何不使用容器的思想来监听多个队列，每个队列对应一个监听线程，如果有新消息，在线程内部通过JNI调用外部应用，并将需要的参数传递给对应的应用。
经过这样处理，每个容器可以启动5-15个应用，这样在管理上我的关注点就不再是应用，而是容器，并且关注的数量也大大减少。并且可以很方便的通过平台对容器进行管理。
在这种模式得到验证的前提下，我们在容器中增加了很多有用的功能：
1. 配置平台化：将配置信息集中管理：队列与应用的对应关系、定时配置等通过管理平台统一管理，每个容器通过容器ID从平台获得自己的配置信息；
2. 应用集中管理：将应用程序集中放置在应用管理服务器上，容器在启动应用时会判断本地应用是否存在，如果不存在就会到应用管理服务器下载；
3. 应用监控：增加对应用全生命周期的监控，从接收到消息到处理完成，都由容器进行跟踪和管理，对于有异常的应用进行及时报警，发送的应用管理平台；
4. 日志处理：对应用的日志进行统一处理，可以记录在本地或则通过消息处理系统如Kafka对日志信息进行集中处理。
虽然只是消息使用方式一种改变，没有使用很高深的技术，没有长篇的架构设计，但是却极大的改变了我们的程序结构，也极大的减少了后续的管理和支持成本；好多事情就是这样的。
最后，为什么称之为消息消费者容器，因为这个容器的主要功能是对消息监听和消息消费者进行了模式优化。
与君共勉！