CIS-客户信息系统标准版-概要设计V1.0
一、系统概述
1.1 系统背景
当前已完成CIS的MVP版本的演示和验收，正向着功能齐全、异常流完备的标准版迈进。从技术角度看，系统的稳定性、可扩展性、高性能、交付的灵活性是标准版的必备特性，需要从架构视角进行系统性设计。此外，MVP版本是由历史老系统复用而来，存在设计不符合当前要求等历史问题，需要对现有系统的设计和实现进行review，以解决CMS模块臃肿、工单模块和流程引擎的分布式事务等问题。详见 客户信息系统技术问题清单。
1.2 系统需求
1.2.1 后付费功能需求
| 主菜单 | 二级菜单 | 功能模块 | 功能描述 |
|---|---|---|---|
| 工单管理 | 全部工单 | 查看详情、流程图、终止 | 全部工单列表&工单详情&工单各环节详情 |
| 待办工单 | 处理工单 / 详情 | ||
| 业务受理 | 低压新装 | 申报 / 处理工单 | 申报、勘查派工、现场勘察、制定供电方案、供电方案审批、拟定供电合同、签订供电合同、计量配表、装拆表派工、装拆表打单、录入装拆信息、接火送电、归档 |
| 高压新装 | 申报 / 处理工单 | ||
| 修改付费模式 | |||
| 修改费率 | |||
| 客户档案修改 | 修改客户的基本信息（如联系方式、用电地址）等 | ||
| 过户 | 输入新的所有者详细信息。确认旧的所有者信息。提交所有权转移请求。 | ||
| 换表/付费模式变更 | |||
| 异常抄表 | 对于抄表数据复核异常的客户，需要重新给对应抄表员生成异常（现场勘察并补抄） | ||
| 销户 | 客户身份验证、销户原因收集、待办工单销户确认、完成销户操作 | ||
| 抄表管理 | 抄表数据复核 | 查看审核规则 | 设置各用电类别的正常抄见电量（包括需量抄见电量）波动幅度、波动率范围；正常抄见需量值的波动幅度和波动率范围。 |
| 抄表数据查看 | 查看抄表相关信息 | ||
| 执行审核 | 复核成功后进入电费计算状态 | ||
| 按抄表段Tab | 查询抄表段下的复核数据,展示各抄表段下复核正常，复核异常，异常（待处理、处理中、已处理）等数据统计结果 | ||
| 处理异常：点击后自动根据条件跳转到按客户Tab，展示对应抄表段下复核后的客户。 | |||
| 按客户Tab | 查询:本界面展示复核正常与异常的所有数据。 单个客户异常处理、批量客户异常处理 | ||
| 核算管理 | 电量电费复核 | ||
| 收费中心 | 收费记录查询 | 查询 | |
| 详情 | 按照客户对账单细节等进行展示 | ||
| 预付费 | |||
| 其他功能 | |||
| 收银台 | 查询 、 打印 | 查询、收费 、打印电费账单收据 | |
| 业扩费用收取 | 收取业扩费用（由业扩报装时直接跳转页面） | ||
| 欠款收取 | 收取欠款（偷电漏电）或业扩费用转欠款 | ||
| 计量资产管理 | 型号管理 | ||
| 到货入库 | |||
| 资产台账 | |||
| 拆除电表返回仓库 | |||
| 综合查询 | 合同查询 | ||
| 抄表情况查询 | 查询未抄表户，已抄表客户，电量波动率大于百分之30的客户等 | ||
| 客户档案查询 | 基本信息、用电信息、供用电合同信息、计量点和计量装置信息、抄表&计费信息、缴费参数信息 | ||
| 系统管理 | 合同模板管理 | ||
| 票据管理 | 发票模板管理 | ||
| 复核规则配置 | 新建/编辑 | ①抄表数据复核： ②电费复核 | |
| 供用电方案模版 |
1.2.2 预付费功能需求
1.2.3 性能需求
A. 页面查询
从条件式查询响应指标上，应符合具体数据场景，时间在适时的接受范围，例如简单页面查询响应用户通常接受在3s左右，如果后端接口或数据存储因历史数据过大响应慢，应重点考虑查询策略（分页）和存储优化（分库/分表/分区/缓存），同步查询缓慢的应考虑异步方案或前端友好提示
B. 大数据导出
新版本应做好用户导出场景需求采集，针对小数据及时导出、大数据异步服务化任务导出，实现方式上做区分；预判和杜绝不合理的导出，注意正确引导用户，不能因数据太大无法导出，也不能因导出拖慢其他业务功能使用，甚至前端假死无响应。
1.2.4 交付衍生的需求
考虑到不同的客户采购的模块不一样，例如有的客户内部管理流程完善需要工单模块，而有些客户的业务流程处于初级阶段暂时不需要工单模块； 此外，不同的客户定制化需求也不一样，对个别模块有对接存量系统的需求，或者部分替换模块的需求。因此，标准版CIS需要有足够的灵活性：
A. 灵活组装业务模块的能力（例如不采购工单模块、不采购预付费模块）
B. 单个模块的功能扩展能力，以便支持快速定制开发。例如收费模块支持快速对接新的支付渠道
C. 支持以外部系统作为主数据源，例如在客户已有系统之上补充工单/账单模块
D. 支持外部系统的部分功能内嵌到CIS， 例如客户使用CIS作为管理/存储用电用户数据，但仍保留原系统的部分功能
1.2.5 数据需求
对于一些简单的数据报表和看板，支持客户自助分析数据和数据可视化，以降低低价值的数据看板的开发成本。包括自助筛选数据、自助配置报表、自助配置看板、自助设计数据图表。
二、系统设计
2.1 架构设计
2.1.1 技术架构
| 分类 | 组件 | 技术选型及版本 | 备注 |
|---|---|---|---|
| 开发框架 | 前端框架 | 主应用：qiankun 2.3.2、vue2.6 vue2: Vue2.6.10、 ant-design-vue 1.7.8 vue3: Vue3.2、ant-design-vue 4.2.3 | 短期：预付费业务直接使用vue3技术栈，新老技术栈采用微前端的解决方案进行融合，对外呈现一致的页面和交互体验 长期：整个CIS只有vue3技术栈 |
| 后端框架 | SpringBoot 2.3.8 SpringCloud Hoxton.SR11 SpringCloud Alibaba 2.2.6 | ||
| 数据库操作组件 | MybatisPlus 3.4.2 | ||
| 数据库连接池 | Druid 1.2.8 | ||
| redis连接池 | jedis 3.3 | ||
| 流程管理 | Flowable 6.6.0 | ||
| 微服务 | 网关 | Spring Cloud Gateway 2.2.8 | |
| 开放API认证 | Spring-security-oauth2 2.3.8 | ||
| 注册中心/配置中心 | Nacos 1.4.2 | ||
| 远程调用 | OpenFeign 2.2.8 | ||
| 负载均衡 | Ribbon 2.2.8 | ||
| 中间件 | 消息队列 | RocketMQ 4.3.1 | 该版本有CVE-2023-33246漏洞，需升级到4.9.6版本 |
| 任务调度 | xxljob | ||
| 数据同步 | flink-cdc | ||
| 数据存储 | 缓存/分布式锁 | Redis 5.0.0 | 该版本有CVE-2022-24834漏洞，需禁用lua脚本：配置文件中设置 lua-time-limit 0 |
| 关系数据库 | Mysql 8.4.4 LTS Oracle 19C | ||
| 对象存储 | Minio go1.14.9 | 该版本有CVE-2023-28434漏洞，需升级为 RELEASE.2023-03-20T20-16-18Z版本 | |
| 数据仓库 | doris 3.0.0 | ||
| 数据可视化 | 自助分析 | metabase v0.51.2 | |
| 报表&看板 |
2.1.2 应用架构
####### 2.1.2.1 模块依赖关系
| 上游模块 | 同步依赖模块（不含公共服务） |
|---|---|
| 工单 | 视具体工单环节而定。某个环节涉及账单，则依赖账单相关模块 |
| APP后台 | 视APP支持的功能而定。就目前支持的抄表功能来说，依赖账单基础服务 |
| 后付费 | 算费中心、CRM |
| 预付费 | 算费中心、STS、CRM |
| 收费 | 视收费业务，依赖预付费和后付费模块 |
| 业扩报装 | CRM、STS、资产管理 |
####### 2.1.2.2 模块解耦原则
原则一：主数据服务、用户中心、消息中心等为公共服务，是上游所有服务的依赖模块，可同步调用。
原则二：在上述模块依赖关系中同步依赖的模块，可直接调用。其他模块之间禁止同步调用，可通过消息队列完成模块之间通讯
####### 2.1.2.3 CIS与用户中心的交互
详情见用户中心的技术方案。 点击跳转。
####### 2.1.2.4 工单模块与其他模块的交互
本方案将流程的表单与Flowable工作流引擎合并到一个模块，表单的提交与工作流的流转放在一个本地事务中，从而规避分布式事务的问题。但是有少量场景工单模块需要调用其他模块，存在一致性问题。
方案一：异步消息实现最终一致
方案二：幂等重试实现最终一致（考虑到此方案牺牲了一部分用户体验，优先考虑使用方案一）
2.2 高性能设计
2.2.1 大表存储与查询方案
A. 账单类大表
特点：随着时间的推移，数据量越来越大；同时业务上必须要查询时间跨度很久的数据。例如客户账单，存在欠费几个月的账单需要缴费的情况
存储方案：主表+历史表的存储策略，主表存储当月数据和待处理的数据， 历史表采用按月分区的策略进行存储，既照顾到业务查询场景，又可以应对大数据量的查询。
改进方案：主表+历史表的方案改成单表存储，新增一个专门用于分区的字段，插入时初始值为当前电费年月， 每次翻月时把未完结的数据修改分区字段为当前电费年月，让数据挪到最新的分区，这样只需在最新的分区即可查到当前电费年月的数据以及历史周期中未完结的数据。特别注意的是，按主键id查询时需要查最新分区和原分区求并集。
B. 流水类大表
特点：随着时间的推移，数据量越来越大；业务上仅查询近2~3个月的数据，历史数据查询的机率很低。
存储方案：单表存储，并采用按月分区的策略进行存储。
2.2.2 扩缩容方案
服务扩缩容：系统中接入网关、聚合层、服务层、用户中心等都采用无状态设计，可在性能不满足要求时增加部署实例，在资源空闲太多时减少部署实例数量；例如算费时效不满足要求时，可通过增加部署实例来加快算费效率。
数据层扩容：在系统初始部署前，需对数据存储量和查询性能做预估，然后日常运营中做好系统监控。当数据量和查询量达到扩容警戒线，由运维安排追加硬件资源来实现扩容，例如追加内存、硬盘、cpu资源。（可能需要停服操作，届时需要制定详细的行动计划和应急方案）
2.2.3 缓存原则
对于变更频次低的主数据、资产数据、系统参数/字典数据，在高频查询和使用的场景下要求引入缓存策略，以降低数据库的负载。具体实现方面，可以采用业内常用的热点数据缓存方案，即缓存数据设置过期时间、更新时删除缓存、查询不存在时加载缓存。
另外，redis是单节点部署，在代码实现中需兼容redis不可用的情况，即退化到本地内存缓存，最后退化到数据库查询。
2.3 扩展性设计
2.4.1 功能扩展性
考虑到客户需求的多样化，存在定制开发的需求。因此，在系统详细设计和编码时要求考虑功能可扩展性，即未来能以最低的开发成本实现新增功能。可预知的业务场景有：
- 复核规则的扩展。将对抄表数据、电量电费、账单等复核过程和复核要素进行抽象，保持主干流程的稳定，同时在具体的复核规则上保持扩展性，未来客户有定制化需求时能以最低的开发量实现新的复核规则。
- 支付方式的扩展。对常见的支付方式进行抽象（现金支付、银行卡支付等），支付路由时选择抽象的支付方式进行支付。在具体的支付方式上，再对支付渠道的支付能力进行抽象，当客户有新的支付方式或者新的支付渠道时，可以以插件的形式对接到已有系统中，实现低成本的功能扩展
2.4.2 在已有系统上补充我司的部分模块（主数据在外部系统）
2.4.3 代理外部系统的部分模块（主数据在我方系统）
2.4 高可用设计
2.4.1 机房级别高可用
服务层高可用：当前的架构设计中，业务模块、中间件、基础服务等均采用多实例部署，结合Springcloud的容灾方案，可以实现单机容灾，即单个实例不可用时不影响系统的可用性。
数据层高可用：数据库采用主从模式、Rocketmq采用一主多从的部署架构，均具备高可用能力。 redis目前是单实例部署，由业务模块在代码中进行容灾，即redis不可用时退化到本地内存缓存，最后退化到数据库查询
2.4.2 异地高可用
需求中，希望CIS支持私有云部署、 公有云部署、混合部署（异地容灾）， 其中，CIS目前支持多租户，天然支持公有云部署。后面重点讲以异地容灾为目的的私有云+公有云的混合部署模式。
异地灾备的前置条件：
1.如果两边机房的物理距离较远，网络延时较大，容易出现两边集群的数据不一致问题，即会出现少量数据丢失（例如在本地机房购电成功了，切换后异地机房没有这条记录）
2.如果异地机房或者公有云在其他国家，还涉及数据出海的问题。
3.异地灾备只针对少量的核心业务做灾备，这些核心业务所依赖的内部其他系统也得具备灾备能力（售电业务暂未发现有依赖）。
4.当本地机房恢复正常后，需要恢复访问，在此之前需要对数据进行合并，存在人力成本投入
集群切换：
1.当本地机房因为网络或者其他原因导致不可用时，开启集群切换流程，关闭数据同步。
2.切换web页面访问域名到备用域名或者外部域名，如果有app还需要在app中切换域名
3.外部接口域名的ip地址解析映射到异地机房的ip
4.替换异地机房的只读Licence为正式生成环境的Licence，正常开展售电业务
集群回切：
1.暂停异地机房的系统的访问，保持数据稳定；将Licence切回到只读Licence。
2.人工将异地机房的增量数据同步到本地机房的业务数据库中，使得两边数据库保持一致
3.恢复本地机房到异地机房的数据同步
4.恢复外部接口域名ip映射到本地机房、恢复外部访问域名到原域名
5.在本地机房正常展开业务
**建议：**异地灾备的方案，实施成本较高，一般不建议使用。
三、模块概要设计
3.1 工单模块的灵活性和可配置能力盘点
| 能力项 | 描述 | 现状 | 待办 |
|---|---|---|---|
| 环节关联角色 | 通过配置不同环节的操作角色实现电力公司各个流程由不同环节员工处理的实际业务场景 | 已支持 | |
| 子流程 | 支持创建子流程，并进行流程的对接 | 已大部分支持。但是子流程结束后，无法再从主流程回退到子流程中。 | 是否要支持回退到子流程 |
| 并行流程 | 并行网关的实际应用——保证合同子流程和工程子流程互不干扰 | 并行流程汇聚时还有bug | 解决bug调通并行流程。但是并行流程的场景比较少，该事项优先级不高 |
| 条件分支 | 允许通过表单变量判断进行分支控制 | 已支持 | |
| 目的地跳转 | 控制审核不通过的情况下，工单跳转的目的地 | 已支持 | |
| 环节复用 | 环节在工作流平台中可以实现直接复用，不需要重复开发 | 有限支持。同一个环节在不同流程可直接复用，但是同一流程中不能重复出现多次 | 按需求开发通用环节（例如通用的审核环节），做到同一流程中多次复用 |
| 角色任务池 | 该角色操作员均可看到该任务，由其中一人认领后继续处理 | 已支持 | |
| 指定传递的用户 | 上一环节的处理人选择一个目标用户，进行指定的传递 | 已支持 | |
| 环节客制化开发 | 调整各个环节内需要展示的信息和待填入的信息 | 视需求而定，需少量开发 | 长期看需要提高表单的配置化能力，包括表单中部分区域可配置、所有区域可配置 |
| 高级功能：按组织机构控制权限 | 可以按组织机构中的上级、岗位等控制审批权限 | 暂不支持。需用户中心升级权限模型 | |
| 高级功能：自定义配置环节的表单 | 通过拖拉拽的形式配置环节的表单页，并在流程中使用 | 暂不支持。需引入Flowable的表单设计器 |
3.2 数据仓库概要设计
3.3 自助分析及数据可视化
**Metabase体验地址：**http://192.168.2.240:3000 , 账号：test@witlink.com ， 密码：witlink123
Metabase效果展示见以下图片：
3.4 Licence管理
Licence管理措施：
- 系统部署完成后，由实施人员提供系统所在网络，例如192.168.0.0 ， 以及访问系统的入口域名，例如cis.witlink.com， 以及系统安装路径， 例如/usr/local/cis
- 根据项目编号-所属网络-域名-安装路径，由我方线下生成机器码。 （域名可以先不考虑加入进去）
- 根据机器码、授权参数（Licence有效期、注册用户数等），生成Licence，最后由实施人员将Licence配置到nacos注册中心
- 在系统提供服务时，由Licence组件自己根据上下文环境生成机器码，然后解析Licence，并判断有效期以及返回授权参数。各业务模块根据授权参数执行权限逻辑
3.5 数据集成方案
四、非功能性测试要点
3.1 灵活组装测试
####### 3.1.1 测试目的
测试CIS各模块是否按要求解耦，当客户需求来临时无需改动代码，确保真正具备灵活交付的能力
####### 3.1.2 测试步骤及预期效果
| 测试步骤 | 测试动作 | 预期效果 |
|---|---|---|
| 初始化 | 1. 完整部署CIS各模块，含用户中心 2. 除网关、用户中心、主数据服务，禁用其他服务 | 可正常登录，可正常查看/修改客户档案信息 |
| 报装 | 启用资产服务、工单服务 | 可正常完成报装流程 |
| 抄表 | 禁用工单服务、启用账单相关服务 | 可正常完成抄表、复核、算费、发行账单等 |
| 复核-工单 | 启用工单服务 | 可正常完成复核中工单的发起、传递等操作 |
| 收费 | 启用收费相关服务 | 可正常完成收费相关功能 |
| 预付费 | 启用预付费相关服务 | 可正常完成预付费充值等相关功能 |
| 消息订阅 | 启用消息服务 | 可正常接收短信、邮件等通知消息 |
3.2 仿真压测
####### 3.2.1 测试目的
模拟真实的使用场景和时间跨度（3年以上），在系统产生足够多的数据，观察系统在3年以上的使用时间后是否还能稳定运行
####### 3.2.2 测试步骤及预期效果
| 测试步骤 | 测试动作 | 预期效果 |
|---|---|---|
| 初始化 | 通过工具构造500w用电用户 | 可正常查看/修改客户档案，页面和接口响应在3秒内 |
| 报装 | 通过工具模拟给所有用户报装一个电表，随机选择合同的关键参数，例如抄表周期等 | 在系统界面上完成一次正常的报装业务，过程中页面和接口响应在3秒内 |
| 抄表&复核&发行账单&收费 | 1. 翻月 2. 对500w个电表模拟抄表 3. 模拟批量复核、发行账单等动作 4. 模拟收费 5. 连续完成24个月份 | 各动作执行流畅，页面和接口响应在3秒内；特别的，随着时间的推移，系统没有明显感知到的性能下滑；每次翻月抄表后在8小时内完成抄表数据落库和自动复核（4核8G数据库） |
| 消息订阅 | 每个用户都开启账单发行的订阅，然后完成24个月的账单发行 | 可正常接收消息通知，从发行账单到接收到消息通知的延时平稳无明显延迟 |
| 预付费 | 模拟500w用户每月都进行预付费充值 | 充值功能正常，响应在3秒内；正常生成token |
五、交付方案--容器化部署
CIS系统涉及的模块较多，为了方便成品管理和交付，采用容器化方式进行部署。
- 搭建成品仓库。经过测试和验收的代码，通过打包工具打包成jar包和静态资源包，携带版本号存放到成品仓库
- 除数据层，其他各模块最终都采用容器部署
- dockerfile中通过环境变量暴露内存、线程数等资源控制变量，以便运维根据客户实际情况进行调整
- 通过docker-compose构建docker镜像，以及组织和管理docker容器
- 如果客户机房有k8s的基础环境，可基于docker-compose的资源文件编写k8s的yaml文件
- 可通过在docker-compose的yaml文件中增删模块来实现CIS各模块的灵活组装
六、待办
6.1 适配/代理三方系统的前置条件：国际电力信息化标准协议、参考行业惯例做数据模型设计等等
参考文档
[附件]
StarRocks Vs doris : https://blog.csdn.net/weixin_44325637/article/details/135537425
- Doris适用于需要高性能数据处理和分析的场景，如实时数据分析、数据仓库等。它能够快速响应查询请求，提供准确的数据分析结果，帮助用户做出更明智的决策。StarRocks则更适合于需要处理大规模数据和分析复杂数据的场景，如 https://cloud.baidu.com/product/sugar.html大数据分析、 数据挖掘等。它能够处理海量数据并提供高效的查询和分析能力，帮助用户发现数据中的价值。
- starrocks在大规模数据处理方面更有优势， doris在多表查询方面更有优势。此外，doris是Apache license，starRocks是 Elastic License。这就意味着starRocks是部分开源，说是为了防止云厂商的白嫖，但从这一路操作看，未来大概率会出商业版
- doris使用门槛相比starRocks较低，上手快。
- 目前我们的应用场景，数据规模在几亿级别，不算特别大，doris足够应对这个量级的数据，综合考虑建议采用doris