基于开源引擎打造自主可控服务体系

1、分享背景

在滴滴负责过 LogAgent、Kafka、Flink、Elasticsearch、Clickhouse 等开源大数据引擎服务体系建设工作，走过很多弯路，趟过很多坑，积累了一些实战经验；近一年疫情肆虐，加速了企业数字化转型的步伐，与数十家互联网、金融、证券、教育企业进行了深度交流，大家对基于开源数据引擎建设自主、可控、安全的服务体系有强烈诉求，常见的困惑是如何基于开源引擎，结合企业特点与发展阶段，进行高 ROI 的服务体系建设。

2、建设实践

滴滴基于开源引擎搭建大数据基础设施，始于数据驱动业务运营与商业决策的 BI 需求，随着实时数据流量达到百 MB/S，存储达到 PB 级，开源数据引擎的服务运营会遇到各种各样的稳定性、易用性、运维友好性挑战。经历了四个阶段：引擎体验期、引擎发展期、引擎突破期、引擎治理期，不同阶段遇到的痛点问题与服务挑战各不相同：

• 引擎体验期：伴随业务快速发展，引擎的选择、版本的选择，机型的选择、部署架构的设计，复盘来看是早期稳定性工作的关键抓手。
• 引擎发展期：随着引擎用户规模的增长，日常运营过程中的问题答疑、最佳实践落地、线上问题诊断消耗团队 60%+的精力，亟需大数据 PAAS 层建设，降低用户引擎技术学习、应用、运维门槛，提升用户自助服务能力。
• 引擎突破期：随着集群规模的膨胀、业务场景的多元，势必触碰开源引擎的能力边界，亟需构建基于开源引擎的内部迭代机制，既需要与开源社区紧密协同，平滑版本升级，享受社区的技术红利，又需要在开源引擎的基础上进行 BUG FIX 与企业特性增强。
• 引擎治理期：随着 PAAS 平台的构建，引擎版本的快速迭代，会衍生三大类问题：未区分 SLA 场景的混用、超出引擎能力边界的误用、没有成本意识的滥用。导致引擎服务口碑低、资源（机器+人力）ROI 业务价值低，亟需基于元数据驱动的引擎治理体系建设。

2.1、引擎体验期

解决特定技术问题的开源引擎众多，比如消息队列有 Kafka、pulsar、rocketmq 等，技术选型对于服务的 SLA、运维保障至关重要，严重影响幸福感与价值感。

• 引擎选择

要综合考虑社区的 Star 数、Contributor 数，国内是否有 PMC 或 Committer；应用的广泛度，有无众多大厂生产实践背书，线下 Meetup 是否频繁，线上问题答疑响应速度，线上最佳实践资料是否丰富，部署架构是否精简等多种因素。

• 机型选择

业务从应用场景上可以分为 IOPS 场景与 TPS 场景，开源引擎可以分为 CPU 密集型、IO 密集型、混合型。以分布式搜索引擎 Elasticsearch 为例， 企业级搜索场景，随机 IO 频繁，对磁盘的 IOPS 能力要求高，SSD 磁盘是刚需；CPU 消耗需要根据查询复杂度、QPS 来评估此业务场景对 CPU 的诉求；推荐的做法是模拟业务场景做 BenchMark，摸底引擎在特定场景下的性能表现，为机型选择提供依据，下图是滴滴 Elasticsearch 引擎在做机型选择时的压测验证。

基于引擎原理与业内最佳实践建议，结合应用场景与压测结果，根据当下可选机型做选择，理想状态是 CPU、磁盘容量、网络 IO、磁盘 IO 资源均衡使用，尽量让 CPU 成为瓶颈。另外随着引擎的不断优化，软硬件基础设施的发展，机器过保置换是常态，最佳机型选择是一个动态演进的过程，滴滴运维保障团队 2020 年进行了新一轮机型优化与场景的调优，Elasticsearch 日志集群成本降低了一半，CPU 峰值平均利用率达到了 50%。

• 部署选择

以 Elasticsearch 为例，最小高可用部署集群是 3 个节点，单节点承担 Master Node、Client Node、 Data Node 三种角色。一般 3 到 5 个节点集群规模影响不大，一旦到几十个节点，写入吞吐量达到百 MB/S，节点网络处理线程池、内存资源竞争突显，元数据处理与索引数据处理资源未隔离，会导致集群元信息出现同步性能或一致性问题，进而诱发集群不可用，所以达到了一定体量后，需要考虑分角色部署。

滴滴Elasticsearch分角色部署实践

用户来申请所需引擎服务，需要结合业务重要程度给出合理部署架构，常见的有单租户单集群 VS 多租户大集群两种模式。引擎体验阶段，对引擎的掌控力有限，线上服务稳定性要求高，延迟与抖动敏感，建议选择独立集群方案；线下场景在乎的是整体资源利用率，RT 抖动不敏感，建议走大集群多租户的部署架构。

2.2、引擎发展期

