RocketMQ是一个高可用、高性能、高可靠的分布式消息队列,相对于kafka更适合处理业务系统之间的消息。
所以,它的本质决定的其架构一定是复杂的,参考RocketMQ官方架构图:
这里不再介绍各个组件的含义,可以参考RocketMQ架构设计。
RocketMQ经过阿里多年双十一的检验,其稳定性不言而喻。
可作为搜狐视频的消息中台,还需要很长一段路要走,为什么这么说呢?
早在2014年我们就引入了RocketMQ作为消息中间件,其附带了基本的命令行工具。
但是命令行运维此等庞然大物会让人感到力不从心,好在社区提供了一个web控制台:RocketMQ-Console。
在初期,简单的控制台已经能满足基本的需求。但是随着各个业务逐渐接入,需求也纷至沓来。
我们在RocketMQ-Console的修修补补已经无法满足了,主要体现在如下几点:
另外,RocketMQ有一些潜在约定、使用规范、最佳实践、bug或优化等等,用文档说明也无济于事。
所以与其写文档不如将经验和实践转换为产品,能够更好的服务于业务及运维集群,于是MQCloud应运而生。
先看一下MQCloud的定位:
它是集客户端SDK,监控预警,集群运维于一体的一站式服务平台。
MQCloud的系统架构如下:
下面来分别说明一下MQCloud如何解决上面提到的痛点。
业务端和运维端分离,使业务用户只聚焦于业务数据。
为了实现这个目的,引入了用户,资源两大维度。
针对用户和资源加以控制,使不同的用户只聚焦于自己的数据。
清晰明了的操作
通过对不同角色展示不同的视图,使用户可以进行的操作一目了然。
规范和安全
为了保障集群操作的安全性和规范性,所有的操作都会以申请单的形式进入后台审批系统,管理员来进行相关审批,安全性大大提升。
多维的数据统计和监控预警
MQCloud核心功能之一就是监控,要想做监控,必须先做统计,为了更好的知道RocketMQ集群的运行状况,MQCloud做了大量的统计工作,主要包括如下几项:
下面来分别介绍每项统计是如何收集的:
每分钟topic的生产流量
此数据来自于RocketMQ broker端BrokerStatsManager,其提供了统计功能,统计项如下:
RocketMQ实现的统计逻辑较为精巧,这里做简单描述,首先介绍几个对象:
上面三个对象如何配合进行数据统计呢?举个例子,比如统计topic名字为test_topic的消息生产大小:
只要进行类似如下调用即可:
StatsItemSet.addValue("test_topic", 123125123, 1)
即表示发送了1次消息到test_topic,消息大小为123125123。
那如何进行数据采样呢?StatsItemSet内置了定时任务,比如其每10秒调用一次StatsItem.samplingInSeconds()。这样StatsItem就会持有60秒的数据,类似如下结构:
那么,最后一个10秒的快照 - 第一个10秒的快照 = 当前60秒的数据,根据时间戳差值可以得到耗时。
类似,小时数据每10分钟进行一次快照,类似如下结构:
天数据每1小时进行一次快照,类似如下结构:
MQCloud每分钟遍历查询集群下所有broker来查询RocketMQ统计好的分钟数据,然后进行存储。
每分钟消费者流量
与每分钟topic的生产流量一样,也采用RocketMQ统计好的数据。
每10分钟topic生产流量
采用数据库已经统计好的每分钟topic流量进行累加,统计出10分钟流量。
每分钟broker生产、消费流量
由于统计1.每分钟topic的生产流量和2.每分钟消费者流量时是跟broker交互获取的,所以知道broker ip,故直接按照broker维度存储一份数据即可。
每分钟broker集群生产、消费流量
采用4.每分钟broker生产、消费流量数据,按照集群求和即可。
每分钟生产者百分位耗时、异常统计
由于RocketMQ并没有提供生产者的流量统计(只提供了topic,但是并不知道每个生产者的情况),所以MQCloud实现了对生产者数据进行统计(通过RocketMQ的回调钩子实现):
主要统计如下信息:
统计完成后,定时发送到MQCloud进行存储,并做实时监控和展示。
关于统计部分有一点说明,一般耗时统计有最大,最小和平均值,而通常99%(即99%的请求耗时都低于此数值)的请求的耗时情况才能反映真实响应情况。99%请求耗时统计最大的问题是如何控制内存占用,因为需要对某段时间内所有的耗时做排序后才能统计出这段时间的99%的耗时状况。而对于流式数据做这样的统计是有一些算法和数据结构的,例如t-digest,但是MQCloud采用了非精确的但是较为简单的分段统计的方法,具体如下:
优点:此种分段方法占用内存是固定的,比如最大耗时如果为3500ms,那么只需要空间大小为96的数组即可
缺点:分段精度需要提前设定好,且不可更
这样,从计数数组就可以得到实时耗时统计,类似如下:
另外提一点,由于RocketMQ 4.4.0新增的trace功能也使用hook来实现,与MQCloud的统计有冲突,MQCloud已经做了兼容。
Trace和统计是两种维度,trace反映的是消息从生产->存储->消费的流程,而MQCloud做的是针对生产者状况的统计,有了这些统计数据,才可以做到生产耗时情况展示,生产异常情况预警等功能。
机器统计
关于集群状况收集主要采用了将nmon自动放置到/tmp目录,定时采用ssh连接到机器执行nmon命令,解析返回的数据,然后进行存储。
上面这些工作就为监控和预警奠定了坚实的数据基础。
单独定制的客户端
针对客户端的一些需求,mq-client在rocketmq-client的基础上进行了开发定制:
自动化运维
安全性加固
一、开启管理员权限
RocketMQ从4.4.0开始支持ACL,但是默认没有开启,也就是任何人使用管理工具或API就可以直接操纵线上集群。但是开启ACL对现有业务影响太大,针对这种情况MQCloud进行专门定制。
借鉴RocketMQ ACL机制,只针对RocketMQ管理员操作加固权限校验:
并且支持自定义和热加载管理员请求码,使得非法操作RocketMQ集群成为不可能,安全性大大提升。
二、broker通信加固
broker同步数据代码由于没有校验,存在安全隐患,只要连接master监听的slave通信端口,发送数据大于8个字节,就可能导致同步偏移量错误,代码如下:
if ((this.byteBufferRead.position() - this.processPostion) >= 8) {
int pos = this.byteBufferRead.position() - (this.byteBufferRead.position() % 8);
long readOffset = this.byteBufferRead.getLong(pos - 8);
this.processPostion = pos;
HAConnection.this.slaveAckOffset = readOffset;
if (HAConnection.this.slaveRequestOffset < 0) {
HAConnection.this.slaveRequestOffset = readOffset;
log.info("slave[" + HAConnection.this.clientAddr + "] request offset " + readOffset);
}
HAConnection.this.haService.notifyTransferSome(HAConnection.this.slaveAckOffset);
}
MQCloud通过验证数据首包的策略,保障了通信的安全性。
目前MQCloud运维规模如下:
MQCloud在充分考虑和吸收实际业务的需求后,以各个角色聚焦为核心,以全面监控为目标,
以满足各业务端需求为己任,在不断地发展和完善。
在MQCloud逐渐成熟之后,秉承着服务于社区和吸收更多经验的理念,我们开放了源代码。
开放源代码说不难也不难,说难也难。为什么这么说?
不难就是因为代码已经有了,只是换个仓库而已。
而难点就是需要进行抽象设计,剥离不能开源的代码(内部模块,代码,地址等等)。
经过设计和拆分,MQCloud于18年开源了,从第一个版本release到现在已经过去两年了,
期间随着更新迭代大大小小一共release了20多个版本。
其中不但包含功能更新、bug修复、wiki说明等,而且每个大版本都经过详细的测试和内部的运行。
之后很多小伙伴跃跃欲试,来试用它,并提出一些建议和意见,我们根据反馈来进一步完善它。
我们将一直遵循我们的目标,坚定的走自己的开源之路: