编者按：随着企业及政府数字化转型升级，越来越多的科技公司开始进入ToB行业。ToB产品因为其独特的性质，与传统ToC互联网应用架构的设计有着很多不同。百分点科技深耕ToB、ToG行业多年，沉淀出了一系列重量级的ToB产品，如大数据操作系统（BD-OS）、资源服务平台等。
本文将从百分点科技重量级ToB产品大数据操作系统（BD-OS）架构设计的思路及实战出发，讲解百分点科技对ToB产品架构设计的一些经验与理解。
一、问题与挑战
大数据操作系统（BD-OS）是百分点科技一款重量级ToB产品，以大数据全栈技术能力为支撑，提供数据接入、治理、处理、管理和服务能力，实现一站式数据全生命周期管理，帮助客户高效、低成本地管理数据资产，发挥数据效能。BD-OS从2015年正式发布1.0版本到现在的6.x版本，已服务众多企业及政府客户，在此过程中，我们总结了ToB产品一般会面临的问题与挑战：
1. 产品多样化的售卖组合
产品的使用者是企业用户，企业用户对产品提供的功能会有一套自己的评判标准，所以有时会对产品提出更高的定制化需求，或者要求产品可以支撑模块化组合采购和拆分采购。
2. 复杂环境的安装部署
产品往往面临着复杂的部署环境，客户通常会要求产品部署在其内网中，并且随着信创行业发展，越来越多的客户也会要求对信创环境进行适配。
3. 可持续的产品服务
从客户的角度希望得到产品的持续服务，从产品自身的角度也希望可以逐步提升产品的竞争力，所以产品的服务体系至关重要。产品服务体系包括产品可持续升级，以及产品售后服务、需求定制等部分。
本文将以百分点大数据操作系统（BD-OS）的实战为例，从三个方面介绍上述问题在产品架构及相关流程设计上的解决办法。
二、模块化架构设计
从软件设计角度看，高内聚低耦合一直都是评判软件好坏的一个标准，但对于ToB产品而言还有一层特别的意义。ToB产品会针对某个领域集成一套完整的功能，每个客户对产品功能的需求点是不同的，他们会按自身需求挑选部分功能采购以保证成本。所以不论是从技术架构的角度还是从客户选择的角度，都需要模块化的产品架构设计。BD-OS前后端均采用了模块化的架构设计，接下来将逐一介绍具体的架构方案。
1. 后端模块化架构设计
BD-OS后端采用目前流行的微服务架构设计方法，整体服务是根据产品的业务定义划分的，分为治理服务、基础服务、业务接口服务和引擎服务四类，架构如下所示：
图1. BD-OS后端服务架构
不同类型的模块在整个产品生态中扮演着不同的身份。
治理服务模块
治理服务模块主要是负责整个产品分布式管理工作，包括配置管理与服务注册功能。配置管理提供集中化的配置查询及修改功能，避免维护者到处维护配置浪费不必要的时间；服务注册主要对产品内部其他模块提供分布式管理服务，便于各模块间的服务发现及调用。
基础服务模块
基础服务模块抽象集中了整个产品的通用共性功能，如用户角色管理、数据权限审计管理等。通过基础功能模块化，可以使开发人员更专注业务本身的功能，减少不必要的关注。
业务接口模块
业务接口模块主要是平台各个核心业务功能，所以在规划上虽然属于一个模块，但其实是一类服务的集合。在产品的迭代中会根据业务聚合度进一步的进行服务化拆分，避免不同类型的业务耦合到一起。
引擎服务模块
引擎服务与基础服务模块类似，也属于功能性服务，用于承接产品中各个业务模块的任务调度执行部分，但与基础服务不同的是，引擎服务本身也具有一定的业务，并且对技术要求更高，所以将其作为一个独立拆分的模块。
通过模块化的的设计划分，可以将每个服务涉及到的共性部分逻辑抽离，让每个业务模块功能更为聚焦，方便团队开发或者快速应对各种项目定制工作。
2. 前端模块化架构设计
前端模块化的设计与后端的设计类似，将不同的业务系统中共性的需求抽离出来，使得每个子系统只专注其自身业务。
BD-OS前端模块化采用了微前端的架构设计方案，微前端架构有如下优势：
- 技术兼容性好，各个子应用可以基于不同的技术框架开发，如VUE、React等可以在同一个产品中直接使用；
- 代码库更小、内聚性更强、维护扩展性好，并且便于独立编译、测试和部署升级；
- 耦合性更低，各个团队可以独立开发，互不干扰。
目前微前端主要有三种架构模式：基座模式、自组织模式和去中心模式。BD-OS是采用基于基座模式的乾坤（QIANKUN）框架，将一个大前端拆分为多个小型前端聚合的应用，整个架构如下所示：
图2. BD-OS前端服务架构
如上图，BD-OS前端架构分为3部分，从下至上分别为基础技术栈层、自定义组件层、应用层，接下来将分别对每一层进行具体介绍：
基础技术栈层
基础技术栈为整个产品前端部分使用的绘制工具、状态管理工具和产品构建工具等，是整个前端的技术选型，包括React、Redux、Webpack、Nodejs等。
组件层
组件层主要包含产品迭代过程中逐步沉淀的一些自定义组件和通用组件，包括调度、拓扑、布局等常见功能组件，可以供研发快速复用。
应用层
应用层是最重要的模块切分层。主要包含微前端架构的主应用、子应用部分。主应用主要包含通用性的功能，如菜单配置、样式控制等，同时也对整个微前端应用注册进行管理；子应用则更为关注具体业务。主应用和子应用均需要与QIANKUN框架进行对接，通过框架实现模块化的管理。
3. 小结
ToB产品由于其自身的复杂性，在通过模块化的架构设计及相应规范的约定后，可以减少开发新模块或优化、定制旧模块时对其他模块的影响范围，只针对一个或几个子应用进行开发改造，这样对研发、测试、运维来说可以减少相应的工作量，提升整体的工作效率，降低项目成本。
三、复杂部署环境应对设计
面对复杂的部署环境，BD-OS作为数据中台类的产品需要解决如下2个问题：
- 与不同操作系统、不同架构CPU适配的问题；
- 与不同大数据平台和数据源组件适配的问题。
针对兼容不同操作系统及CPU架构的问题，BD-OS采用了Docker化的部署方案来解决，整体方案如下：
上一节模块化的架构设计中提过，BD-OS采用的是微服务的架构方案，而每个服务都是以Docker镜像的方式进行打包的。应用服务在进行Docker化后可以消除不同环境的差异，保证应用服务的环境一致性及标准化，只需要使用服务器提供的CPU、内存等硬件资源即可。进一步可支撑客户上云的需求；退一步不管是物理机、虚拟机或是信创环境，均可快速部署。
图3. BD-OS Docker化部署架构
针对如何与各种大数据集群及数据源的适配问题，BD-OS采用抽象集群适配器的方案来解决，整体方案如下：
百分点科技通过设计一个适配器服务，将产品与大数据平台及其他第三方数据源的功能抽象到该服务中，作为中间适配层，将整个产品与平台进行解耦。该适配层向上提供通用的相关组件操作接口，如查询Hive、HBase元数据，执行各种数据源的SQL命令等；向下适配多种数据源及各种类型大数据平台，如社区版的Hadoop、CDH、HDP、百度云BMR、京东云JMR、腾讯云TBDS、华为云MRS等。
图4. BD-OS资源适配器架构
资源适配器架构如上图所示。整体架构分为3层：
- 最底层为适配层，根据集群和数据源类型分为集群数据组件适配器、JDBC规范数据组件适配器及其他数据源组件适配器。在设计上分别对不同类型的组件进行功能的抽象封装，方便后续其他类型的扩展。底层的对组件及数据源依赖的驱动包进行外部目录规划引用。在部署时，只需收集各个集群的驱动包即可，可以避免修改代码，大大地提高大数据平台适配效率、减少成本。
- 中间层为接口抽象层， 对下规范化各种类型适配器并抽象统一的结构，对上提供通用的各类组件的元数据查询、数据源等操作。
- 最上层为应用层，通过基础jar包的提供，使各应用完成自身业务与底层集群及数据源的交互。
小结
通过抽象化的设计架构可以快速适配不同的集群组件，对于不能直接兼容的集群，也可以通过只扩展该服务来快速适配，避免其他业务使用模块的改动，减少定制工作的成本。
四、产品服务体系设计
对于ToB产品来说，完善的产品服务体系是最为重要的部分，这关系到一个产品是否能健康地持续成长迭代下去。BD-OS建设了完善的产品服务体系，保证产品全生命周期运转，其整体服务体系设计如下：
图5. 产品服务体系
通过上图可以看到，BD-OS以版本迭代为主线，通过售后问题及项目定制流程来完成产品需求及体验的回流，逐步增强产品功能，同时给予客户更好的使用体验。接下来文本将对每一部分流程进行具体的介绍。
1. 版本迭代流程
BD-OS产品在版本迭代流程上设计了一套适合自身的产品开发测试流程，具体如下：
- 对于同一个产品，每个版本都要建立相应的版本主干分支，研发人员只能在个人分支上开发，开发完成的功能才能合并到该版本主干分支上。
- 对于涉及到的数据库变更也需要在数据库对应版本主干分支进行维护，同时应保证提供一份数据转换脚本，供产品升级使用。
- 通过配置好的DEVOPS流程，自动打版程序仅从主干分支拉取代码进行测试以及后续的产品打包。
- 当产品测试流程完成并确认发版后，产品会输出两个产品包：全量部署包和增量升级包。全量产品包用于全新环境的部署，主要包含全部部署工具及软件包；增量升级包则约定为对上一个小版本的升级，因此增量包内部除包含软件包外，还有一个基线库的转换脚本，用于协助转换已经部署版本的数据。
通过上述流程规范，可以保证每个版本代码均可追溯，实现标准产品的升级功能，提高产品的生命力。
2. 售后流程
BD-OS的售后工作主要通过售后工单系统进行问题的收集。用户可以在工单系统上为产品提交自己的问题工单，问题主要分为3大类：bug类、使用类、需求类。
对于bug类问题，会直接指定到售后进行问题的排查修复，通过增量补丁包的方式为现场升级。
对于使用类问题，用户可以通过查阅产品FAQ进行处理，如果FAQ中对相关问题描述有所缺失，可以直接与人工售后人员进行反馈解决。售后人员会定期复盘整个产品问题，总结到FAQ中来，以节省交流成本。
对于需求类问题，会通过产品进行需求的评估解读，待需求确认后则按项目定制的流程去解决该问题。
3. 项目定制流程
项目定制来源主要有两种，一种是通过售后渠道反馈回来的需求，这类需求通常不会很大；另一类是产品在售卖时约定提供的专属定制功能。
对于产品来说，模块化的架构已经可以减少项目定制所影响的测试范围，和在修改代码后可能引起的其他潜在风险。但是当定制的项目变多、客户变多的时候，如何维护这些定制的代码版本才是更大的问题。
对于项目定制而言，细微的需求也需要独立进行维护，否则会导致产品主干与定制版本的管理混乱。基于此，BD-OS产品约定定制版本进行独立的维护，避免与产品主干版本代码交叉。项目定制化也同产品版本迭代一样采用整体的版本流程管理方式来进行控制，包括需求评审、产品研发设计、功能测试等，最终通过提供已经部署版本的增量需求升级包为客户环境进行产品升级。
4. 小结
通过上述三部分的流程规划及建设可以看到，BD-OS产品可以通过售后及项目定制产生的问题与需求不断反哺产品自身，并且通过完善的版本迭代流程，可以满足产品的持续升级，保持其自身的行业竞争力，更好地服务客户。
总结
通过BD-OS整个产品架构体系的介绍可以看到，对于ToB产品架构设计需要同时对技术架构与流程规范两个维度进行建设。
从技术架构角度来看，ToB产品的架构关注点主要是整个产品体系的技术架构方案，包括组件选型、模块规划、组件抽象、运维部署方案等工作。
从流程规范角度来看，通过统一的流程规范，对外可以快速响应客户的问题与需求，更好地服务客户；对内在解决客户问题及需求的同时，可以不断将这些问题和需求迭代到产品内部，保证产品生命周期延长，不断适应市场，保持ToB产品的竞争力。
