技术调研工作开展与应用自查报告

技术调研工作开展与应用自查报告一、调研背景与目标1.1背景公司“云犀”事业部在2023年Q2启动“全域数据实时融合平台”项目，要求2024年Q1完成国产化替代并上线。技术委员会在2023-07-15决议：必须在正式编码前完成一轮“技术选型+合规性”双轨调研，输出可落地的《技术调研报告》与《应用自查报告》，否则项目预算冻结。1.2目标①给出3套以上可落地的国产化技术栈组合，并量化对比；②梳理现行系统与目标系统的差异，形成《差异矩阵》；③建立“技术-合规-成本”三维评分模型，得分≥80分方可进入POC；④输出《应用自查清单》及《整改预案》，确保2023-12-31前所有高危项清零。二、调研范围与边界2.1业务边界仅覆盖“实时数据采集→流式计算→OLAP存储→API网关”四层，不涉及前端可视化。2.2技术边界编程语言限定Java17、Rust1.70、Go1.20；数据库必须兼容信创目录；消息队列必须支持≥30万条/秒并发且端到端延迟≤50ms。2.3合规边界须同时满足《网络安全法》第21条、《数据安全法》第27条、《个人信息保护法》第38条，以及人民银行《金融业开源软件应用管理指南》（银发〔2021〕336号）。三、组织与职责3.1调研小组组长：架构部副总监李辰（拥有预算20%的一票否决权）；副组长：合规法务部高级顾问王婧；成员：研发、运维、QA、安全、财务共18人，采用RACI表固化责任。3.2决策机制每周三14:00召开“技术调研评审会”，使用Confluence+Jira管理任务；出现≥3条高风险合规缺陷时，自动触发“红色预警”，由组长直接上报CTO。四、调研方法流程4.1信息收集①桌面研究：检索信创目录、CNCF、Apache基金会、工信部2022年优秀开源项目名单；②问卷：向21家同业公司发放《技术选型问卷》，回收18份，有效16份；③深度访谈：邀请5位外部专家（含2位信创联盟评委）进行半结构化访谈，每次90分钟；④代码走查：对现有Flink1.13作业进行静态扫描，使用SpotBugs+SonarQube，共发现高危缺陷47个。4.2实验验证①环境：基于鲲鹏920+麒麟V10的裸金属集群，64C/256G/2TBNVMe×4；②工具：使用TPC-DS生成1TB数据，Kafka3.4作为数据源，分别运行Flink1.17、Spark3.4、PulsarFunctions2.11；③指标：吞吐、延迟、CPU利用率、FullGC次数、信创兼容性、许可证传染性。4.3评分模型三维评分=技术分×0.5+合规分×0.3+成本分×0.2；技术分细化为6项二级指标，每项满分100，权重平均；合规分采用“一票否决+累加扣分”，出现GPL-3.0直接0分；成本分=（商业授权费+运维人力×3年）/参考基线，低于基线20%得100分，高于基线20%得0分。五、技术选型结果5.1推荐方案A：Flink1.17+OceanBase4.1+Pulsar2.11技术分88，合规分95（MPL-2.0），成本分82，综合87.4；优点：生态成熟，Exactly-Once原生支持；缺点：OceanBase对ARM优化仍需手动开启4个参数。5.2备选方案B：Spark3.4+StarRocks3.0+Kafka3.4技术分82，合规分100（Apache-2.0），成本分90，综合89.0；优点：信创目录全覆盖，GPU向量化增强；缺点：微批延迟最低只能压到100ms，不满足业务≤50ms要求。5.3淘汰方案C：Flink1.17+ClickHouse23.3因ClickHouse使用Apache-2.0，但依赖的lz4-java含BSD-3-Clause与GPL-2.0混合代码，合规分直接判0，淘汰。六、差异矩阵与风险评估6.1差异矩阵（节选）|维度|现行系统|目标系统|差异等级|风险描述||消息队列|Kafka2.4|Pulsar2.11|高|客户端API不兼容，需重写Producer||状态存储|RocksDB5.17|RocksDB8.3|中|文件格式升级不可逆，需双跑验证||监控|Prometheus+Grafana|内置PulsarManager|低|指标名称变更，需统一Dashboard|6.2风险清单共识别风险32条，其中“极高”4条、“高”9条。示例：R-2023-08-002：OceanBase在ARM下编译需GCC11，而公司默认GCC9，升级编译链可能引入ABI不兼容。缓解措施：①使用官方提供的麒麟V10容器镜像；②在CI新增“ABI兼容性”门禁，基于`objdump-p`比对符号。七、合规自查实施细节7.1自查流程Step1资产清点：使用SPDX-SBOM工具生成软件物料清单，共导出组件1,247个；Step2许可证扫描：采用FOSSology4.2，规则库更新至2023-07-01，发现GPL相关组件3个；Step3漏洞扫描：使用Grype0.65，共命中CVE-2023-1234等高危漏洞7个；Step4整改闭环：在Jira建立“合规-”前缀工单，整改期限≤15天，超时自动升级至法务总监。7.2规章制度《开源软件管理细则》（云犀研字〔2023〕18号）明确规定：①任何引入开源组件须提前5个工作日提交《开源引入申请》，附SBOM与合规报告；②禁止引入GPL-2.0、GPL-3.0、AGPL-3.0组件；③违反者扣减当季绩效10%，并承担由此产生的法律费用。八、整改预案（可直接执行）8.1高危漏洞CVE-2023-1234（netty4.1.94）影响：远程拒绝服务；整改版本：升级至4.1.100.Final；验证脚本：```bash!/bin/bashjarxfmyapp.jarBOOT-INF/lib/netty-|grep-E"4\.1\.(9[4-9]|100)"&&echo"仍需升级"||echo"已修复"jarxfmyapp.jarBOOT-INF/lib/netty-|grep-E"4\.1\.(9[4-9]|100)"&&echo"仍需升级"||echo"已修复"```8.2GPL组件替换glibc2.31静态链接项被判定为GPL-2.0，需改用musl1.2.4；操作步骤：①在构建机安装musl-cross-make；②修改Maventoolchain.xml，新增`<type>musl</type>`；③在CI新增编译参数`-Dmaven.test.skip=false-Pnative-Dlibc=musl`；④产出静态二进制后，使用`ldd`确认无gpl-libc依赖。九、POC与基准测试9.1测试场景场景A：30万条/秒支付订单，字段256字节，Exactly-Once写入OceanBase；场景B：峰值80万条/秒，持续10分钟，验证PulsarBookie是否出现Backlog堆积。9.2基准结果场景A：平均延迟42ms，P9968ms，CPU58%，无LostMessage；场景B：Backlog最高1.2GB，持续3分钟后回落，未触发写入拒绝。9.3通过标准技术委员会设定：延迟P99≤80ms、CPU≤70%、零数据丢失；本次POC全部达标，准予进入正式开发。十、成本与采购策略10.1三年TCO对比（单位：万元）|项目|方案A|方案B||商业授权|0|180（StarRocks企业版）||人力运维|240|210||硬件折旧|90|90||合计|330|480|10.2采购策略①采用“框架协议+订单”模式，与麒麟、OceanBase、华为云签订三方框架，锁定单价三年不变；②设置“性能衰减”条款：若厂商版本升级导致性能下降>10%，可免费获得同规格License增量20%。十一、实施里程碑2023-08-15完成差异矩阵与风险评估2023-09-30完成所有高危合规漏洞整改2023-10-31完成POC并通过技术委员会评审2023-11-30完成生产环境灰度发布（5%流量）2023-12-31完成100%流量切换并下线旧系统2024-01-15出具《结项报告》与《知识固化手册》十二、知识固化与培训12.1固化交付物①《信创中间件调优手册》共148页，含OS参数、JVMGC、PulsarLedger配置模板；②Docker-Compose一键可运行Demo，已上传至GitLabTagv23.08.00；③录制3小时视频课程，已上传至云犀学院，强制要求研发、运维在2023-10-15前完成考试，通过率≥90%。12.2培训考核采用“线上理论+线下实操”双通道，理论≥85分且实操在120分钟内完成集群扩缩容方可通过；未通过者暂停生产权限。十三、经验教训13.1成功经验①提前引入法务，节省返工：在调研第2周即让法务介入，避免后期因GPL重新选型，节省约3人月；②采用“差异矩阵”而非“功能清单”方式，能直观量化风险，评审会一次性通过。13.2失败教训①初期未锁定CPU型号，导致在x86环境通过的基准，在ARM下延迟升高20%，被迫回滚；②对RocksDB文件格式升级评估不足，测试环境因磁盘不足未做全量回滚演练，结果生产环境回滚耗时4小时。十四、后续规划14.1技术演进2024年H2计划引入“ServerlessFlink”模式，与华为云FunctionGraph团队共建，目标把资源利用率再提升25%。14.2合规演进跟踪《信创开源软件管理办法（征求意见稿）》，若2024年正式发文，将同步更新《开源