駕馭千級(jí)節(jié)點(diǎn)——揭秘PUMA大規(guī)模集群能力（一） ——需求分析

前言

這個(gè)系列的文章主要介紹了大規(guī)模PUMA集群的一些內(nèi)容，包括產(chǎn)品對(duì)大規(guī)模集群的訴求、業(yè)界使用大規(guī)模kafka集群的分析、千級(jí)節(jié)點(diǎn)集群和單集群千萬tps的可行性分析、PUMA針對(duì)千級(jí)節(jié)點(diǎn)集群在彈性伸縮上做的技術(shù)突破、最后介紹一下在華為企業(yè)云上進(jìn)行大規(guī)模集群測(cè)試的過程及測(cè)試結(jié)論分析等等。

PUMA是什么？

PUMA：Portable(Programmable) and?Unified?Message?Architecture，統(tǒng)一開放消息總線，解決大規(guī)模分布式應(yīng)用的通訊問題，保障消息通信高可靠、搞吞吐、高擴(kuò)展。

什么是大規(guī)模集群？

何謂大規(guī)模集群？三節(jié)點(diǎn)、五節(jié)點(diǎn)、七節(jié)點(diǎn)算不算，肯定算不上了，那200節(jié)點(diǎn)、500節(jié)點(diǎn)或者1000節(jié)點(diǎn)的集群呢，我認(rèn)為其實(shí)沒有一個(gè)統(tǒng)一的劃分，不同產(chǎn)品對(duì)集群規(guī)模的支持是不同的；比如redis，通過分槽來實(shí)現(xiàn)集群化，槽的總數(shù)是一定的，這就導(dǎo)致你不可能去搭建一個(gè)千節(jié)點(diǎn)的redis集群，因?yàn)檫@沒有任何的實(shí)際意義除了增加你訪問的時(shí)延；再比如zookeeper，最終一致性，每個(gè)節(jié)點(diǎn)上 訪問到的數(shù)據(jù)或者看到的視圖都是一樣的（可能會(huì)出現(xiàn)數(shù)據(jù)不一致的情況，但最終會(huì)同步成一致的），你去搭建一個(gè)千節(jié)點(diǎn)的zk集群，我只能說過猶不及，集群的寫性能會(huì)大幅下降，因?yàn)槟愕臄?shù)據(jù)寫入了leader后需要同步到所有的Learner(包括follower和Observer)中去，讀性能提升也有限，因此業(yè)界使用zk集群的規(guī)模一般在5節(jié)點(diǎn)或者7節(jié)點(diǎn)的規(guī)模，兼顧了讀寫性能和容災(zāi)備份。

哪些產(chǎn)品能駕馭千節(jié)點(diǎn)集群的規(guī)模呢？

這里舉個(gè)栗子：PUMA（統(tǒng)一開放消息總線，技術(shù)選型為kafka），其集群的節(jié)點(diǎn)間是松耦合的，任意兩個(gè)節(jié)點(diǎn)間的關(guān)聯(lián)很少，增加節(jié)點(diǎn)可以線性增加整個(gè)集群的tps，而且?guī)缀鯖]什么副作用；通過增加PUMA集群的節(jié)點(diǎn)，可以很輕松實(shí)現(xiàn)千萬tps的消息隊(duì)列，支持更多的租戶和更多的topic（隊(duì)列）。

產(chǎn)品訴求

這里主要說下某兩個(gè)產(chǎn)品對(duì)大規(guī)模集群的訴求，對(duì)應(yīng)大規(guī)模集群的兩個(gè)方面：千級(jí)數(shù)量節(jié)點(diǎn)的集群和千萬tps性能的集群

云消息服務(wù)

云化場(chǎng)景消息服務(wù)，PaaS的基礎(chǔ)中間件能力。

如上圖所示：

1）?ELB需感知每租戶到每集群的映射關(guān)系，為盡量和ELB解耦。考慮提供消息集群注冊(cè)發(fā)現(xiàn)機(jī)制和租戶與集群的對(duì)應(yīng)關(guān)系，需要ELB進(jìn)行集成；

2）?多集群下租戶訂閱服務(wù)時(shí)集群的創(chuàng)建和已有集群的選擇，需要有一個(gè)類似資源調(diào)度的算法來決定是否創(chuàng)建新的集群還是在某個(gè)已有集群里進(jìn)行擴(kuò)展；

3）?每個(gè)子集群支持多個(gè)租戶，平均10個(gè)租戶，100個(gè)節(jié)點(diǎn)，需要支持多租戶及資源的共用或隔離，節(jié)點(diǎn)擴(kuò)展后的消息分布問題；

