上一篇讲到Producer的封装思路，比较的是AMQ和Kafka两个比较流行的中间件，这篇就不多啰嗦了，继续沿着上一篇的思路，将AMQ和Kafka尝试封装成对客户更简单更易用的接口。
拐一句，我有想过为什么不直接对外暴露官方的接口，也就是做通用化封装的意义何在？在一个一两个人的小项目里，如果MQ只是用于系统间解耦，当然没必要封装，直接拿来用即可。但是如果一个公司有成千上百个项目，大量项目都希望使用消息中间件，这时候最合适的方法就是对这些项目暴露一个简单易用的消息中间件的接口，由专门的团队提供消息平台的服务，让业务系统只需要简单的培训就可以使用消息服务，简化公司内重复的劳动。
说回正题，仍然从AMQ和Kafka的官方接口开始，consumer考虑统一只使用拉取（pull）的方式。
AMQ的接收一条消息的流程为：
- 建立连接工厂 ConnectionFactory
ConnectionFactory cf = new ActiveMQConnectionFactory("admin","admin",url);
- 通过连接工厂建立连接并启动 Connection
Connection conn = cf.createConnection();
conn.start
- 通过连接建立会话 Session
Session session = conn.createSession(false,Session.AUTO_ACKNOWLEDGE);
- 通过会话建立目的地 Destination
Destination dest = session.createQueue("test");
- 在会话中指定目的地建立消费者Consumer
MessageConsumer consumer = session.createConsumer(dest)
- 使用Consumer收取一条消息
Message msg = consumer.receive(1000);
与生产者主要的区别就是从第五步以后的步骤，建立连接等方式都是一样的。一般来说，使用pull方式需要在外面套上一层while(true)的循环，连接保持长连接的方式，不停的从服务器端拉取消息。
Kafka的消息消费与一般消息中间件有所不同。
Kafka接受消息的流程为：
注：使用kafka 0.9版本后提供的新的consumer API
- 实例化一个Properties类
Properties props = new Properties();
- 往Properties中填入bootstrap服务器，groupID等属性
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "test");
props.put("enable.auto.commit", "true");
props.put("auto.commit.interval.ms", "1000");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
- 将Properties作为入参实例化一个KafkaConsumer
KafkaConsumer consumer = new KafkaConsumer<>(props);
- 设置consumer订阅的topic
consumer.subscribe(Arrays.asList("foo", "bar"));
- 接收一条消息
ConsumerRecords records = consumer.poll(100);
简直感动，当初我以为要使用high level的consumer来设计了，要从流中获取消息啊，都不知道怎么封装了。没想到0.9版本以后简化了更易用的consumer版本，业界良心！
通用化封装
闲话少说，沿袭上一篇的思路，直接开始：
- 实例化一个MQClient对象
MQClient mc = new MQClient("mqclient.properties");
对应AMQ的1，2两步，Kafka的1，2两步
在实例化时，从mqclient.properties文件中读取出所有的配置，并建立连接。
- 建立一个消费者
MQConsumer consumer = client.getConsumer(destination);
对应AMQ的3,4,5步，Kafka的第3,4步
建立消费者时，需要指定目的地，因为很明显消费者和目的地应该是对应好的。destination应该支持组合的方式，不止是ActiveMQ支持组合目的地，kafka也同样支持。
- 获取一条消息
MQMessage(s) msg = consumer.receive(time);
对应AMQ的第6步，Kafka的第5步
AMQ和Kafka的API都支持传入时间，表示持续消费的意思。外面包上一层while()循环即可。获取到的MQMessage是一个我们自己写的类，在这个类中，如果是AMQ，需要将消息的类型（TextMessage，ObjectMessage）等标注清楚，如果是Kafka的类，需要注意的是获取到的是一个ConsumerRecords的类，里面可能包含多条消息。
我们可以在这里选择三种处理方式：
- 将AMQ也改为获取到一组消息，MQMessages类中包含多个MQMessage。
- 限制Kafka每次只能获取一条消息，继续使用MQMessage类。
- MQMessage类中，为Kafka单独处理，对于AMQ来说，MQMessage获取到的是一条消息，Kafka获取到的是一组消息。
由于Kakfa的新API我还没用过，等到实际使用后我再来选择具体方案。
结合上一篇Producer的封装思路，消息中间件的面向客户的API封装思路基本理顺了，生下来的就是各种细节，需要仔细思考的有：
- 线程池，连接池的使用
- 快速安装broker
- 用户的权限管理，topic和queue的安全访问控制
- 定制化需求的实现
- ……
原来还有一堆事等着我啊。。。。