组建saas平台分析
2023-08-14 本文已影响0人
liguiyun
一,业务现状分析和诊断
1.1 服务繁多维护麻烦
目前每个地市级部署Center+App,Vehicle,报表,病历等各个服务 11个服务左右,不仅对服务器资源要求比较高,而且运维也是一个问题,出现问题又需要远程各个地市级进行排查
1.2 服务更新麻烦
如果有什么bug 和需求,而且影响业务bug,各个地区都要更新,导致更新工作量*N
1.3 系统对接麻烦
各地市如果需要对接数据 那个地区需要对接功能都要更新上线,导致频繁更新服务
二,系统技术解决方案
2.1 对内服务保持现有业务逻辑和相应的服务
坐席服务和基础服务 各地市业务场景有差异,保持现有的业务逻辑不变
2.2 分化系统以领域驱动设计
每个功能都是独立的个体,业务功能就如组件一样 可以是服务的一部分,也可以随时剥离服务
2.3 保持当前业务正常 逐步抽离
当前业务耦合太深,一下子全部剥离出来,不仅bug百出,而且拉长开发周期,先从小的开发慢慢剥离,比如短信功能,我们可以剥离出 短信服务功能到saas平台上去,现在各地市都存在开通或者不开通短信服务功能,短信服务又区分 发送短信和回访短信能功能模块,要么现在用配置项是否开通,现在我们把单独的短信功能开完完成之后 集成到各地市里面,这个短信功能需要那些是saas 平台来控制的,需要开启那些功能只需要点击开启按钮即刻
2.4现在能够独立剥离的业务有那些
1,短信业务
2,监护仪解析功能
3,心电图解析发送功能(需要和纳龙沟通心电服务是否支持)
4,app版本控制功能
5,车载解析功能
6,第三方车载接受工单系统
7,省质控系统
2.5 目前剥离系统所面临什么问题
1,服务交互耦合性太深,剥离系统堪比从新开发系统
2,当前的数据交互方式不准许,只能把独立的数据建立独立的数据库,需要交互的通过api进行交互
3,个性化需求太多,配置项太多,对公用的saas 平台,在大需求上我们可以订阅开通和不开通,在小功能上大家要保持一致性