4）?用戶不感知后臺(tái)架構(gòu)，訂閱服務(wù)后直接使用，提供統(tǒng)一的服務(wù)規(guī)格和SLA（討論點(diǎn)）。

集群初始化為一個(gè)租戶的規(guī)模（如10個(gè)節(jié)點(diǎn)），當(dāng)租戶規(guī)模增大時(shí)，擴(kuò)展消息集群的規(guī)模，按一個(gè)租戶擴(kuò)展特定節(jié)點(diǎn)的量（如10個(gè)節(jié)點(diǎn)）擴(kuò)展。當(dāng)集群分配滿時(shí)（即達(dá)到100個(gè)節(jié)點(diǎn)時(shí)），則擴(kuò)展新的集群。

由于多個(gè)租戶共享一個(gè)PUMA集群，需要PUMA提供租戶的隔離能力，其主要包括租戶創(chuàng)建topic的命名空間的隔離，性能和穩(wěn)定性的隔離，租戶對(duì)topic訪問的權(quán)限控制。

租戶與消息集群之間的對(duì)應(yīng)關(guān)系，可以是一個(gè)租戶綁定到唯一的一個(gè)集群，也可以是一個(gè)租戶綁定到多個(gè)集群，如果是后者，則需要在上層增加一個(gè)租戶topic到集群映射關(guān)系表。如果租戶只能綁定到一個(gè)集群，這樣隨著租戶業(yè)務(wù)量增加以及租戶量增加時(shí)，?需要消息服務(wù)支持大規(guī)模集群的能力。當(dāng)前設(shè)計(jì)的單集群的最大的規(guī)格為100節(jié)點(diǎn)，PUMA集群能支持多大規(guī)模，需要評(píng)估，期望能支持1000+的集群規(guī)模；另外，當(dāng)PUMA集群規(guī)模增大時(shí)，Rest proxy集群如何擴(kuò)展，也需要考慮。

云消息服務(wù)場(chǎng)景的主要需求：

1）?彈性伸縮：支持PUMA按負(fù)載的彈性擴(kuò)，為云化消息提供基礎(chǔ)能力（自動(dòng)彈性擴(kuò)容），同時(shí)支持當(dāng)增加業(yè)務(wù)或應(yīng)用的topic時(shí)，通過彈性擴(kuò)展避免應(yīng)用之間的性能影響；

2）?多租戶隔離及訪問：a.集群內(nèi)多租戶，具備租戶認(rèn)證、授權(quán)能力，租戶間業(yè)務(wù)性能和穩(wěn)定性互不影響；b.具備租戶內(nèi)的用戶的認(rèn)證、授權(quán)能力；租戶內(nèi)業(yè)務(wù)性能和穩(wěn)定性互不影響；

3）?大規(guī)模集群：PUMA提供大規(guī)模集群能力，支持1千broker節(jié)點(diǎn)的集群規(guī)模，以便應(yīng)對(duì)用戶的擴(kuò)容和海量topic的需求。

日志檢索

某日志平臺(tái)主要用于收集業(yè)務(wù)的各種日志，用于快速定界定位問題，統(tǒng)計(jì)分析業(yè)務(wù)的：質(zhì)量，容量，監(jiān)控業(yè)務(wù)告警等功能。

產(chǎn)品現(xiàn)狀：

現(xiàn)網(wǎng)存在的問題：

1、穩(wěn)定性（異常掛死）、性能不足；

2、Redis非集群，多業(yè)務(wù)使用暫未統(tǒng)一；

3、ES性能問題（不足以支撐現(xiàn)網(wǎng)的日志量入庫(kù)和檢索）；

基于PUMA的改進(jìn)方案如下：

整體系統(tǒng)的能力訴求：

1、?每秒需要處理的日志數(shù)量: 100~150W/s，2016年底1000W/S的處理能力

2、?每天處理的數(shù)據(jù)：100~200TB/天，未來具備支撐PB/天量級(jí)的能力

3、?保存時(shí)間，定位問題:建議一周(日志中樞保留一周，ES集群可以根據(jù)業(yè)務(wù)需要自行設(shè)定，Push建議最多一周)

4、?帶寬需求：每條消息長(zhǎng)度:100~300Bytes??，以上能力為國(guó)內(nèi)節(jié)點(diǎn)業(yè)務(wù)量訴求

5、查詢性能：10分鐘以內(nèi)（查詢用戶當(dāng)天的業(yè)務(wù)數(shù)據(jù)），30分鐘以內(nèi)(查詢用戶最近一周的業(yè)務(wù)數(shù)據(jù))

6、全球部署：北京、香港、北美、巴西。中國(guó)區(qū)各機(jī)房分節(jié)點(diǎn)部署，對(duì)于跨機(jī)房部署的，需要考慮策略，對(duì)vpn帶寬的占用。

