美团网■美团OCTO万亿级数据中心计算引擎技术解析 |技术|美好，一直在身边|MySQL|

美团自研的 OCTO 数据中心（简称 Watt）日均处理万亿级数据量，该系统具备较好的扩展能力及实时性，千台实例集群周运维成本低于10分钟。
本文将详细阐述 Watt 计算引擎的演进历程及架构设计，同时详细介绍其全面提升计算能力、吞吐能力、降低运维成本所采用的各项技术方案。希望能给大家一些启发或者帮助。

本文插图
一、OCTO数据中心简介1.1 系统介绍
1.1.1 OCTO系统介绍
OCTO 是美团标准化的服务治理基础设施，目前几乎覆盖公司所有业务的治理与运营。 OCTO 提供了服务注册发现、数据治理、负载均衡、容错、灰度发布等治理功能，致力于提升研发效率，降低运维成本，并提升应用的稳定性。 OCTO 最新演进动态细节可参考《美团下一代服务治理系统 OCTO2.0 的探索与实践》一文。
1.1.2 OCTO数据中心业务介绍
OCTO 数据中心为业务提供了立体化的数字驱动服务治理能力，提供了多维度的精确时延 TP（Top Percent ，分位数，最高支持6个9）、QPS、成功率等一系列核心指标，粒度方面支持秒级、分钟级、小时级、天级，检索维度支持多种复杂查询（如指定调用端 IP + 服务端各接口的指标，指定主机 + 接口的指标等）。这些功能有效地帮助开发人员在复杂的分布式调用关系拓扑内出现异常时，能快速定位到问题，也有助于研发人员全方位掌控系统的稳定性状况。
目前 Watt 承载日均超万亿条数据的10余个维度精确准实时统计。而伴随着数据量的迅猛增长，其整个系统架构也经历了全面的技术演进。
1.1.3 OCTO原架构介绍
OCTO计算引擎在重构之前，也面临诸多的问题，其原始架构设计如下：

本文插图

采集层：每个业务应用实例部署一个采集代理，代理通过将采集数据用批量 RPC 的方式发送给路由节点。
路由层：每个路由节点随机收到各服务的数据后，将同一服务的所有数据，用类似 IP 直连的方式通过 RPC 发送到计算层的同一个计算节点。同服务数据汇总到同计算节点才能进行特定服务各个维度的聚合计算。
计算层：每个计算节点采用 Akka 模型，节点同时负责分钟、小时、天粒度的数据计算集。每个计算集里面又有10个子计算 actor ，每个子计算 actor 对应的是一个维度。采用“先计算指标，再存储数据”的准实时模式。
存储层：准实时数据使用 HBase 存储，元数据及较大数据采用 KV 存储（美团内部系统Cellar）及 MySQL 存储。

1.2 问题、目标与挑战
1.2.1 原架构面临的问题

计算节点有状态，异常无法自动化迁移。计算层部署的每个节点平均负责200+服务的统计。一个节点 OOM 或宕机时，其管理的200个服务的数据会丢失或波动，报警等依托数据的治理功能也会异常。此外计算节点 OOM 时也不宜自动迁移受影响的服务，需人工介入处理（异常的原因可能是计算节点无法承载涌入的数据量，简单的迁移易引发“雪崩”），每周投入的运维时间近20小时。
系统不支持水平扩展。计算节点的压力由其管理的服务调用量、服务内维度复杂度等因素决定。大体量的服务需单独分配高配机器，业务数据膨胀计算节点能力不匹配时，只能替换更高性能的机器。
系统整体稳定性不高。数据传输采用 RPC ，单计算节点响应慢时，易拖垮所有路由层的节点并引发系统“雪崩” 。
热点及数据倾斜明显，策略管理复杂。按服务划分热点明显，存在一个服务数据量比整个计算节点200个服务总数多的情况，部分机器的 CPU 利用率不到10% ，部分利用率在90%+ 。改变路由策略易引发新的热点机器，大体量服务数据增长时需要纵向扩容解决。旧架构时人工维护160余个大服务到计算节点的映射关系供路由层使用。
- 上一页
- 1
- 2
- 3
- 4
- 下一页