随着引擎服务业务方的持续增长，集群个数（10+）与集群规模快速增长（100+）。一方面会遇到用户咨询与答疑量激增的问题，有引擎上手门槛高的原因，更多的是资源申请、Schema 变更等高频用户操作未平台化赋能有关；另一方面会触碰到运维保障能力边界，指标体系不完备，问题诊断低效，缺乏降级、限流、安全、跨 AZ 高可用的服务体系支撑，运维人员疲于奔命 。这个阶段需要做好两个方面的工作，一方面亟需提升引擎用户、运维保障人员的工作效率，将高频的变更或操作平台化实现，另一方面需要补足开源引擎在运维友好性上的短板，构建引擎的指标体系，高可用体系，进行服务架构升级。

2.2.1、引擎 PAAS 平台建设

保姆式人肉支撑用户高频资源创建、Schema 变更等操作，在引擎建设初期用户不多的情况下尚能应对。随着引擎服务用户的增多，引擎上手门槛高，最多有一个 Quick Star 的小白用户指南；官方用户手册，侧重功能性描述，缺乏结合业务场景，给出最佳实践的场景化指导的问题充分暴露， ALL IN ME 的用户服务体系成为引擎后向前赋能业务的瓶颈。

一般开源引擎都有自己的 Metric 指标体系，庞杂且晦涩难懂，缺乏对引擎业务过程的深度理解；另外引擎都有自己的原子 API 能力，脚本化的实现了高频操作，操作过程不透明，缺乏 Double Check 的强制机制容易存在安全与归零风险。

综上亟需一套 Paas 云管系统，面对普通用户降低接入和使用成本，针对常见问题给出 FAQ，针对业务场景沉淀最佳实践。针对运维保障人员，打造全托管的引擎服务，需要体系化的构建引擎的指标体系来提升问题定位的效率；需要平台化的实现集群的安装、部署、升级、扩缩容的自动化执行，提升集群变更效率与安全性。

以滴滴 Kafka PaaS 云平台 Logi-KafkaManager 为例介绍平台建设理念，具体设计参见：滴滴开源Logi-KafkaManager 一站式Kafka监控与管控平台，已开源https://github.com/didi/Logi-KafkaManager。

2.2.2、引擎服务架构升级

开源项目一般会开放其核心能力，定义好客户端与服务端的交互协议，周边生态对接、不同语言 SDK 版本的维护基本都交给开发者自己贡献，很多企业级特性比如租户定义，租户认证，租户的限流等都交给用户自己拓展实现。

在开源服务应用早期，往往是研发人员因业务需要引入，对引擎只有基本原理的了解，为了填补开源引擎在安全、限流、灾备、监控等方面的不足，往往都由业务/中间件架构师选择自己熟悉语言对开源 SDK 做一层切面包装，对业务侵入性做到最低，自己维护 SDK 版本，统一推广与升级。

随着业务的不断拓展，业务中台化和微服务化的落地，伴随着人员和组织的膨胀与熵增，SDK 的能力增强和 BugFix 变更变得异常艰难，推动业务升级 SDK，沟通与落地的成本极高，需要要做好压测、降低业务侵入、论证业务收益、配合业务发布节奏等各种工作，SDK 收敛的周期以年为单位，SDK 的引擎服模式已无法支撑业务快速发展的需要。

基于以上这些原因，业界普遍采用了经典 Proxy 代理架构，在服务端与客户端之间架起了桥梁，滴滴内部很多引擎都有对应的落地实践，比如 Kafka-GateWay，ES-GateWay，DB-Proxy，Redis-Proxy 等，下面以滴滴 Elasticsearch 服务为例，介绍 Proxy 架构建设实践。

一、在 Elastic Proxy 层承接企业特性的拓展如安全、限流、高可用，突破大数据引擎的集群规模扩展瓶颈，用户既能享受多租户共享集群、独享集群、独立集群不同 SLA 保障等级的服务模式，又不用关心底层物理集群与资源的细节，构建了一套全托管的服务形态

二、跨大版本升级，不管是存储格式、通讯协议、数据模型、都有许多不兼容的点，可以依托于 Proxy 架构实现跨大版本平滑升级，以下是滴滴 2019 年从 ES2.3 跨版本升级 6.6.1 的架构实践，详情参见滴滴ElasticSearch平台跨版本升级以及平台重构之路

依托 Proxy 的平台架构真正做到了底层引擎服务与上层业务架构的解耦，为后续底层引擎技术创新、服务架构快速迭代打下了坚实的基础！

2.3、引擎突破期

随着业务的快速发展，实时峰值流量达到 GB/S，离线数据增量达 TB/天，不论是数据吞吐量还是集群规模都达到了开源引擎的能力边界。一方面低频故障场景比如磁盘故障、机器死机、Linux 内核问题，在集群实例达到数百近千规模时频出；另一方面引擎在极端场景的 BUG 高概率被触发。都需要对引擎有深度的掌控力，能进行日常 Bug Fix 与内部版本的迭代，最终做到对引擎的自主与可控！

2.3.1、引擎原理深度掌控

