做这个项目的初衷，是因为我们基于物理机的大数据基础设施面临着‘效能低、管理弱、债务重’的三大核心痛点：
1. 首先是交付效能极低。
当时我们统计过，2022 年全年有 259次 资源申请，但由于预算和审批系统未打通，平均审批时间接近 2天。这意味着业务方要用资源，得等好几天甚至更久，严重拖慢了业务迭代。
2. 其次是资源管理能力弱。
传统物理机的资源是静态的，遇到节点故障没有自愈能力，遇到业务高峰也没法快速扩容。此外，多集群混合部署时资源相互抢占，业务面临稳定性的风险。
3. 最后是历史债务沉重。 我们当时同时维护着‘大数据组件平台’和‘运维平台’两套系统，技术栈不同且功能重叠，而且缺乏标准化管理，这就导致维护成本很高。
为了解决这些问题，我主导了 ES 的全栈云原生化转型，开发了ES云原生平台，主要包括如下功能：
1. 集群搭建（Deploy）：自助申请，帮助用户快速启动和配置 ES集群
2. 集群变更（Update）：支持业务用户或SRE对集群做规格变更、配置变更、扩缩容、重启等操作
3. 索引管理（Usage）：提供创建、删除、查询索引等功能，以及索引生命周期管理
4. 集群监控（Monitor）：支持集群各个维度监控指标数据统一输出到顺丰云、并在顺丰云基础上自定义告警
5. 集群日志（Logging）：提供查询和分析 ES的集群、慢索引、慢查询及GC日志的功能，以便进行性能优化
6. 可视化（Dashboard）：提供可视化管理界面，可以对 ES数据进行简单查询和分析（优先级低）
7. 可用性（HighAvailability）：提供集群容灾、备份恢复、智能巡检、性能基线等能力
8. 安全性（Security）：提供用户和角色的管理，以及访问控制功能，保护 ES集群的安全，以及审计日志能力
第一层级：从0到1的云原生平台建设
首先是基础设施层。针对过去物理机交付周期长（24小时）、资源无法隔离的痛点，我基于 K8s + Operator 体系，配合 OpenEBS LVM本地存储方案，完成了 ES 组件的容器化建设。
我打通了私有云 API，实现了集群交付全流程自动化。这套体系目前纳管了 350套 ES 集群，将交付效率提升了 48倍（从24小时缩短至30分钟），实现了运维成本的大幅降低。
第二层级：解决有状态服务的核心痛点
平台建好后，我设计了一套POD无损迁移和上下线方案。
这一块的核心亮点是，我结合 K8s 的cordon/uncordon机制和组件的数据副本同步原理，实现了节点的跨机器无损迁移，并利用组件自身原理实现了节点优雅上下线流程。
同时，我利用 Linux Cgroup 技术实现了 CPU 配额的热加载。
这使得我们在进行节点驱逐或CPU资源升降配时，业务零感知，解决了云原生环境下‘服务连续性’的难题。
第三层级：资源容量规划
K8s Worker 节点的资源不会全量分配给 Pod，而是默认设置了 20% 的预留水位作为系统缓冲。
为了应对紧急情况，平台支持动态调整单个节点的资源水位。
在实现上，内存方面通过修改Kubelet配置文件中的预留参数，磁盘方面则通过 LVM 的 vgextend 命令扩充卷组。这两类操作均能做到即时生效，从而快速释放资源以供调度。
第四层级：内核性能调优
随着业务量达到亿级，开源版本开始出现严重的性能瓶颈，我不得不深入内核源码进行改造：
第一点是Lucene段合并优化。我在Lucene引入了根据指定段名称合并的策略，最终将索引存储降低了5倍（85G降至16G）。
第二点是容灾切换流程优化。我二次开发了ES的CCR源码，将pause/unfollow接口重构为批量处理逻辑，最终将切换耗时从1小时缩短至5分钟
评论