百度垂类离线计算系统发展历程( 二 ) _垂类离线计算

文章插图
如上图所示，灰色部分是业务外层接入的数据系统，最开始的时候只有XML、POST 和数据队列的这种模式。蓝色部分就是业务没有自定义时候原始的数据框架代码。红色部分就是为了针对业务自定义需求引入的框架模块：
用户数据代理：主要是为了适配业务数据接入方式，数据的协议打平，主要是不同用户协议的RPC做建库层的数据转化。
用户通用需求：主要是为用户共性需求做统一处理，会根据不同业务的不同配置做功能处理：比如业务图片视频的转化处理，业务用户版本管理处理以及用户的核心机制等。
统一数据加工模块：主要是为了统一用户数据的加工处理，主要是给所有接入的业务的数据提供了一个可以数据加工的入口。
3.2 业务处理架构
如上文所述3.1架构核心价值是自定义加工能力的从0到1的建设，然而随着业务的快速发展，越来越多的业务需要自定义加工能力。业务自定义加工的需求从原来个位数迅速膨胀了10倍。因此，为了满足业务在自定义开发上易用性和稳定性的诉求，将原来3.1的中心化的处理模式升级成为服务框架的模式。总体上来说，当前阶段的计算系统建设已经基本具备了服务层和业务层两层：

文章插图
业务层：业务通过平台已经基本上可以实现，基础的服务管理。
服务层：对计算引擎进行重构，让新的服务框架支持业务的高效开发。
下面会对该系统的部分细节进行详细说明。
3.2.1 业务特点
由于3.1中上一代系统数十个业务自定义需求统一在同一个模块里面开发&统一线上运行，遇到了主要如下几方面问题：
效率：业务在相同的模块里面开发，导致业务开发上线的过程中经常遇到冲突，以及上线排队的问题，导致整体生效周期比较长。
稳定性：由于这种业务流量混合的模式隔离性比较差，导致单个业务出问题，经常会影响所有的业务。
因此，架构构建出完善的服务框架，业务可以基于服务框架构建自己的业务代码，从效率和稳定性两个方面解决上述问题：
效率：服务开发上线的过程是完全隔离的，业务在开发上线的过程中完全没有业务阻塞，整体服务上线周期从天级缩短到小时级别。
稳定性：由于每个业务服务执行逻辑都有完全独立的App，导致业务的稳定性大大提升，不会存在业务之间的互相影响。
3.2.3 核心设计
业务处理框架：建设一个数据处理框架，业务可以基于这个框架来实现自己的业务处理功能。
任务平台：每个任务注册、升级、管理都可以通过任务平台来进行管理。
统一网关：所有数据的统一入口，统一接收上游数据，并且做数据的转发和分发。
业务APP：每个业务都有自己独立服务的app，每个业务开发是基于框架的独立分支开发，上线是每个业务单独上线，业务处理的服务流量也都是完全隔离的。
3.3 Serverless架构
如上文中3.2表述已经解决系统隔离性的问题，业务快速发展从最开始的几十个，发展到上百个业务应用。当业务发展到井喷状态后，服务框架的形式已经完全不能满足业务的开发需求。
Serverless架构如下图所示，此时计算系统整体版图已经相对完善，相比上一代计算架构，不仅仅业务层包含的全流程的优化，提供了完整的工具功能；服务层充分考虑的架构的设计和复用，同时增加控制层增加智能调度的功能针对系统流量进行资源的动态调度。

文章插图
下面会对该系统的部分细节进行详细说明。
3.3.1 业务特点&解决问题
业务学习成本：大量的新业务接入需要进行开发，导致框架本身学习成本需要几天的时间，新业务的接入和开发的时间基本上都在周级别。
资源如何节省：大量的业务也带来app的高速膨胀，原来接入的数百台机器已经用满，到了资源瓶颈，当前的资源量无法支持业务的快速膨胀。
3.3.3 核心设计