随着引擎服务业务方的拓展，引擎的商业价值凸显，企业逐步搭建专门的引擎研发团队，如何展开对开源引擎的深度学习与改进，以及后续如何 Follow 社区的节奏，在享受社区技术迭代红利的同时实现企业增强特性的落地，结合在滴滴的实践经验，以 Kafka 为例抛出一些自己的理解。

一、快速熟悉开源代码，需要搭建本地调测环境，熟悉打包、编译、部署各个环节，跑通测试用例，学会基于测试用例进行功能调试，熟读官方用户与开发文档：https://kafka.apache.org

二、熟悉引擎的启动与日常运行日志，熟悉功能模块的主干流程与运行原理

三 、定期开展引擎原理分享与源码交流，参加社区 Meetup，跟进社区 Issue 列表

四、线上问题复盘：熟读源码有利于建立引擎整体的宏观认知，线上问题才是最好的学习场地。线上故障深追 Root Cause 及时复盘，探寻引擎每个细节，是将知识点变成认知的高效途径。引擎同学看到问题应该像看到金子一样，眼睛发光，追根究底，才能提升引擎的掌控力。

五、展开混沌工程，梳理引擎各异常场景，结合异常运行日志与监控指标，掌握该场景引擎的运行原理，明确引擎能力边界，做好稳定性保障的预案。

2.3.3、引擎内部分支迭代

线上引擎 Bug：一般有两种解法，一种是社区有对应的 Issue/Feature 已解决，我们合并对应的 Patch 到本地维护的分支版本，进行 Bug 修复；另一种我们向社区提交 Issue，提出解决方案，按照社区 Patch 提交流程进行测试与 Review，最终合并到当前版本。滴滴每年累计向 Apache 社区包括 Hadoop，Spark，Hive，Flink，HBase， Kafka，Elasticsearch，Submarine，Kylin 开源项目贡献 150+Patches。

企业级特性研发：引擎在内部服务的时候，一方面需要跟企业的 LDAP、安全体系、管控平台对接，另一方面，企业增强的引擎特性，实现方式比较本地化或者是极端小众的场景，社区不接收对应的 Patch，我们需要维护自己的特性列表和拓展实现。在维护企业特性方面修改尽可能内聚，能够拓展引擎接口实现的尽量插件化的实现，方便后续版本升级与本地分支维护，以滴滴 Elasticsearch 为例

随着社区版本的发展，企业内部分支的演进，需要定期跟进社区版本，享受社区红利，升级方案的制定需要非常严谨，涉及的环节和评估的事项较多，以滴滴 Elasticsearch 7.6 版本为例进行说明

一般涉及版本特性梳理，新特性的体验，评估升级收益，评估版本的兼容性；内部特性反向合并到开源版本，做好功能测试、性能测试、兼容性测试；制定详细升级与回滚方案，集群的升级计划，评估用户的改动与影响面等工作。

2.4、引擎治理期

引擎治理的核心目标是向上透传业务价值，向下索要技术红利，核心是通过数据看清问题，找到 ROI 最高的切入点，同时配套推动业务改造的核心抓手，讲清引擎服务的长期价值，保障技术持续的投入和价值创造！

• 透传业务价值

随着引擎服务业务方的增多，业务方应用场景持续动态演进，一方面我们可以通过资源利用率看清资源 ROI 情况，另一方通过用户对 RT 的敏感度，服务运行稳定性关注度，应用场景的重要程度，定期 Review 分级保障体系。

核心业务，在运维保障的精力投入、核心硬件资源的倾斜程度，独立集群的服务模式，高可用架构的设计，不遗余力的守好稳定性底线，就是创造了最大的业务价值！

非核心业务，通过业务价值分模型，配合组织建设抓手，进行红黑榜排名运营，鼓励“越用越好，越好越用“的正向增长飞轮；对用信用分高的客户，服务响应、资源申请、业务保障都给予更多的倾斜，最终保障整体资源 ROI 的最大化！

• 索要技术红利

服务运营通常都满足 2-8 原则，20%的业务特别核心，分级保障机制运营合理，对于服务运营方压力可控，在保障核心业务价值基本面的情况下，需要对剩下的 80%的业务方，在资源、性能、成本、稳定性上，从平台层面进行统一治理与优化，结构化降低服务成本，提升服务质量，打造一个人人为我，我为人人的正向服务口碑体系建设，基于完善的指标体系，我们可以洞察出开源系统的软件瓶颈，根据 ROI 分阶段优化与创新，具体案例可以参考，我们在 ES 上的几个技术创新

滴滴离线索引快速构建FastIndex架构实践

滴滴 ElasticSearch 千万级 TPS 写入性能翻倍技术剖析

当业务的体量达到一定的规模，技术创新的商业价值得以体现，以上的优化每年都给公司节省近千万的成本，技术的价值得到了充分的体现。

3、写在最后

滴滴大数据引擎服务体系 100%基于开源引擎构建，我们从开源社区收益匪浅，滴滴大力提倡开源，我们也陆续将滴滴引擎的一些最佳实践逐步开源，回馈开源社区，详情参见7年沉淀之作--滴滴Logi日志服务套件