知识卡片

第一代PaaS完整闭环设计的落地教训:平台的理想范式与业务的真实诉求相冲突

普通读书笔记卡

内容

芒果TV第一代PaaS平台Nebulium Engine(NBE)试图打通一个业务从生到死的每一个环节,是一个完整闭环的设计——平台自己定义了一套强制性的范式和规则,要求业务方必须遵守,其中平台团队因为有豆瓣App Engine的经验,比较推崇服务拆分和微服务化这套理念。但在真实落地时,平台方的理想和业务方的现实处境发生了正面冲突:业务方当时面对的现实是”流量现在都快撑不住了,还要拆分”,业务方普遍采用的是”一份代码通过不同启动命令实现线上角色切换”这种更实用主义的做法,和平台方期望的规范化拆分方式存在重大矛盾——尽管从技术角度看,第一代NBE本来只需要业务方增加一个App.yaml配置文件就能让大部分业务直接Docker化,接入成本本不算高,但双方在”业务代码该如何组织、角色该如何拆分”这个更深层的理念上分歧太大,导致落地阻力极大,甚至平台团队自己的人都被迫直接参与到业务组的开发中去帮忙推进。这次教训促使团队彻底反思并转向了第二代(Project Eru)的设计哲学。这个案例给出了一条平台型基础设施建设的重要教训:一个技术平台即使在纯技术接入成本上做得足够低(只需加一个配置文件),如果它背后隐含的强制性规范和业务方当下的真实处境、优先级存在根本冲突,接入门槛低这个优势也会被这种理念层面的抵触完全抵消——平台设计者需要区分清楚”业务方不愿意接入是因为技术改造麻烦”还是”业务方不愿意接入是因为不认同平台强加的组织方式”,后者往往是更难解决、也更容易被低估的落地障碍。

参考来源

- 位置:《高可用架构(第1卷)》第4章《容器与云计算》"4.4 解析Docker在芒果TV的实践之路"节,"4.4.12 疑问与解惑"(源文件:_epub-src/OEBPS/Text/Chapter4_4_13.xhtml) - 结论依据:原文说明"NBE第1代是一个纯种PaaS去做的,那么自然有强制性的范式和规则要求业务方遵守……但在业务方面,我觉得流量现在都快撑不住了,还拆分……但是就是因为我们两方在这个业务代码角色和拆分上有重大矛盾,导致落地阻力非常大",直接支撑本卡片结论。 - 原始内容:NBE第1代是一个纯种PaaS去做的,那么自然有强制性的范式和规则要求业务方遵守,其中我这边因为DAE带来的一些经验,比较推崇与服务拆分和微服务化。但在业务方面,我觉得流量现在都快撑不住了,还拆分……导致落地阻力非常大,以至于我本组的人都直接参与业务组开发了。