前言

       目前汽车行业正在经历从传统燃油车向新能源汽车和智能汽车的转型，这不仅包含了产品的更新换代，也涉及整个产业链的优化升级，以及设计、办公方式方法的效率提升和安全保障。某商用车公司在研发工作场景复杂化、工程师角色多样化的转型趋势下，通过实现办公、设计等全面云化来满足企业在不同场景下的研发办公环境需求，同时自主研发基于各场景全面云化的数据交互平台，满足各云平台之间数据交互的需求，提升研发工作效率，节约开发成本。

1 汽车行业全面云化带来的数据交互需求

       科技发展、技术迭代的日新月异，使汽车行业快速的从传统燃油车向新能源、智能化升级，同时也引入了先进的开发、仿真等辅助工具，使汽车商品开发周期越来越短。

       在并行开发、快速推进的汽车研发业务工作中，研发人员在同一时间身兼多职，需要在短时间内进行多次角色切换，使用不同的工具完成会议讨论等办公内容、方案及代码设计等开发内容、调试验证等试验内容。

       为此，在当前5G网络普及的条件下，云化办公所提供的共享硬件和数据资源，使设计人员摆脱了对高性能台式工作站的依赖，解放了办公场所远离试验道路的约束，同时又保证了数据存储于公司的云平台内，保障了数据安全，是当前汽车行业推崇和推进的办公方式。

       但在全面云化战略的具体实施过程中，办公、设计、试验等各类场景，对软件、硬件资源、数据保密等又提出了不同的要求，简单划分可分为以下三类：

       第一类为日常办公交互场景，主要使用office、浏览器、会议、邮件等办公软件，数据涉密程度较低，需要保证信息交流便利性；

       第二类为机械设计及仿真场景，主要使用Creo、CATIA等三维CAD设计软件，以及业务衔接较强的Hyperworks等CAE仿真软件，生成和使用的数据主要为三维数模，数据涉密程度高，应限定人群交互使用；

       第三类为软件开发与验证场景，主要Python、Java等软件开发工具，以及对应的代码管理和测试程序。在汽车电控化、智能化的趋势下，数据越来越多，功能越来越复杂，数据涉密程度也越来越高。

       全面云化实施过程中，对于这些专业不同、使用软件不同、数据涉密程度不同的业务，通过分割为不同云平台来实施，各云平台内数据互通，不同云平台内用户不同、数据隔离。我们将日常办公场景的云平台称为OA云，部署在OA网段内；将机械设计和仿真场景的云平台称为设计云，部署在与互联网隔离的设计网段；将软件开发与验证场景的云平台称为电控云，部署在同样与互联网隔离的电控网段内，并与其他网段逻辑隔离，避免用户串用，数据管理混乱。

       根据不同的业务需求，设计人员在不同业务场景下，会在对应平台开展工作，而在各云平台间又存在数据交互的需求，如在设计云内模型，通过脱敏，相关截图需通过邮件发送或会议分享，以便在设计过程中与制造、售后等领域进行交流和信息同步。因此需要在云平台间，引入一套可以实现互相交互、同时又能审批脱敏的高效率数据交互平台。

