基本介紹

Bonree ONE作為國內(nèi)領(lǐng)先的一體化智能可觀測平臺,，本次春季版的發(fā)布，在新一代技術(shù)變革中為生產(chǎn)力升級保駕護(hù)航,，后臺三板斧（高效能架構(gòu),、高技術(shù)引擎、高質(zhì)量數(shù)據(jù)）讓可觀測更“新質(zhì)”,。

架構(gòu)是IT系統(tǒng)的骨架,，決定了系統(tǒng)的穩(wěn)定性和擴(kuò)展性。高效能架構(gòu)需要具備輕量化,、高可用和易維護(hù)性,，以適應(yīng)不斷變化的業(yè)務(wù)需求和技術(shù)環(huán)境,。Bonree ONE在本次春季版中從以下幾個(gè)方面做了技術(shù)上的提升,。

特色功能

多地多中心

Bonree ONE平臺支持異地多活的高可用架構(gòu),。一般在金融或其他重要業(yè)務(wù)領(lǐng)域中，客戶業(yè)務(wù)數(shù)據(jù)分布在多城市多數(shù)據(jù)中心（DC）,，同時(shí)對可觀測性平臺也是一樣的能力要求,。具體需要可觀測平臺具備數(shù)據(jù)本地存儲（避免過多占用跨地帶寬），多數(shù)據(jù)中心資源可以全局統(tǒng)一管理但權(quán)限又可以靈活,，并且調(diào)用鏈要包含完整的跨數(shù)據(jù)中心的調(diào)用過程和詳情,。這對萬億級以上數(shù)據(jù)平臺的技術(shù)挑戰(zhàn)極大。Bonree ONE技術(shù)底座實(shí)現(xiàn)了數(shù)據(jù)本地化存儲,，在ClickHouse集群存儲層實(shí)現(xiàn)分布式表,，本地先計(jì)算一次后再聚合數(shù)據(jù)分析結(jié)果（當(dāng)然，里面有很多技術(shù)細(xì)節(jié)的考慮）,，并通過OneService的統(tǒng)一聯(lián)邦數(shù)據(jù)服務(wù)建立全局?jǐn)?shù)據(jù)地圖和動態(tài)路由,，做到了跨地跨中心計(jì)算，既做到了數(shù)據(jù)分開存,，也做到了可以全局分析,，還做到了任一節(jié)點(diǎn)的服務(wù)高可用和數(shù)據(jù)高可用。例如我們的四地八中心底層架構(gòu)：

存儲瘦身

早期時(shí)候,，調(diào)用鏈,、會話、日志的數(shù)據(jù)存到了Elasticsearch,。我們歷史架構(gòu)如下圖,，大數(shù)據(jù)團(tuán)隊(duì)需要維護(hù)多種存儲。比如,，告警業(yè)務(wù)A說要做AI訓(xùn)練,，就得自己加工一份時(shí)序數(shù)據(jù)到HDFS，指標(biāo)中心業(yè)務(wù)B說加工指標(biāo),，就自己加工一條鏈路到ClickHouse,，DEM業(yè)務(wù)C想做會話分析，APM業(yè)務(wù)D又想做調(diào)用鏈分析,，日志業(yè)務(wù)E還想做日志分析,，那么業(yè)務(wù)C、D,、E就分別加工各自數(shù)據(jù)到ES,，這就導(dǎo)致完全各自業(yè)務(wù)各自加工存儲。這樣煙囪式的發(fā)展到一定程度后,，數(shù)據(jù)不好管理,，資源浪費(fèi)嚴(yán)重,，并且各業(yè)務(wù)之間數(shù)據(jù)很難做關(guān)聯(lián)式的統(tǒng)計(jì)和分析（比如用戶的網(wǎng)絡(luò)請求和后端調(diào)用鏈關(guān)聯(lián)的多端打通場景），產(chǎn)品迭代越來越重,。

在IT架構(gòu)中,，只要組件多、存儲重,，很多問題就會暴露,。為了徹底解決數(shù)據(jù)底層割裂、資源成本,、性能,、穩(wěn)定性等問題，本次Bonree ONE春季版將所有信號數(shù)據(jù)全部遷移到了ClickHouse中,，徹底下線了ES,。

經(jīng)過本次Bonree ONE架構(gòu)瘦身治理和全面技術(shù)優(yōu)化，博睿數(shù)據(jù)公有云千億數(shù)據(jù)量的集群,，下線了所有ES機(jī)器24臺（16C32G配置）,，擴(kuò)容了10臺CK，節(jié)省了58%機(jī)器成本,。如果從資源占用比例看,，收益更大：

ZooKeeper瘦身

眾所周知，大數(shù)據(jù)很多開源引擎都用ZooKeeper做分布式協(xié)調(diào)和數(shù)據(jù)同步,。作為ClickHouse大數(shù)據(jù)底座,，我們原先架構(gòu)也是用默認(rèn)的用ZooKeeper去做數(shù)據(jù)管理。但隨著數(shù)據(jù)量和數(shù)據(jù)種類不斷擴(kuò)充的情況下,，ClickHouse集群對于ZooKeeper的壓力越來越大,。例如在基于實(shí)時(shí)性要求高的告警數(shù)據(jù)入庫查詢時(shí)，數(shù)據(jù)查詢的實(shí)時(shí)性要求秒級返回,，ZooKeeper會出現(xiàn)性能瓶頸（比如一套ZK集群最多支持5個(gè)shard）,，資源占用和維護(hù)成本非常高，還經(jīng)常出現(xiàn)fullgc和zxid溢出的故障發(fā)生,。顯然,，我們把調(diào)用鏈數(shù)據(jù)和日志數(shù)據(jù)遷移到ClickHouse后，原有ZK方案明顯支持不住,，如下圖,，看層次就非常復(fù)雜，20個(gè)shard需要5套ZK集群,，每套ZK又有三個(gè)實(shí)例,，在擴(kuò)容和安裝升級過程中，一步都不能錯(cuò)，否則就容易出問題,。

本次Bonree ONE春季版中做了架構(gòu)升級,，我們把ClickHouse的ZK替換成了固定一套ClickHouse-Keeper的方案，同時(shí)從技術(shù)解決了多套轉(zhuǎn)一套,、ZK加密鑒權(quán)的問題,。

安裝包瘦身

在私有化安裝包瘦身方面，我們技術(shù)也一直追求極致,，所謂“加能力不加體積,！小u盤就代表實(shí)力,！”,。經(jīng)過一年的努力，我們安裝包在依賴包精簡,、dockerfile鏡像合并壓縮,、程序包精簡、基礎(chǔ)鏡像瘦身等方面都做了相關(guān)治理和改造,，從早期的11GB降到了本次發(fā)布的5GB左右,，里面已經(jīng)裝進(jìn)了全部可觀測性的技能包（數(shù)字體驗(yàn)、指標(biāo)分析,、調(diào)用鏈,、日志、全局拓?fù)?、儀表盤,、AI、告警,，等等）,。