基本介紹

Bonree ONE作為國內領先的一體化智能可觀測平臺，本次春季版的發(fā)布，在新一代技術變革中為生產力升級保駕護航，后臺三板斧（高效能架構、高技術引擎、高質量數據）讓可觀測更“新質”。

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

特色功能

多地多中心

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

存儲瘦身

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

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

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

ZooKeeper瘦身

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

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

安裝包瘦身

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