基本介紹

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在本次春季版中從以下幾個方面做了技術(shù)上的提升。

特色功能

多地多中心

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

存儲瘦身

早期時候，調(diào)用鏈、會話、日志的數(shù)據(jù)存到了Elasticsearch。我們歷史架構(gòu)如下圖，大數(shù)據(jù)團(tuán)隊需要維護(hù)多種存儲。比如，告警業(yè)務(wù)A說要做AI訓(xùn)練，就得自己加工一份時序數(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ù)不好管理，資源浪費嚴(yán)重，并且各業(yè)務(wù)之間數(shù)據(jù)很難做關(guān)聯(lián)式的統(tǒng)計和分析（比如用戶的網(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ù)據(jù)入庫查詢時，數(shù)據(jù)查詢的實時性要求秒級返回，ZooKeeper會出現(xiàn)性能瓶頸（比如一套ZK集群最多支持5個shard），資源占用和維護(hù)成本非常高，還經(jīng)常出現(xiàn)fullgc和zxid溢出的故障發(fā)生。顯然，我們把調(diào)用鏈數(shù)據(jù)和日志數(shù)據(jù)遷移到ClickHouse后，原有ZK方案明顯支持不住，如下圖，看層次就非常復(fù)雜，20個shard需要5套ZK集群，每套ZK又有三個實例，在擴(kuò)容和安裝升級過程中，一步都不能錯，否則就容易出問題。

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

安裝包瘦身

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