业务中台问题梳理和优化方案

业务中台问题梳理和优化方案

一、业务中台现有问题及对潜在的风险

1、业务中台现有问题

• 组织机构树存在设计缺陷
  • 基于邻接列表模型设计，需要配合函数实现关联查询，数据量大的时候，会出现数据查询丢失
  • 为了快速查询，设计时候采用空间换时间，每个节点都冗余了大量与所有父节点的关联关系，数据量较大，影响查询效率和数据的维护
• 逻辑冗余，代码中包含大量拱墅项目业务代码，需要精简
• 数据权限控制逻辑不够优化，采用的节点以下的思路进行关联控制，如果组织机构树优化了，这块也需要同步优化
• 学年学期开始时间全局控制方式不合理，不能满足各个业务学校的使用场景
• 升学毕业数据处理逻辑存在性能压力和数据丢失风险
• 服务数量偏多，目前标准版前后端加一起有 20 多个服务，为了提高运维实施效率以及降低资源要求，需要合并优化服务
• 通用功能偏弱，比如消息中心、运维中心、安全中心、数据服务、对象存储等，尚未形成较完善的基础服务，为各业务系统，提供共公能力支持

2、潜在的风险

• 组织机构树设计缺陷的问题，数据量少时无大碍，一旦数据量多起来的时候，后续的性能和数据维护会是比较头疼的事情
• 多余的代码，对往后新参与相关功能的研发，有较大的干扰
• 服务数量多，对部署实施和资源要求较高一些
• 学年学期不能单独按学校控制，对业务正常使用有一定的干扰
• 通用服务弱，子业务不能关注业务开发

二、相应问题的优化方案

1、优化设计为路径枚举模型，优化组织机构树维护和查询逻辑（仅后端参与）

2、去除无效代码，进行合理逻辑优化（仅后端参与）

3、编写统一的数据权限控制逻辑，调整原查询逻辑（仅后端参与）

4、合并服务，调整接口地址（前端、后端）

目前从拱墅项目中剥离出来用于业务中台的服务中，前后端加起来一共 19个服务，在部署的时候对资源的要求较高。

• 仅服务可启动最低资源就需要 5GB 以上的内存
• 能提供正常使用，一般也需要 10GB 以上的内容
• 作为 SaaS 服务或局端项目运行，势必需要更高的内存消耗才能满足运行，对实施条件也会有更高的要求

4.1、当前服务清单

4.1.1、统一身份认证服务

4.1.2、业务中台服务

4.1.2、开放平台服务

4.1.3、个人门户服务

4.1.5、综合评价-局校一体化平台

4.2、服务合并优化计划

5、开发基础功能（前端、后端）

5.1、学年学期可按学校单独设置和切换

新增学校学年学期

5.1、研发学校校历功能

• 可同时兼顾学校在统一的工作开始时间，工作结束时间，
• 读取统一的上课开始时间，上课结束时间

6、开发通用服务（前端、后端）

6.1、业务中台 • 消息中心服务

借着综合评价需要推送消息需求，完成通用的消息中心服务优化

• 短信推送
• 微信推送
• 钉钉推送
• 站内信推送

6.2、业务中台 • 对象存储服务

借着综合评价需要对存储资源进行管理的需求，完成通用的对象存储服务研发

• 1、提供对象存储服务临时账号密钥
• 2、提供租户空间管理（分配、预警、资源包）、资源管理
• 3、在项目中，当甲方不能提供存储服务时，用于整合MinIO本地服务后，对外提供对象存储能力
• 4、提供资源打包、下载等功能