2 研发数据交互平台的构建

       2.1 研发数据交互平台业务需求梳理

       结合以上业务背景，对研发数据交互平台业务需求进行梳理，要求导入统一的研发数据交互管理平台，所有云桌面下的数据都在此平台中交互，如图1所示。

       1）在提交审批流程时，申请人可自动将需要拷贝的数据带入流程中，流程审批通过后，申请人可从流程中直接下载；

       2）审批人员在审批过程中可直接在线预览需要审批的数据文件；

       3）因电控云数据为核心商密，保密级别最高，因此对数据进行加密，数据拷出脱离电控云环境后数据自动加密，数据拷入电控云内数据自动解密；

       4）OA云与电控云、设计云之间可以进行数据交互，设计云数据可以进入电控云环境，但电控云数据需要进入设计云环境通过OA云进行中转；

       5）该平台与邮件系统集成，有审批任务时有邮件提醒功能；

       6）具有定期统计各应用平台数据交互报表展示功能；

       7）支持移动端审批。
   
       为满足以上业务需求，该商用车公司完全自主开发一套适用于三朵云之间数据交互的平台，并设定目标：

       ●高效的文件上传下载服务；

       ●全流程自动化；

       ●对接OA流程；

       ●完善的申请审批下载记录；

       ●导入导出规则可维护；

       ●支持组织领导审批和项目负责人审批；

       ●支持统一身份认证。

       2.2 研发数据交互平台IT技术实现

       1）服务器部署设置思路

       服务器的部署，最开始的设计方案是各网都部署一台面向本网提供服务的平台服务器，各网用户只需要访问本网的服务器，而服务器之间需要开通权限传递文件和申请审批信息。由于OA流程仅在OA网可以访问，所有申请中的文件还需要传到OA网平台服务器上，开放链接给审批人从OA网访问。平台会比较复杂，并且占用较多的服务器资源和存储资源，而且也影响导入导出申请流程的效率。后来的设计方案是服务器部署在专门的服务器区，仅向各业务网络开通https特定端口，用户在各业务网内可以访问平台，进行文件上传、文件下载，而审批在OA流程中，仅在OA网可以访问。业务要求用户从各网访问体验一样，各网DNS服务器中为平台配置的是同一个全限定域名(Fully Qualified Domain Name)。

       2）审批流配置思路

       由于业务要求在OA流程中进行审批，并且要能查看申请的文件明细并下载检查。有两个方式实现，一种是文件以附件的方式放在流程中，不过OA流程有附件大小限制，不适合大文件附件；另有一种是将申请文件明细链接放在流程中，审批人点击链接，浏览器打开新的页面访问文件明细，可以查看下载，并且这个链接是做了权限限制的，仅审批人可以访问，当OA流程和平台都接入统一身份认证时，这个链接的访问是免登录的，这个也是平台采取的方式。

       3）数据交互业务规则配置思路

       平台需要识别用户所在业务网段，以配置相应的数据导入导出策略，并且可以针对用户所在业务网段，提供面向该业务网段的下载服务。平台根据web请求获取用户IP，根据平台维护的业务网段IP子网列表匹配用户所在的业务网段。平台需要按照业务单位网络IP分配现状预先配置好业务网络定义参数，并且当网络IP分配调整修改时要及时更新参数文件。
 
       平台数据导入导出策略是根据组织或项目个性化定制的，这里策略是指允许的源网和目标网，用户在业务网段中发起文件导入导出申请时，平台在申请页面呈现给用户可以看到的组织和项目是策略源网中包含用户所在业务网段的用户所属的组织和项目，而看到的导出目标是策略中用户所选组织或项目的源网是用户所在业务网段的所有目标网络。平台不仅在页面上给出限制，而且在后台收到用户提交信息后也会进行策略校验，以确保文件导入导出符合既定的业务规则。

       4）数据申请人组织架构人员配置思路

       为保障信息的准确性，平台每日从企业的活动目录(Active Directory)定时获取业务单位的组织人员信息，依次可以更新组织ID、组织名称、组织成员和组织审批人信息。我们知道单位的HR信息可能跟实际情况有些滞后，一些部门领导已经在履职，但是HR信息尚未更新，一些部门领导已经离任，但是HR信息也尚未更新。所以我们在平台上也给业务管理员授权，可以配置离职领导列表和履新领导列表，用户在提交文件导入导出申请时，选择组织看到的审批人不会出现离职领导列表的人员，而履新领导列表中的人员会在其中。
 
       如果业务单位也有项目的权威数据源，也可以配置相关项目信息的同步，没有的话，也可以在平台上维护项目信息，主要是项目ID、项目名称、项目成员和项目领导(审批人)，更为重要的是，要指定项目的文件导入导出策略。
 
       由于组织的策略允许的源网目标网覆盖较多，内部员工一般选组织提交申请，项目的策略允许的源网目标网限制严格，主要用于外部人员参与的文件流转。

       审批区内的每一对源网目标网对应的文件存储区域，都存放在不同的存储位置；下载区内的每一对源网目标网对应的文件存储区域，也都存放在不同的存储位置。而上传区没有做区分隔离，用户文件上传期间提交之前存放于同一个存储位置下的不同名为申请ID的子文件夹下。

       5）安全策略配置思路

       按照业务要求，数据进入电控云环境，需要进行加解密处理，因此在数据交互平台服务器安装了加密客户端软件，定制了加密策略，对特定文件存储区域进行落地加密，以符合业务安全策略。

       另外由于防病毒安全软件对新文件的扫描会占用较多的系统资源，影响文件写入落盘效率，再加上业务各网中也都安装了防病毒软件，桌面安全有保障，所以对平台的文件存储区域设置扫描白名单，减少防病毒对平台性能的负面影响。

       6）报表查询功能配置思路

       平台的最基本的业务功能页面主要是文件导入导出申请、审批查看，以及文件下载，此外每个用户还可以访问报表查询页面，查看自己的发起或审批的申请处理情况，并可以导出excel文件下载。为业务管理员还提供了组织和项目管理、业务网段定义管理、文件导入导出规则管理，另外还可以查询所有用户的申请处理情况和下载情况，考虑到选择的时间范围内数据量可能比较多，页面查询支持分页查看，并且支持按每月日期和每天时段的统计查询显示。
 
       7）平台门户功能配置思路

       为方便用户访问应用，平台还提供了应用门户功能，应用被定义为公共应用或私有应用，公共应用，所有登录到平台的用户均可以看到，私有应用仅被授权的用户可以看到，业务管理员可以进行应用的发布授权维护，用户登录到平台后，还可以拖拽应用图标，按自己的喜好保存应用的显示顺序。
   
       平台面向各网只提供了https特定端口的web服务，而平台本身是有多个功能应用组成，为减少应用之间的相互影响，其实在服务器上是运行着相互独立的web服务，通过nginx反向代理向外部提供看似统一的web路径视图。

       8）用户体验功能优化配置思路

       除了上述一些有用户界面的应用外，平台还包含一些底层服务应用，比如定时AD同步服务、平台健康状态监控服务、定时文件清理服务、流程审批执行服务、项目查询服务、人员查询服务、OA流程接口重传服务等，此外还有平台的两个重要服务：文件分片上传服务和文件下载服务，这两个服务对于大文件、多用户访问尤其重要，所以还配置了集群，集群数量是CPU核数，可以更高效率地利用服务器CPU多核的优势，将IO处理负载均衡地分配到这每颗CPU核上运行。

       高效的文件上传和文件下载是平台的重要优势。文件上传是由前端和后端共同实现的，前端引入了百度fex团队的webuploader组件，它对文件分片、上传，队列管理做了封装，可以节省很多前端开发工作量。平台的前端对webuploader的4个事件的进行了监听处理，分别是文件进入队列前、文件上传过程中、文件上传完成以及队列所有文件上传完成。文件在进入队列前触发服务器上创建文件；文件上传过程中，在队列中展示该文件上传进度百分比；文件上传完成会在已上传文件管理的列表中显示，可以对它进行操作；队列所有文件完成，才允许提交申请。文件上传后端是全自研开发的，其中上传的分片文件不落盘，而是以流(stream)的形态以流水线方式写入目标文件指定位置。这种方案与通常的上传文件分片合并方式相比，可以实现更少的IO，在降低服务器负载压力同时，减少了文件上传用户等待时间，因为它完全省略了分片合并这个大IO的耗时操作步骤，也不用担心等待超时问题而需要开发定时查询合并状态的前后端。

       在系统申请页面可以直观的展示用户文件上传队列的状态，并且可以对已上传到服务器上的文件，在未提交申请前可以选择删除不想放在申请中的文件。
 
       审批人员在该页面可以看到各个文件存储区中尚未处理的申请，依次点选文件存储区、日期目录列表、待审目录列表后，会看到申请详情，文件列表，可以点选一个或多个文件下载检查，可以在本页面里进行审批操作，也可以在OA流程中进行审批。区别在于OA流程中审批后，进入该审批界面就不会再看到那条申请，而在本页面里审批后，OA流程待办清单里仍会有申请存在，无论怎样审批通过或驳回都不再对该条申请的文件流转产生影响。当然也可以按业务单位的要求，将该页面的审批操作给隐藏或关闭掉，仅在OA流程中进行审批。实际上该平台也可以不依赖OA流程，在平台内审批也是一套完整的流程。

       用户申请通过后，平台将申请文件夹转移到对应的文件存储区，用户从申请的目标网络访问文件下载页面下载文件。文件存储区仅面向用户当前业务网段，其他文件存储区域不可见。文件并不是永久存放，而是按业务设定规则定时超期清理。
 
       在平台中，审批人下载和申请人下载页面中的下载文件操作调用的是后端的文件下载服务。文件并不是以ftp或者url方式能被用户浏览器直接访问到，而是服务器本地文件以流(stream)的形态以流水线方式返回用户浏览器触发下载保存操作，前端利用浏览器本身的能力，对前后端系统资源占用较少，后端服务由一个集群提供，可充分利用到服务器CPU多核的处理优势。前端文件下载并发数量受到浏览器的限制，微软edge和谷歌chrome的POST请求的并发数量是6，所以一次选中超过6个文件的下载并不能获得更高的并行性。

       虽然技术上可以放开对文件大小的限制，但是实际场景中，平台还是对每条申请中的单个文件大小和包含的所有文件的总大小设定了限制，研发限制是单文件最大64GB，单申请中所有文件大小不超过128GB。

       至于申请中包含的文件的数量，平台也是有限制。为了方便查询，数据库中，不仅将申请中每个文件在文件表中用单条记录存放，在申请表中也使用了一个JSON字段保存申请中包含的全部的文件的文件名和文件大小信息。在MySQL中JSON类型受BLOB列长度的限制，最大长度为65,535字节（64KB），按每个文件json字段信息占128字节估计的话，一条申请可以包含512个文件。从效率考虑，平台也不建议申请中包含一大批小文件，上传下载会很费劲。比较优化的建议是将大批量的小文件压缩打包传输，一条申请内包含的文件数量最好在50个以内。

       下载文件存放位置可以在浏览器设置中指定更改。用户需留意下载位置所在盘符的剩余空间，如果下载文件太大，建议将下载位置修改为剩余空间最大的盘符下，以免空间紧张导致各种问题出现。

       平台由多个应用服务组成，一些是面向用户交互的web服务，一些是接口服务和定时任务服务。为方便用户登录使用，避免用户访问平台的不同应用重复进行登录认证，平台实现了单点登录。

       平台中涉及到不少数据库操作，有很多数据库应用系统被抱怨运行速度慢主要是SQL语句只是完成了功能逻辑，但是没有考虑到执行效率，经过优化的查询带来的性能提升是巨大的。本平台在多记录增加和多条件多表查询上做了相关优化。
 
       虽然数据交互平台功能逻辑比较简单，但是在多个方面都做了用户体验和系统效率的考虑，在实际使用中达到了较好的效果，而且可以灵活配置，可以满足多种场景下的文件流转需求，可供参考借鉴。

3 研发数据交互平台创新点及实施效果

       该平台根据该商用车公司自身业务需求完全自主开发实现的数据交互解决方案，采用纯开源软件进行客制化开发，使系统更加贴合业务流程，满足特定功能的需求，节约开发成本。据统计导入一套类似商业化软件购买成本为30万（除硬件设备费用），每年运维费用6万，有效节约了系统开发成本。

       数据导入导出统一都采用web访问方式，方便业务单位在不同安全级别的业务子网之间按照业务设定地规则受控地传递文件，支持对接OA审批流程、统一身份认证，平台提供高效的web文件上传下载服务。平台自2024年1月1日正式上线至今，共实现近5000次数据交互需求，传输了超14000个文件，容量总计约2.4TB，且均是线上申请审批流转，避免了审批人员的差旅或异地办公影响，显著提升了业务部门数据交互的效率。

       该平台通过自主研发，企业完全拥有控制权和软件知识产权，所有数据都部署在自己服务器和基础设施上，不受第三方供应商的限制和潜在风险，有效地保护了数据的安全性，增强了企业品牌的科技实力形象，是企业一项重要的资产。