系统环境与硬件需求
本页面详细记录了中-集团智能化合并报表系统的环境与硬件需求设计方案，包括系统部署架构设计、现有硬件配置分析、预期性能目标以及硬件资源申请等内容。
系统基于某IT财务平台平台构建，采用独立部署方案以确保合并报表系统的稳定性和性能。
系统部署架构设计
某IT财务平台标准逻辑架构设计
某IT财务平台标准逻辑架构设计：财务平台分为财务平台及财务平台应用，其中：财务平台提供财务平台系统标准paas服务，财务平台应用是基于财务平台搭建的saas应用
某IT财务平台合并报表项目逻辑架构设计
根据项目现场情况及合并报表项目应用需求，规划某IT财务平台在IaaS、paas层、saas层架构：基于集团云平台提供的硬件、容器平台搭建财务平台平台及财务平台应用，其中：
1.财务平台应用：
中-合并报表项目建议使用财务平台平台的系统基础服务进行权限、组织、合并架构管理
合并应用服务用于报表编制、对账平台、台账平台、权益抵消等前端用户交互应用
合并报表后台事务服务用于智能合并、自动编报、股比计算、外币折算等后端高性能任务
2.财务平台：
中-合并报表项目建议使用的财务平台提供了标准的应用开发服务、流程服务及集成服务
3.Paas层：
中-合并报表项目建议使用中-集团IT部门提供的容器平台、中间件、监控平台、网关，在此基础上搭建财务平台
4.Iaas层：
中-合并报表项目建议使用中-集团IT部门提供基础的硬件服务
某IT财务平台标准逻辑架构设计
基于集团云平台搭建中-合并报表系统，具体架构方案如下：
DMZ区
通过中-集团提供的中-随行零信任服务，保障用户登录及系统使用安全
PaaS层-中-容器平台：
在中-集团提供IaaS层资源(物理机或虚拟机、网络、存储）基础上，安装部署“某IT基础平台”服务来构建
PaaS层计算区：
网关转发：用户登录零信任后点击“内部应用”应用，通过中-集团提供的网关服务，自动跳转到财务平台的web实例
财务平台应用容器微服务拆分：根据业务拆分合并报表容器微服务，拆分为合并报表应用、合并后台事务、集成、工作流、平台基础服务等应用，提升处理合并报表效率，通过容器技术保障各业务独立运行
容器持续化存储说明：使用中-集团IT部门NFS共享存储，挂载到财务平台每个容器实例中，保障财务平台数据持续化存储
共享存储使用场景：轻分析存储、图片附件服务器存储、静态资源、应用仓库(appstore)存储。
4、高可用说明
部署架构中的每个服务部件都采用分布式集群架构，财务平台应用的状态通过独立的集群（Redis）存储，财务平台应用实现无状态服务，满足应用层的弹性伸缩和可用性需求。
中-合并报表部署方案独立性
财务平台运用了容器及数据库分库技术，解决中-EAS系统瓶颈，按照中-集团项目现状，划分微服务，保障每个服务单独运行，互不影响
1.EAS系统一体化部署面临瓶颈：
| 系统 | 面临问题 |
|---|---|
| 系统 | 面临问题 |
| EAS系统 | 服务互干扰，部署需要将所有功能都停止 |
| EAS系统 | 资源利用低 |
| EAS系统 | 迁移扩展难，需要绑定IP地址，整体迁移难度大 |
2.财务平台系统容器化部署优势：
| 系统 | 优势 |
|---|---|
| 系统 | 优势 |
| 财务平台系统 | 移植简单，可以不停机切换后台数组机，减少硬件资源异常对应用影响 |
| 财务平台系统 | 业务隔离，可按容器微服务划分不同业务各业务间互不影响 |
| 财务平台系统 | 弹性伸缩，根据实际情况，弹性扩容实例资源 |
3.中-项目容器及数据库部署规划
| 分类 | 功能模块 | 微服务 |
|---|---|---|
| 容器微服务 | 附件 | fileserver 文件服务器 |
| 容器微服务 | 基础服务 | mservice 基础服务 |
| 容器微服务 | 基础服务 | qing 轻应用 |
| 容器微服务 | 基础服务 | web 对外入口 |
| 容器微服务 | 基础服务 | mservice-iscb 集成 |
| 容器微服务 | 合并报表项目 | mservice-bcm 合并报表应用 |
| 容器微服务 | 合并报表项目 | mservice-bcmcal 合并报表应用后台事务 |
| 容器微服务 | 合并报表项目 | mservice-epm 预算 |
| 容器微服务 | 中-司库项目 | mservice-tmc 资金&司库 |
| 容器微服务 | 中-司库项目 | mservice-tda 决策分析应用 |
| 容器微服务 | 中-司库项目 | mservice-tdacal 决策分析后台事务 |
| 容器微服务 | 综合共享费控项目 | mservice-fi 财务 |
| 容器微服务 | 共享升级项目 | mservice-ssc 共享升级 |
| 数据库 | 基础资料数据库 | mysql-基础库 |
| 数据库 | 集成数据库 | mysql-集成库 |
| 数据库 | 总账、费控、资金财务数据库 | mysql-财务库 |
| 数据库 | 合并报表数据库 | mysql-企业绩效库（新增） |
| 数据库 | 工作流数据库 | mysql-流程库 |
| 数据库 | 系统服务数据库 | mysql-系统库 |
财务平台系统用户使用情况及现有硬件配置
现有港口合并报表项目400家组织，150个用户，用户使用情况及硬件资源配置如下：
1.用户使用情况：
| 系统 | 面临问题 |
|---|---|
| 系统 | 面临问题 |
| mservice-bcm 合并报表应用 及mservice-bcmcal 合并报表应用后台事务 | 目前智能合并全级次（400家）计算性能：不包括权益：15分钟重新对账+重新权益抵销：20分钟远远无法达到集团合并项目上线标准 |
| mysql-财务库 | 在2022年出现2次主从切换，平时数据库压力在70% |
| Redis-会话 | redis会话服务采取淘汰制，在高峰期用户会话在20分钟左右就会被踢出 |
| 日志中间件 | 现有磁盘空间500G，只能支持1天info级别日志输出，对于偶发性问题定位困难 |
| 多维库 | 2023年Q1港口上线200家新公司，共有400家公司参与计算，原有8c的CPU不足出现计算报错，后紧急协调加到32c/32g |
| 静态资源 | 目前附件+静态资源存储已占共享磁盘空间约60% |
2.现有硬件配置：
| 所属模块 | 推荐配置 | 推荐配置 | 推荐配置 | 推荐配置 | 推荐配置 |
|---|---|---|---|---|---|
| 所属模块 | 数量 | cpu(核) | 内存(G) | 磁盘空间(G) | 硬盘类型 |
| mservice 基础服务 | 6 | 4c | 9g | \ | \ |
| mservice-bcm 合并报表应用 | 3 | 4c | 13g | \ | \ |
| mservice-bcmcal 合并报表应用后台事务 | 3 | 4c | 13g | \ | \ |
| mservice-iscb 集成 | 3 | 4c | 9g | \ | \ |
| web 对外入口 | 6 | 4c | 9g | \ | \ |
| mysql-财务库 | 1 | 64c | 128g | \ | \ |
| mysql-集成库 | 1 | 8c | 32g | \ | \ |
| Redis-algo | 1 | 4c | 16g | \ | \ |
| Redis-缓存 | 1 | 4c | 16g | \ | \ |
| Redis-会话 | 11 | 4c4c | 16g16g | \500g | \HDD |
| Elasticsearch | 11 | 4c4c | 16g16g | \500g | \HDD |
| Logstash | 11 | 4c4c | 16g16g | \500g | \HDD |
| Kafka | 2 | 128 | 1TB | 1TB | SSD |
| 多维数据库MDD | 2 | 32c | 32g | 500g | SSD |
| 应用仓库，静态资源，附件（包括图片），轻分析存储 | \ | \ | \ | 500g | HDD |
预期性能
预期数据量及预计性能目标值
预计数据量：参考EAS报表年结数据，集团合并报表项目在高峰期预计有5000家组织，3000用户数同时编报
预期性能：集团合并报表项目以行业一流水平为性能预期，其核心功能预期性能如下：
| 功能分类 | 核心功能 | 预估组织 | 数据量（以2022年12期为例） | 预期性能 |
|---|---|---|---|---|
| 报表编制 | 报表打开 | 基于0009,0001HB预估 | 0009-1-11:14125单元格0001HB-1-10：98472单元格 | 报表单元格小于2000个，3秒内；报表单元格小于20000个，10秒内；报表单元格小于200000个，2分钟内； |
| 报表编制 | 报表计算 | 基于0009,0001HB预估 | 0009-003:6182单元格0001HB-HB101：989单元格 | 集团合并报表项目通过集成，单体无计算环节；合并层通过智能合并计算数据； |
| 报表编制 | 报表保存 | 基于0009,0001HB预估 | 0009-1-11:14125单元格0001HB-1-10：98472单元格 | 报表单元格小于2000个，3秒内；报表单元格小于20000个，10秒内；报表单元格小于200000个，2分钟内； |
| 报表编制 | 勾稽校验 | 基于0009,0001HB预估 | 0009-101:1418/60s0001HB-HB101:1433/60s | 计算勾稽数小于10个，3秒内；计算勾稽数小于100个，30秒内；计算勾稽数小于1000个，1分钟内； |
| 报表编制 | 批量导出（50张报表一个excel） | 基于0009,0001HB预估 | 数据量小于20000，30s；数据量小于200000，3分钟； | |
| 数据集成 | 定时采集 | 数据湖1000组织，EAS3000组织预估 | 平均1个组织科目余额表5000行数据，共2千万行 | 集成数据小于1千万，4小时内；集成数据小于2千万，6小时内； |
| 数据集成 | 单一组织即时采集至报表 | 基于某证券、0009预估 | 1个组织科目余额表10000行数据 | 集成数据小于1000，2分钟内；集成数据小于10000，5分钟内 |
| 外币折算 | 外币折算（单一报表） | 基于0004预估 | 财务平台是全量折算，无单一报表折算； | |
| 外币折算 | 全套报表（142张表） | 基于0004预估 | 9687单元格 | 单家组织单期数据量2w，5秒内； |
| 对账平台 | 对账数据采集 | 基于0009预估 | 862行 | 集成后会更新数据，不需要采集，若重新同步报表数据后需要更新对账数据，3秒内可以更新完成； |
| 对账平台 | 对账勾稽 | 基于0009预估 | 3秒内 | |
| 对账平台 | 抵销分录生成 | 基于0003HB预估 | 2578行分录 | 数据量小于1000行，1分钟内；数据量小于10000行，5分钟内； |
| 台账平台 | 台账数据导入 | 基于0009利息资本化 | 1000行初始化数据 | 数据量小于200行，5秒内；数据量小于1000行，60秒内； |
| 台账平台 | 抵销分录生成 | 基于0009HB预估 | 1000行分录 | 数据量小于1000行，1分钟内；数据量小于10000行，5分钟内； |
| 权益抵销 | 架构变更和股比关系报告生成 | 基于0003HB预估 | 200分录 | 数据量小于1000行，1分钟内；数据量小于于10000行，5分钟内； |
| 权益抵销 | 权益抵销分录生成 | 基于0003HB预估 | 3057分录 | 数据量小于1000行，1分钟内；数据量小于10000行，5分钟内； |
| 权益抵销 | 手工抵销分录编制保存或者审核 | 基于0003HB预估 | 100行分录 | 分录小于100行，3秒内；分录小于1000行，15秒内； |
| 智能合并 | 智能合并 | 基于0003HB预估 | 20000行数据 | 对账、权益抵销计算：数据量小于20000行，2分钟内；数据量小于200000行，10分钟内只重算手工分录：数据量小于20000行，1分钟内；数据量小于200000行，5分钟内 |
详见附件【财务平台合并报表项目性能预期.xlsx】
系统性能对比分析
对比数据量：维度成员1w，单张报表数据量2000个单元格，单家组织1000行抵销分录，200家组织合并，单家组织单期数据量2w，单期总数据量200W。
| 功能 | 操作 | 某IT | HFM | SAP |
|---|---|---|---|---|
| 维度 | 成员搜索 | 5s | 8s | 7s |
| 维度 | 导出 | 10s | 10s | 11s |
| 报表编制 | 打开报表 | 3s | 5s | 5s |
| 报表编制 | 保存报表 | 3s | 3s | 3s |
| 报表编制 | 批量导出（50张报表一个excel） | 30s | 需要单独一张张报表导出 | 32s |
| 对账管理 | 对账（1 .2万条记录） | 25s | 流程控制中执行，没有单独计算 | 单独搭建方案，抽取数据后对账处理，无单独计算 |
| 权益抵销 | 权益抵销生成 | 60s | 执行规则 | 60s |
| 调整抵销分录 | 打开分录 | 3s | 5s | 4s |
| 调整抵销分录 | 审核分录 | 3s | 3s | 3s |
| 调整抵销分录 | 打回分录 | 3s | 3s | 3s |
| 智能合并 | 报表计算（简单规则） | 3s | 3s | 3s |
| 智能合并 | 报表折算 | 5s | 5s | 5s |
| 智能合并 | 智能合并(对账、权益抵销) | 2min | 6min | 3.5min |
性能目标值硬件资源申请
以财务平台合并报表5000家组织，3000个用户估算，现有财务平台环境的测试及生产环境硬件资源远远不符合要求，需要对容器、缓存、中间件、多维库等资源进行优化升级，具体优化建议如下，其中标黄色的为需要申请升级的硬件资源：
需要申请升级的资源清单如下：
| 安装内容 | 建议说明 | 推荐配置 | 推荐配置 | 推荐配置 | 推荐配置 | 推荐配置 |
|---|---|---|---|---|---|---|
| 安装内容 | 建议说明 | 数量 | cpu(核) | 内存(G) | 磁盘空间(G) | 硬盘类型 |
| mservice-bcm 合并报表应用 | 以一个用户使用10M，每个实例10G最多支持100用户，以5000用户数估算，需要增加合并报表应用实例至50个 | 50 | 6c | 13g | \ | \ |
| mservice-bcmcal 合并报表应用后台事务 | 以5000家组织估算，每个实例支持300个组织，需要增加合并报表应用后台事务实例至10个 | 10 | 8c | 13g | \ | \ |
| mservice-iscb 集成 | 以5000家组织集成数据量估算，需要增加集成实例至10个 | 10 | 6c | 13g | \ | \ |
| web 对外入口 | 以增加5000用户数估算，需要增加web入口实例至10个 | 10 | 4c | 9g | \ | \ |
| mysql-集成库 | 以5000家组织集成数据量估算，需要加大内存至128g | 1 | 64c | 128g | \ | \ |
| mysql-企业绩效库（新增） | 为保障合并报表性能，与其他功能互不影响使用，合并报表数据库独立拆分 | 1 | 64c | 128g | ||
| Redis-algo | 以5000用户数估算，合并报表为提升效率将大量使用缓存，需要加大内存至64g | 1 | 8c | 64g | \ | \ |
| Redis-缓存 | 合并报表为提升效率将大量使用缓存，需要加大内存至64g | 1 | 8c | 64g | \ | \ |
| Redis-会话 | 以5000用户数估算，会产生许多会话，需要加大内存至64g | 1 | 8c | 64g | \ | \ |
| Elasticsearch | 以5000家组织估算，合并报表日志数据量将成倍提升，需增加磁盘空间至2T | 1 | 64000 | 16g | 2TB | HDD |
| Logstash | 以5000家组织估算，合并报表日志数据量将成倍提升，需增加磁盘空间至2T | 1 | 64000 | 16g | 2TB | HDD |
| Kafka | 以5000家组织估算，合并报表日志数据量将成倍提升，需增加磁盘空间至2T | 1 | 64000 | 16g | 2TB | HDD |
| 多维数据库MDD | 合并报表核心计算都在多维数据库中进行，需要CPU128核，内存1TB支持短时间暂预估：5000个组织,每期1亿的明细数据，占用磁盘10GB左右，每年共13期加4个季报、1个年报，共约180GB左右的磁盘占用空间的数据，此外，多维库会定期备份，磁盘空间需要预备1T | 2 | 128 | 1TB | 1TB | SSD |
| 应用仓库，静态资源，附件（包括图片），轻分析存储 | 预留合并报表附件空间，磁盘空间需要预备1T，且需考虑后续扩展性 | \ | \ | \ | 1TB | HDD |
详见附件【财务平台合并报表项目部署配置方案.xlsx】