MQ的使用以及选择，对应着公司的业务发展。

在不同阶段，如何选择合适的MQ？

image
这几年随着物联网的发展，对消息中间件的应用越来越广泛，像ActiveMQ、RabbitMQ、阿里的RocketMQ、Kafka、雅虎的Pulsar等这些开源消息中间件，在不同的行业和系统中都担任着重要的角色。关于这些MQ的资料，也很容易搜索到，但有很多将它们之间进行对比。在此说一下我的个人看法，因为每一款MQ专注的地方和发展路径以及它的优势都不一样，所以没有绝对的可比性。我们的系统要使用这些中间件，一定是为了解决某些问题，所以就要选择最适合的。
image
下面介绍我们在使用消息中间件的演进历程，可能很多数公司都有相似之处。
主要分了三个阶段，而每个阶段的诉求都不一样，所以要使用不同的MQ：
第一阶段：需要一个与平台无关并且能够支持多协议的MQ，因为是异构系统，而且上下游不同的技术栈，上游是C++，下游是Java系统，所以中间使用ActiveMQ进行异步通讯。
第二阶段：建设车辆网IOT，因为高并发量和数据量，需要一个高吞吐中间件，此时ActiveMQ就不合适了，并且Kafka和大数据生态组件结合的比较好，像Strom/Spark/Flink一些流计算框架对Kafka支持也比较好。其实做物联网（IOT）的小伙伴应该比较清楚，从终端设备采集上来的数据质量其实是很差的，可能是因为强弱电或者网络的一些关系，会照成部分数据的丢失和不准确，基本上是在数据接入之后，甚至落地之后，通过一些算法和模型来提高数据质量，其实考验IOT中间件最重要的不是数据的可靠性，而是数据的接入能力和处理能力，所以Kafka是当时一个不错的选择。
第三阶段：我们的部分业务想移植到共有云上，需要一个款面向云原生，具备自动化能够弹性伸缩的MQ，对Kafka比较了解的同学应该知道，Kafka的Topic和Partition不建议太多，过多的磁盘IO会严重影响broker端的写入性能，而且又因为broker是和存储绑定在一起，扩展和减少kafka集群需要对分区rebalance，这些，其实是很头疼的，而 RocketMQ是把数据都顺序写入了一个文件（commit log），很好的解决了这些问题，而且当时公司也更倾向于阿里云，不过这部分业务因为一些原因搁置了。
image
在MQ演进的过程中，就会面临一个问题和思考：如果能让应用快速切入，想要在不改动业务代码的情况下，可以在不同的消息中间件间切换，也就是说需要一个公共的API，这就是消息队列客户端框架初衷和想要解决的问题。

消息队列客户端框架实践分享

image
这款消息队列客户端框架，开源在GitHub上。
项目主页：http://www.darkphoenixs.org/message-queue-client-framework/
Maven的中央仓库也可以下载，目前最新版本1.5.8

org.darkphoenixs messagequeue-framework x.x.x （说到开源框架，一般都有一个响亮或者洋气的名字，但是作者本身比较词穷，所以这个框架的名字就叫做消息队列客户端框架：Message Queue Client Framework） image 这个框架设计之初非常简单，就抽象出这么几个接口：

Producer：通过send方法发送消息
Consumer：通过receive方法接收消息
Encoder和Decoder：定制消息序列化和反序列化
这样一个最基本的生产消费模式就出现了，基于这些接口用户就可以根据自己的业务开发完成消息的收发功能了。
具体代码示例可以参考：https://github.com/DarkPhoenixs/message-queue-client-framework/wiki/Configuration-Examples

image
对于Kafka Consumer的增强，作者是从Kafka 0.8.x版本开始使用Kafka的，那个时候的kafka还只是分布式消息中间件，在使用和开发过程中的一个感受就是Kafka的API真的是过于“简单”，尤其是Consumer端的API，只提供一种poll方式让用户自由发挥，这样使用者需要额外做很多工作，再加上非常奇怪的4位版本号，曾经一度认为Kafka是Linkedin内部的阉割版，后来感觉这可能是和kafka的设计思想有关系，有句话好像是这么说的：“在计算机领域，一些比较复杂的问题，往往是不需要解决的”，那既然这样总要有人来做，所以框架对Kafka Consumer做了一些特性增强。
image
一个最主要的特性是消费模式的增强，分了两种模式：
MODEL_1：是默认的模式，每一个线程消费一个分区（partition）的数据，缺点就是并行度受限于Topic的分区总数，
MODEL_2：之前也说过kafka并不适用于过多分区；所以把消费线程与处理线程分离，在消费线程受限的情况下，增加处理线程能够有效提高吞吐量，但是缺点就是不能保证消息顺序。
image
然后还有批量处理的特性，
NON_BATCH：默认是非批量的，一条一条的处理。
BATCH：在批量场景下使用批量处理能提高消费端的处理能力，比如批量入库。
image
Message Retry，这是一个容错机制，就是消息处理出现异常时，可重新处理，能提高了数据可靠性，但是目前仅在非批量处理时可用。
（这些特性只是针对kafka增加，并没有对 RocketMQ做增强，因为RocketMQ已经具备了这些特性，所以框架没有过多封装，API和配置尽量全都用的它自己的。）
image
至于为什么不封装成一套统一的API，所有的接口和配置全都由框架实现，从代码层面就让MQ完全透明（Spring Cloud的做法），因为封装过度会产生一些问题：
一方面是可能会屏蔽原因特性，因为随着MQ的迭代升级，肯定会有些新特性，如果框架无法跟上MQ的迭代速度，这些新特性可能会被屏蔽，而且未来的维护成本也很巨大。
另一方面就是性能，框架过度封装，本身就会占用很多资源，肯定会影响性能。
image
针对这个框架进行了性能测试和性能对比，以Kafka客户端为例，因为对kafka的API封装的比较多。对直接使用Kafka API、使用客户端框架、和使用spring cloud stream做了对比。
测试服务器用的是阿里云的ECS 4核8G，测试场景完全一样。
Kafka Native API：TPS 80W+
Client Framework API：TPS 80W-
Spring Cloud API：TPS 10W+
从测试结果上来看性能差距还是很大的，所以如果对吞吐和成本有很高要求，其实不建议使用Spring Cloud，不过Spring Cloud封装的确很好，使用也非常方便，所以就要自己衡量了，就像很多在开源微服务框架技术选型上，最终还是放弃Spring Cloud，而使用Dubbo是一个道理，即便是Spring Cloud提供了非常丰富的微服务套件。
image
最后分享一个大件事，OpenMessaging，在2017杭州云栖大会，由阿里和其他几家公司共同发起的分布式消息领域的国际标准。
目标打造厂商中立，面向云原生，对流计算和大数据生态友好的分布式消息标准，未来就可以在不同厂商的产品和平台之间进行无缝迁移。
目前RocketMQ和Pulsar完成了对OpenMessaging支持，后续会推动更多消息中间件厂商落地该标准。

结束语：目前这个消息队列客户端框架只支持ActiveMQ、RocketMQ和Kafka，接下来也会考虑把OpenMessaging集成到这个框架里面，如果感兴趣的小伙伴也可以加入进来，非常的欢迎，一起把它完善的更好。