全图化在线系统设计

news2024/9/24 13:20:50

Pillars是什么

Pillars是一个Serverless全图化业务托管平台。Pillars应用全图化开发模型，提供丰富的运行时组件，支持CI/CD全生命周期项目管理，具备主动式资源优化能力。

Pillars解决什么问题

当前广告系统架构采用分布式微服务的设计理念，通过服务分治实现各组织间开发、运维、资源等维度解耦，并通过RPC实现服务间通信，实现多服务联动。微服务的逻辑基础是“服务自治”与“服务复用”，这些设计从软件管理、资源适配两个维度给业务系统带来了诸多好处。但随着广告业务复杂度增长，广告中台系统呈现出“服务间联动”与“流量端自治”两个趋势。这些变化趋势逐渐打破微服务理念的逻辑基础，在研发效率、持续集成、资源利用率等方面给系统带来一系列问题。
Pillars希望通过建设全图化业务托管系统，将按照服务分治的水平物理架构转变为按照业务场景分治的垂直逻辑架构，提供全业务视图的研发、运维体系，同时进一步提升在线执行引擎调度、混部的灵活性，实现算子粒度的资源智能编排，以追求资源最大化利用。

当前痛点

开发视角

瞻前顾后：在开发某个逻辑的时候，需要首先熟悉前后相关逻辑，确定依赖的前置逻辑能正确执行，确保修改逻辑对后面逻辑不会产生预期外的影响。
扑朔迷离：业务代码和实验参数高度耦合，难以清晰看到全局业务流程，难以高效清除废弃逻辑。

集成交付视角

左顾右盼：部分业务改造和系统级项目（nuwa、addebug）涉及多个模块配合上线，需要考虑上下游兼容发布等问题，费时费力。
闭关锁国：模块一旦完成划分，重新调整边界成本高（如cypher-inspire合并、inspire-sendcontrol拆分），导致系统的重构难度加大，不便于长期管理。

系统资源视角

指鹿为马：模块划分规则并未遵从系统最优原则，而是以经验主导进行面向组织分工的划分，存在系统层面的损耗。
舍近求远：星型架构下，各叶子节点服务间传输数据须经中心节点转发，造成带宽、CPU浪费，且会增加延时。

痛点的深层原因

系统熵增：业务永远在迭代，业务系统会越来越复杂。
组织分工：分工虽然提升了内部效率，但也引入了边界损耗，业务团队间、业务与中台间、中台各个模块间存在大量认知成本、协作成本。
自动化、智能化缺失：目前仍需人力介入大量重复性工作，并依赖人力处理大量经验性工作，效率低，质量低，成本高。

解决痛点

开发视角

瞻前顾后 -> 以Lambda算子为开发标准，参考TensorFlow算子实现，利用开发框架强约束开发模式，实现算子内逻辑内聚、算子间逻辑解耦。所有数据依赖通过算子的input、output显式声明，避免跨算子认知负担。
扑朔迷离 -> 用数据流图串联所有算子，提供完善的图DSL，并支持图可视化，清晰表达算子间关系。用条件语句表达图分支，便于在图上进行实验管理，实现执行流程与算子实现解耦，降低理解成本。

集成交付视角

左顾右盼 -> 建设以业务图为粒度的发布体系，用标准化、自动化的发布流程实现跨集群协同发布，并实现完备的版本管理系统，让业务同学在发布时无需关注系统繁琐细节。
闭关锁国 -> 统一算子开发框架与通信框架，建立公共算子仓库组，算子可以在各个机器间灵活移动部署，便于实现面向各种目标的模块间重组。

系统资源视角

指鹿为马 -> 对给定的业务图进行自动化、智能化切分与编排，并对切分后图片段进行全自动部署、切流、实验，提高时延约束下的资源最大化利用。
舍近求远：数据机器间的数据交互模型由RPC常用的“ping-pong模型”变为单向传递的“数据流模型”。

在新的模式下：开发走向Lambda算子化，开发具体逻辑所需的关注域逐渐缩小。psm、模块、服务等概念逐渐弱化，甚至消失，取而代之的是“图”。“图”内的编排、部署、版本管理等全部实现自动化、智能化，数据机器间的数据交互模型由RPC常用的“ping-pong模型”变为单向传递的“数据流模型”。机器资源逐步走向池化，抽象出CPU线程资源池、GPU资源池、内存池、存储池等。此外，系统还需要一系列辅助设施，如CodeGen工具、可观测工具、Debug工具等。

在这里插入图片描述