Bonree ONE

基本介绍

Bonree ONE作为国内领先的一体化智能可观测平台，本次春季版的发布，在新一代技术变革中为生产力升级保驾护航，后台三板斧（高效能架构、高技术引擎、高质量数据）让可观测更“新质”。

架构是IT系统的骨架，决定了系统的稳定性和扩展性。高效能架构需要具备轻量化、高可用和易维护性，以适应不断变化的业务需求和技术环境。Bonree ONE在本次春季版中从以下几个方面做了技术上的提升。

特色功能

多地多中心

Bonree ONE平台支持异地多活的高可用架构。一般在金融或其他重要业务领域中，客户业务数据分布在多城市多数据中心（DC），同时对可观测性平台也是一样的能力要求。具体需要可观测平台具备数据本地存储（避免过多占用跨地带宽），多数据中心资源可以全局统一管理但权限又可以灵活，并且调用链要包含完整的跨数据中心的调用过程和详情。这对万亿级以上数据平台的技术挑战极大。Bonree ONE技术底座实现了数据本地化存储，在ClickHouse集群存储层实现分布式表，本地先计算一次后再聚合数据分析结果（当然，里面有很多技术细节的考虑），并通过OneService的统一联邦数据服务建立全局数据地图和动态路由，做到了跨地跨中心计算，既做到了数据分开存，也做到了可以全局分析，还做到了任一节点的服务高可用和数据高可用。例如我们的四地八中心底层架构：

存储瘦身

早期时候，调用链、会话、日志的数据存到了Elasticsearch。我们历史架构如下图，大数据团队需要维护多种存储。比如，告警业务A说要做AI训练，就得自己加工一份时序数据到HDFS，指标中心业务B说加工指标，就自己加工一条链路到ClickHouse，DEM业务C想做会话分析，APM业务D又想做调用链分析，日志业务E还想做日志分析，那么业务C、D、E就分别加工各自数据到ES，这就导致完全各自业务各自加工存储。这样烟囱式的发展到一定程度后，数据不好管理，资源浪费严重，并且各业务之间数据很难做关联式的统计和分析（比如用户的网络请求和后端调用链关联的多端打通场景），产品迭代越来越重。

在IT架构中，只要组件多、存储重，很多问题就会暴露。为了彻底解决数据底层割裂、资源成本、性能、稳定性等问题，本次Bonree ONE春季版将所有信号数据全部迁移到了ClickHouse中，彻底下线了ES。

经过本次Bonree ONE架构瘦身治理和全面技术优化，博睿数据公有云千亿数据量的集群，下线了所有ES机器24台（16C32G配置），扩容了10台CK，节省了58%机器成本。如果从资源占用比例看，收益更大：

ZooKeeper瘦身

众所周知，大数据很多开源引擎都用ZooKeeper做分布式协调和数据同步。作为ClickHouse大数据底座，我们原先架构也是用默认的用ZooKeeper去做数据管理。但随着数据量和数据种类不断扩充的情况下，ClickHouse集群对于ZooKeeper的压力越来越大。例如在基于实时性要求高的告警数据入库查询时，数据查询的实时性要求秒级返回，ZooKeeper会出现性能瓶颈（比如一套ZK集群最多支持5个shard），资源占用和维护成本非常高，还经常出现fullgc和zxid溢出的故障发生。显然，我们把调用链数据和日志数据迁移到ClickHouse后，原有ZK方案明显支持不住，如下图，看层次就非常复杂，20个shard需要5套ZK集群，每套ZK又有三个实例，在扩容和安装升级过程中，一步都不能错，否则就容易出问题。

本次Bonree ONE春季版中做了架构升级，我们把ClickHouse的ZK替换成了固定一套ClickHouse-Keeper的方案，同时从技术解决了多套转一套、ZK加密鉴权的问题。

安装包瘦身

在私有化安装包瘦身方面，我们技术也一直追求极致，所谓“加能力不加体积！小u盘就代表实力！”。经过一年的努力，我们安装包在依赖包精简、dockerfile镜像合并压缩、程序包精简、基础镜像瘦身等方面都做了相关治理和改造，从早期的11GB降到了本次发布的5GB左右，里面已经装进了全部可观测性的技能包（数字体验、指标分析、调用链、日志、全局拓扑、仪表盘、AI、告警，等等）。