該場(chǎng)景主要需求如下：

1）?PUMA取代以前的Redis部件，提供消息的日志傳輸通道；

2）?提供PUMA-ES的數(shù)據(jù)傳送通道；

3）?與Agent/Flume對(duì)接，接收Agent/Flume送過來的日志數(shù)據(jù)；

Agent為C語(yǔ)言開發(fā)，這里需要提供RESTFUL接口；

4）?峰值處理能力達(dá)到1000w TPS，來應(yīng)對(duì)全業(yè)務(wù)接入的壓力；

小結(jié)

兩個(gè)產(chǎn)品，一個(gè)需要部署千級(jí)節(jié)點(diǎn)集群來應(yīng)對(duì)用戶的擴(kuò)容升級(jí)和創(chuàng)建海量topic，另一個(gè)需要千萬tps來支撐海量日志的傳輸；歸結(jié)到一點(diǎn)就是需要puma的單個(gè)集群能支撐千級(jí)節(jié)點(diǎn)的部署和千萬tps的性能。

業(yè)界分析

PUMA的技術(shù)選型為kafka，業(yè)界分析這塊的話就主要是看一下業(yè)界部署和使用kafka集群的規(guī)模如何，我這里選取了兩組參照物：LinkedIn和青云/Ucloud；眾所周知，kafka是由LinkedIn開源的，而且領(lǐng)英公司自己也廣泛使用了kafka來做消息通信服務(wù)；青云和Ucloud是國(guó)內(nèi)的兩個(gè)云服務(wù)商，其產(chǎn)品中有基于kafka的消息隊(duì)列服務(wù)，也有一定的代表性。

LinkedIn

在LinkedIn的Kafka的系統(tǒng)上，每天有超過8000億條消息被發(fā)送，相當(dāng)于超過175TB字節(jié)的數(shù)據(jù)，另外，每天還會(huì)消耗掉650TB字節(jié)數(shù)據(jù)的消息，為什么Kafka有這樣的能力去處理這么多產(chǎn)生的數(shù)據(jù)和消耗掉的數(shù)據(jù)，對(duì)每一種消息分類是一個(gè)重要原因。在每天系統(tǒng)最繁忙的時(shí)候，他們每秒接收超過1300萬條消息，相當(dāng)于每秒2.75GB數(shù)據(jù)。去處理這所有的信息，LinkedIn運(yùn)行超過60個(gè)kafka集群，并在上面部署超過1100個(gè)Kafka節(jié)點(diǎn)；平均算下來，每個(gè)kafka集群內(nèi)有大概20個(gè)節(jié)點(diǎn)。

總體來說，由于業(yè)務(wù)需求的原因，LinkedIn未選擇使用大規(guī)模的kafka集群，而是通過搭建60+的小集群來實(shí)現(xiàn)對(duì)業(yè)務(wù)的全覆蓋。

青云/ucloud

QINGCLOUD和Ucloud，這是國(guó)內(nèi)的兩家頂尖的云服務(wù)提供商，都有使用kafka來提供消息總線服務(wù)，從他們的官網(wǎng)和用戶手冊(cè)上可以看到相關(guān)介紹，用戶創(chuàng)建kafka集群時(shí)，集群的節(jié)點(diǎn)數(shù)量都限制在20個(gè)以內(nèi)，我也注冊(cè)了相關(guān)的賬號(hào)進(jìn)行測(cè)試，發(fā)現(xiàn)在搭建kafka集群時(shí)，其集群的節(jié)點(diǎn)數(shù)量確實(shí)被限制在20個(gè)以內(nèi)：

咨詢他們的售后客服，問是否可以升級(jí)擴(kuò)容，得到的答復(fù)是在20節(jié)點(diǎn)以內(nèi)的集群可以進(jìn)行擴(kuò)容，最大擴(kuò)容到20節(jié)點(diǎn)，縮容節(jié)點(diǎn)的話需要手動(dòng)操作，先停服務(wù)，再遷移分區(qū)，最后下線節(jié)點(diǎn)，對(duì)運(yùn)行中的業(yè)務(wù)有影響；另外，兩家均沒有提供縮容分區(qū)的能力。

小結(jié)

通過分析業(yè)界使用kafka集群的情況，暫無發(fā)現(xiàn)超過100節(jié)點(diǎn)的kafka集群使用案例，而且業(yè)界所提供的擴(kuò)容縮容服務(wù)都有一定的局限性，要么對(duì)業(yè)務(wù)有影響，要么只能手動(dòng)操作，要么只能在比較小的集群規(guī)模內(nèi)進(jìn)行。

華為云計(jì)算

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。