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

以你之姓@ 2022-10-07 05:46 227阅读 0赞

**本文作者：张亮** 滴滴云-商业数据 负责人

2014年加入滴滴，负责过LogAgent、Kafka、ElasticSearch、OLAP的引擎建设工作，具有丰富的高并发、高吞吐场景的架构设计与研发经验，主持构建过任务调度系统、监控系统、日志服务、实时计算、同步中心等数据体系的平台设计与研发工作。

**一、分享背景**

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

**二、建设实践**

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

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

**1、引擎体验期**

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

**1）引擎选择**

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

**2）机型选择**

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

![21e2f3896fbf0e0e486a260bca9f577a.png][]

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

**3）部署选择**

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

![d2cc45a4c7354d4a18ad36264d94c73c.png][]

滴滴Elasticsearch分角色部署实践

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

**2、引擎发展期**

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

**1）引擎PaaS平台建设**

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

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

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

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

**2）引擎服务架构升级**

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

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

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

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

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

![d3595b914845427d887a84f4ad4cd7a9.png][]

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

![76d1d84fa998673d5f3512c1690a766f.png][]

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

**3、引擎突破期**

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

**1）引擎原理深度掌控**

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

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

![883ef7193f8a27466f888a91974a3cb4.png][]

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

![640075ab7d14e7699a70da80fb0bf0f5.png][]

*  定期开展引擎原理分享与源码交流，参加社区Meetup，跟进社区Issue列表。
 *  线上问题复盘：熟读源码有利于建立引擎整体的宏观认知，线上问题才是最好的学习场地。线上故障深追Root Cause及时复盘，探寻引擎每个细节，是将知识点变成认知的高效途径。引擎同学看到问题应该像看到金子一样，眼睛发光，追根究底，才能提升引擎的掌控力。

![eda1cb6365180f30df5187c34b5ca02a.png][]

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

![c51d3f64194944a9031bb392a31ae28e.png][]

**2）引擎内部分支迭代**

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

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

![0cc193659d8dae35d7c4ec8111bdf997.png][]

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

![2b187f0aaf6249bf6b594d25190cdc45.png][]

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

**4、引擎治理期**

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

**1）透传业务价值**

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

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

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

**2）索要技术红利**

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

*  [滴滴离线索引快速构建FastIndex架构实践 ][FastIndex_]
 *  [滴滴 ElasticSearch 千万级 TPS 写入性能翻倍技术][ElasticSearch _ TPS]

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

**滴滴Logi**

滴滴Logi日志服务套件在滴滴内部经过7年多的沉淀打磨，针对日志采集、日志存储、日志计算、日志检索、日志分析各个环节，在组件能力上PAAS化建设、在引擎稳定性与扩展性上进行了针对性的优化。

目前该套件已经开源了滴滴Logi-KafkaManager，后期还会陆续开源Logi-Agent、Logi-LogX、Logi-ElasticSearchManager各PAAS套件。

