4 钟情RocketMQ
4.1 开源的盛宴
2014年，我搜罗了很多的淘宝的消息队列的资料，我知道MetaQ的版本已经升级MetaQ 3.0，只是开源版本还没有放出来。
大约秋天的样子，我加入了RocketMQ技术群。誓嘉(RocketMQ创始人)在群里说：“最近要开源了，放出来后，大家赶紧fork呀”。他的这句话发在群里之后，群里都炸开了锅。我更是欢喜雀跃，期待着能早日见到阿里自己内部的消息中间件。
终于，RocketMQ终于开源了。我迫不及待想一窥他的风采。
因为我想学网络编程，而RocketMQ的通讯模块remoting底层也是Netty写的。所以，RocketMQ的通讯层是我学习切入的点。
我模仿RocketMQ的remoting写了一个玩具的rpc，这更大大提高我的自信心。正好，艺龙举办技术创新活动。我想想，要不尝试一下用Netty改写下Cobar的通讯模块。于是参考Cobar的源码花了两周写了个netty版的proxy，其实非常粗糙，很多功能不完善。后来，这次活动颁给我一个鼓励奖，现在想想都很好玩。
因为在神州优车使用MetaQ的关系，我学习RocketMQ也比较得心应手。为了真正去理解源码，我时常会参考RocketMQ的源码，写一些轮子来验证我的学习效果。
虽然自己做了一些练习，但一直没有在业务环境使用过。2018年是我真正使用RocketMQ的一年，也是有所得的一年。
短信服务
短信服务应用很广泛，比如用户注册登录验证码，营销短信，下单成功短信通知等等。最开始设计短信服务的时候，我想学习业界是怎么做的。于是把目标锁定在腾讯云的短信服务上。腾讯云的短信服务有如下特点：
- 统一的SDK，后端入口是http/https服务 , 分配appId/appSecret鉴权；
- 简洁的API设计：单发，群发，营销单发，营销群发，模板单发，模板群发。
于是，我参考了这种设计思路。
- 模仿腾讯云的SDK设计，提供简单易用的短信接口；
- 设计短信服务API端，接收发短信请求，发送短信信息到消息队列；
- worker服务消费消息，按照负载均衡的算法，调用不同渠道商的短信接口；
- Dashboard可以查看短信发送记录，配置渠道商信息。
短信服务是我真正意义第一次生产环境使用RocketMQ，当短信一条条发出来的时候，还是蛮有成就感的。
MQ控制台
使用过RocketMQ的朋友，肯定对上图的控制台很熟悉。当时团队有多个RocketMQ集群，每组集群都需要单独部署一套控制台。于是我想着：能不能稍微把控制台改造一番，能满足支持多组集群。
于是，撸起袖子干了起来。大概花了20天的时间，我们基于开源的版本改造了能支持多组集群的版本。做完之后，虽然能满足我最初的想法，但是做的很粗糙。而且搜狐开源了他们自己的MQCloud ，我看了他们的设计之后， 觉得离一个消息治理平台还很远。
后来我读了《网易云音乐的消息队列改造之路》，《今日头条在消息服务平台和容灾体系建设方面的实践与思考》这两篇文章，越是心痒难耐，蛮想去做的是一个真正意义上的消息治理平台。一直没有什么场景和机会，还是有点可惜。
最近看了哈罗单车架构专家梁勇的一篇文章《哈啰在分布式消息治理和微服务治理中的实践》，推荐大家一读。
一扇窗子，开始自研组件
后来，我尝试进一步深入使用RocketMQ。
- 仿ONS风格封装消息SDK；
- 运维侧平滑扩容消息队列；
- 生产环境DefaultMQPullConsumer消费模式尝试
这些做完之后，我们又自研了注册中心、配置中心，任务调度系统。设计这些系统的时候，从RocketMQ源码里汲取了很多的营养，虽然现在看来有很多设计不完善的地方，代码质量也有待提高，但做完这些系统后，还是大大提升我的自信心。
RocketMQ给我打开了一扇窗子，让我能看到更广阔的Java世界。对我而言，这就是开源的盛宴。
4.2 Kafka: 大数据生态的不可或缺的部分
Kafka是一个拥有高吞吐、可持久化、可水平扩展，支持流式数据处理等多种特性的分布式消息流处理中间件，采用分布式消息发布与订阅机制，在日志收集、流式数据传输、在线/离线系统分析、实时监控等领域有广泛的应用。
日志同步
在大型业务系统设计中，为了快速定位问题，全链路追踪日志，以及故障及时预警监控，通常需要将各系统应用的日志集中分析处理。
Kafka设计初衷就是为了应对大量日志传输场景，应用通过可靠异步方式将日志消息同步到消息服务，再通过其他组件对日志做实时或离线分析，也可用于关键日志信息收集进行应用监控。
日志同步主要有三个关键部分：日志采集客户端，Kafka消息队列以及后端的日志处理应用。
- 日志采集客户端，负责用户各类应用服务的日志数据采集，以消息方式将日志“批量”“异步”发送Kafka客户端。Kafka客户端批量提交和压缩消息，对应用服务的性能影响非常小。
- Kafka将日志存储在消息文件中，提供持久化。
- 日志处理应用，如Logstash，订阅并消费Kafka中的日志消息，最终供文件搜索服务检索日志，或者由Kafka将消息传递给Hadoop等其他大数据应用系统化存储与分析。
日志同步示意图：
流计算处理
在很多领域，如股市走向分析、气象数据测控、网站用户行为分析，由于数据产生快、实时性强且量大，您很难统一采集这些数据并将其入库存储后再做处理，这便导致传统的数据处理架构不能满足需求。Kafka以及Storm、Samza、Spark等流计算引擎的出现，就是为了更好地解决这类数据在处理过程中遇到的问题，流计算模型能实现在数据流动的过程中对数据进行实时地捕捉和处理，并根据业务需求进行计算分析，最终把结果保存或者分发给需要的组件。
数据中转枢纽
近10多年来，诸如KV存储（HBase）、搜索（ElasticSearch）、流式处理（Storm、Spark、Samza）、时序数据库（OpenTSDB）等专用系统应运而生。这些系统是为单一的目标而产生的，因其简单性使得在商业硬件上构建分布式系统变得更加容易且性价比更高。通常，同一份数据集需要被注入到多个专用系统内。例如，当应用日志用于离线日志分析时，搜索单个日志记录同样不可或缺，而构建各自独立的工作流来采集每种类型的数据再导入到各自的专用系统显然不切实际，利用消息队列Kafka版作为数据中转枢纽，同份数据可以被导入到不同专用系统中。
下图是美团 MySQL 数据实时同步到 Hive 的架构图，也是一个非常经典的案例。
4.3 如何技术选型
2018年去哪儿QMQ开源了，2019年腾讯TubeMQ开源了，2020年Pulsar如火如荼。
消息队列的生态是如此的繁荣，那我们如何选型呢？
我想我们不必局限于消息队列，可以再扩大一下。简单谈一谈我的看法。
Databases are specializing – the “one size fits all” approach no longer applies ----- MongoDB设计哲学
第一点：先有场景，然后再有适配这种场景的技术。什么样的场景选择什么样的技术。
第二点：现实往往很复杂，当我们真正做技术选型，并需要落地的时候，技术储备 和成本 是两个我们需要重点考量的因素。
技术储备
- 技术团队有无使用这门技术的经验，是否踩过生产环境的坑，以及针对这些坑有没有完备的解决方案；
- 架构团队是否有成熟的SDK，工具链，甚至是技术产品。
成本
- 研发，测试，运维投入人力成本；
- 服务器资源成本；
- 招聘成本等。
最后一点是人 的因素，特别是管理者的因素。每一次大的技术选型考验技术管理者的视野，格局，以及管理智慧。
5 写到最后
我觉得这个世界上没有什么毫无道理的横空出世，真的，如果没有大量的积累大量的思考是不会把事情做好的。。。总之，在经历了这部电影以后，我觉得我要学的太多了，这世界上有太多的能人，你以为的极限，弄不好，只是别人的起点。所以只有不停地进取，才能不丢人。那，人可以不上学，但一定要学习，真的。------ 韩寒《后会无期》演讲
我学习消息队列的过程是不断思考，不断实践的过程，虽然我以为的极限，弄不好，只是别人的起点，但至少现在，当我面对这门技术的时候，我的内心充满了好奇心，同时也是无所畏惧的。
我始终相信：每天学习一点点，比昨天进步一点点就好。
：
