编者按：随着企业及政府数字化转型升级，越来越多的科技公司开始进入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产物的竞争力。
原创文章，作者：百分点科技，如若转载，请注明出处：https://www.iaiol.com/news/32651
