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

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日志服务套件

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/f0bce9e63733df1a957db628d
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券