頭條技術號：實戰架構

交流郵箱：[email protected]

本文主要講述：

rocketmq主從架構的生產級實踐，並提供rocketqmq的master-slave結構的生產級容器化配置。

(1).rocketmq生產級鏡像製作

(2).rocketmq生產級鏡像製作注意事項

(3).rocketmq-console-ng生產級鏡像

(4).kubernetes容器化rocketmq生產級主從集群

1.容器化配置文件說明

2.本例配置文件用於生產環境需要的改動

(5).壓測容器化rocketmq集群

(附1).相關資源

(附2).rocketmq生產實踐相關文章

(1).rocketmq生產級鏡像製作

使用rocketmq的master-slave結構。

筆者提供了一個step by step的完整製作流程，位於：

https://github.com/hepyu/rocketmq-docker-image

以rocketmq4.3.2為例：

下載rocketmq4.3.2的二進制包：

wget http://dist.apache.org/repos/dist/release/rocketmq/4.3.2/rocketmq-all-4.3.2-bin-release.zip

git clone https://github.com/hepyu/rocketmq-docker-image.git

解壓後的文件夾重命名為rocketmq，放到目錄:

rocketmq-docker-image/image-build

然後執行腳本完成鏡像製作：

cd sh ./image-build

sh build-4.3.2.sh

(2).rocketmq生產級鏡像製作注意事項

1.本鏡像基於centos:7, java-1.8.0-openjdk-devel.x86_64製作。

2.鏡像名稱格式為：rocketmqinc/rocketmq:${ROCKETMQ_VERSION}

如果想修改為其他格式，請執行docker tag tagId newName重新命名，tagId指鏡像標識。

3.由於broker集群通過序號標識，所以需要容器化前通過腳本自動的識別當前啟動的broker的序號和角色(master/slave)。

修改image-build/scripts/mqbroker，增加：

sh ${ROCKETMQ_HOME}/bin/rewrite-broker-config.sh

在kubernetes容器化時，配置configmap時，配置文件rewrite-broker-config.sh,目的是在broker容器啟動前先行修改broker-config配置文件，根據statefulset的pod序號確認brokerName的序號，同時根據pod序號的奇偶數來確定當前container的角色(master/slave)。

上述腳本文件位於：

https://github.com/hepyu/k8s-app-config/blob/master/product/standard/rocketmq-pro/rocketmq-ms-cluster-pro/rocketmq-broker-configmap.yaml

(3).rocketmq-console-ng生產級鏡像

使用官方鏡像：styletang/rocketmq-console-ng

位於：

https://hub.docker.com/r/styletang/rocketmq-console-ng

https://github.com/apache/incubator-rocketmq-externals/tree/master/rocketmq-console

(4).kubernetes容器化rocketmq生產級主從集群

同樣，筆者提供了生產級的yaml配置，位於：

https://github.com/hepyu/k8s-app-config/tree/master/product/standard/rocketmq-pro/rocketmq-ms-cluster-pro

git clone後進入目錄直接執行:

kubectl apply -f .

但要注意需要執行兩遍，因為namespace剛開始可能還沒有初始化，會報錯。

本地配置ingress宿主機的host,即可訪問rocketmq-console控制檯：

Ip pro-rocketmq-c4-k8s.inc.com

1.容器化配置文件說明

2.本例配置文件用於生產環境需要的改動

修改為2master-2slave-2namesrv的結構。

(5).壓測容器化rocketmq集群

由於之前獨立部署rocketmq時已經做過完備的壓力測試，所以這裡的容器化測試只是看看大概數據而已，並非嚴格壓力測試(資源也不允許)，benchmark都是在namesrv上跑的，沒有單獨劃分資源。但是保證cpu和內存和我們獨立部署的rocketmq集群是一致的，再次確保生產環境正常。

被壓rocketmq集群資源：

a.broker-containers:

2master-2slave共4個container,分佈在4個pod,每個container的資源如下：

limits=requests,cpu=4,memory=8G；jvm內存開啟，-Xms4g -Xmx4g -Xmn2g

b.namesrv-containers:

共2個container，分佈在2個pod，每個container的資源如下：

limits=requests,cpu=1,memory=4G；jvm內存開啟，-Xms3g -Xmx3g -Xmn1g

c.console-container:

忽略，不影響壓測。

使用rocketmq自帶的benchmark壓測：

/producer.sh --w=1 --s=1024 --n=rocketmq-c4-namesrv-prod-server-0.rocketmq-c4-namesrv-prod-server.coohua.svc.cluster.local:9876;rocketmq-c4-namesrv-prod-server-0.rocketmq-c4-namesrv-prod-server.coohua.svc.cluster.local:9876

由於我們生產環境用的是阿里雲的nas存儲，都是SSD，所以效果比我們之前獨立部署的非容器化集群要好（用的是物理磁盤）；成本也不會增加，嚴格來講是減少，因為rocketmq正常情況下不需要很大磁盤空間，而且nas存儲是根據實際使用量來計算費用(即使你的PV聲明瞭2TB也是按照使用量來計算)，綜合下來是更划算些。

測試期間worknode各資源耗費情況：

(6).TODO LIST

1.重製鏡像，增加oracle-jdk8的鏡像製作文件，同時集成mysql-client, redis-client和arthas。openjdk坑的一點是沒有jstat等各種調試工具。

(附1).相關資源

1.官方rocketmq鏡像與容器化

https://github.com/apache/rocketmq-docker

2.筆者rocketmq鏡像製作

https://github.com/hepyu/rocketmq-docker-image

3.筆者oracle-jdk生產級鏡像，包含redis-cli, mysql-cli等基本組件。

https://github.com/hepyu/oraclejdk-docker-image

4.筆者oracle-jdk-skywalking生產級鏡像，包含redis-cli, mysql-cli等基本組件，同時集成了鏈路追蹤skywalking-agent。

https://github.com/hepyu/oraclejdk-skywalking-docker-image

(附2).rocketmq生產實踐相關文章