1、滴滴Logi-KafkaManager Github：[https://z.didi.cn/4newP][https_z.didi.cn_4newP]

2、快速体验地址：[http://117.51.150.133:8080/kafka][http_117.51.150.133_8080_kafka] 账号密码 admin/admin

3、日常FAQ：[https://github.com/didi/Logi-KafkaManager/blob/master/docs/user\_guide/faq.md][https_github.com_didi_Logi-KafkaManager_blob_master_docs_user_guide_faq.md]

4、升级手册：[https://github.com/didi/Logi-KafkaManager/tree/master/docs/dev\_guide/upgrade\_manual][https_github.com_didi_Logi-KafkaManager_tree_master_docs_dev_guide_upgrade_manual]

5、滴滴Logi-KafkaManager云平台建设总结：

[https://mp.weixin.qq.com/s/9qSZIkqCnU6u9nLMvOOjIQ][https_mp.weixin.qq.com_s_9qSZIkqCnU6u9nLMvOOjIQ]

6、系列视频教程：[https://mp.weixin.qq.com/s/9X7gH0tptHPtfjPPSdGO8g][https_mp.weixin.qq.com_s_9X7gH0tptHPtfjPPSdGO8g]

**滴滴夜莺**

滴滴夜莺是一套**分布式高可用**的运维监控系统，最大的特点是混合云支持，既可以支持传统物理机虚拟机的场景，也可以支持K8S容器的场景。同时，滴滴夜莺也不只是监控，还有一部分CMDB的能力、自动化运维的能力，很多公司都基于夜莺开发自己公司的运维平台。

Github：[https://z.didi.cn/4WurZ][https_z.didi.cn_4WurZ]

官方文档：[https://n9e.didiyun.com][https_n9e.didiyun.com]

提问必读：[https://gocn.vip/topics/10811][https_gocn.vip_topics_10811]

语音答疑：[https://m.ximalaya.com/keji/45095827/][https_m.ximalaya.com_keji_45095827]

视频教程：[https://m.bilibili.com/space/442531657][https_m.bilibili.com_space_442531657]

二次开发：[https://xie.infoq.cn/article/30d37e98fbe52ff2a79fc04b4][https_xie.infoq.cn_article_30d37e98fbe52ff2a79fc04b4]

如果大家在使用滴滴Logi-KafkaManager和夜莺的过程中出现问题，或者有疑问需要与开发者交流的，都可以扫描下方二维码进入滴滴Logi及夜莺的开源用户群，在群中提问。

**群内有滴滴Logi-KafkaManager和夜莺项目负责人：滴滴高级专家工程师—张亮、秦晓辉等技术大咖，在线为大家解答问题**，欢迎大家长按二维码加小助手进群。（需备注Kafka或夜莺）

![908da4bf3c74887aca8050a41cb85703.png][]

[21e2f3896fbf0e0e486a260bca9f577a.png]: /images/20221005/ce046e6430d04d18a517d27dc4cf4156.png
[d2cc45a4c7354d4a18ad36264d94c73c.png]: /images/20221005/45892e82dad4435cab9bf092a408b148.png
[Logi-KafkaManager _Kafka]: https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU1ODEzNjI2NA%3D%3D%26mid%3D2247527050%26idx%3D1%26sn%3Dbafb07f4145d3125d427e3481a158436%26scene%3D21%23wechat_redirect
[https_github.com_didi_Logi-KafkaManager]: https://link.zhihu.com/?target=https%3A//github.com/didi/Logi-KafkaManager
[d3595b914845427d887a84f4ad4cd7a9.png]: /images/20221005/70b1fb5e273e438a89fd54f2b012ef98.png
[ElasticSearch]: https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU1ODEzNjI2NA%3D%3D%26mid%3D2247487159%26idx%3D1%26sn%3D49c915854e9e32cfb02f20e6874fcc6e%26scene%3D21%23wechat_redirect
[76d1d84fa998673d5f3512c1690a766f.png]: /images/20221005/fcfddf940d02472fb00ac46c30d51c9f.png
[https_kafka.apache.org]: https://link.zhihu.com/?target=https%3A//kafka.apache.org
[883ef7193f8a27466f888a91974a3cb4.png]: /images/20221005/5319d8671c284da896b1f986553e7b3e.png
[640075ab7d14e7699a70da80fb0bf0f5.png]: /images/20221005/d0966620d8ce433da764879997da0129.png
[eda1cb6365180f30df5187c34b5ca02a.png]: /images/20221005/c5c179c0c3f746d5b874977f18dccafd.png
[c51d3f64194944a9031bb392a31ae28e.png]: /images/20221005/c8fa439049ab46a09578aec4e4aa101f.png
[0cc193659d8dae35d7c4ec8111bdf997.png]: /images/20221005/90e498b643f24f05990704d9679143e4.png
[2b187f0aaf6249bf6b594d25190cdc45.png]: /images/20221005/a073dc15201947cbb1167da367d56d06.png
[FastIndex_]: https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU1NDA4NjU2MA%3D%3D%26mid%3D2247500894%26idx%3D2%26sn%3D75fc7035e8cf387ff74d06da787188e0%26scene%3D21%23wechat_redirect
[ElasticSearch _ TPS]: https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzU1ODEzNjI2NA%3D%3D%26mid%3D2247496570%26idx%3D1%26sn%3Da11ff747ce40d3aa1ccc5667b5767f21%26scene%3D21%23wechat_redirect
[https_z.didi.cn_4newP]: https://link.zhihu.com/?target=https%3A//z.didi.cn/4newP
[http_117.51.150.133_8080_kafka]: https://link.zhihu.com/?target=http%3A//117.51.150.133%3A8080/kafka
[https_github.com_didi_Logi-KafkaManager_blob_master_docs_user_guide_faq.md]: https://link.zhihu.com/?target=https%3A//github.com/didi/Logi-KafkaManager/blob/master/docs/user_guide/faq.md
[https_github.com_didi_Logi-KafkaManager_tree_master_docs_dev_guide_upgrade_manual]: https://link.zhihu.com/?target=https%3A//github.com/didi/Logi-KafkaManager/tree/master/docs/dev_guide/upgrade_manual
[https_mp.weixin.qq.com_s_9qSZIkqCnU6u9nLMvOOjIQ]: https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s/9qSZIkqCnU6u9nLMvOOjIQ
[https_mp.weixin.qq.com_s_9X7gH0tptHPtfjPPSdGO8g]: https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s/9X7gH0tptHPtfjPPSdGO8g
[https_z.didi.cn_4WurZ]: https://link.zhihu.com/?target=https%3A//z.didi.cn/4WurZ
[https_n9e.didiyun.com]: https://link.zhihu.com/?target=https%3A//n9e.didiyun.com
[https_gocn.vip_topics_10811]: https://link.zhihu.com/?target=https%3A//gocn.vip/topics/10811
[https_m.ximalaya.com_keji_45095827]: https://link.zhihu.com/?target=https%3A//m.ximalaya.com/keji/45095827/
[https_m.bilibili.com_space_442531657]: https://link.zhihu.com/?target=https%3A//m.bilibili.com/space/442531657
[https_xie.infoq.cn_article_30d37e98fbe52ff2a79fc04b4]: https://link.zhihu.com/?target=https%3A//xie.infoq.cn/article/30d37e98fbe52ff2a79fc04b4
[908da4bf3c74887aca8050a41cb85703.png]: /images/20221005/2687905f627f49029006e1d999cd7549.png