项目实战05大客户定制相关技术

基于公版,对我司大客户进行定制版本的相关开发。

公版

整体架构

微服务spring cloud,抄来的图如下,大多数采用spring cloud的都是这个套路。

事务机制

二级事务处理,成功or回滚。

数据隔离,tenantid列

优点:所有租户使用同一套数据库,成本低。开发也容易,各查询添加一个条件字段即可。
缺点:隔离级别低,安全性差,数据备份和恢复最困难。
采用tenant租户id字段进行数据隔离,所有租户数据混合一起,会导致个别租户数据过大会导致所有租户查询速度有受到影响。数据批量更新时也需要格外注意,避免误操作其他tenant的数据。
其实mybatis有现成的租户隔离插件,MyBatis-Plus,由于历史原因,当时已经积重难返了,只能拿不完美的先用着了。

用户的建立

通过付费,后台建立超级管理员账户,然后密码交给租户(具体到人,比如老板或负责对接实施的管理人员)修改重置,重置后租户可以通过超级管理员,建立其他用户(普通工人,仓库管理员,采购人员等具体角色),设置用户名,初始密码等。建立后,用户可以通过用户名密码登录,查看到自己公司的相关订单,生产单等信息(和用户全新和角色有关)。
由于我们是按照端口付费的,所以对新建用户数量是有限制的。

催收续费

按月定时任务扫数据库,生成邮件通知市场负责人,市场负责人通知具体公司对接人进行续费。

AB环境升级

由于是微服务架构,所以升级时采用分组升级,一组看做A组,另一组看做B组。对A组做update时,nginx打到B组上,对B组升级时,nginx再打回到A组上。当然这是不涉及数据库变更的情况下。
如果牵涉数据库变更,由于数据库是共享的(同一个功能的AB组都使用了1个数据库),所以只能做短暂停机,一般情况数据库的变更都是提前导出部分数据做升级验证,确保所有数据都是可更新的,无遗漏的情况。
如果遇到意外(常在河边走,必然会湿鞋),可以采用提前的备份库顶上,回滚代码的升级。此次升级先暂停,后续再排查原因。不可能让用户一直等着研发调bug,除非小问题。

解耦和异步rabbitMq

场景:当库存变动时或库存配发到车间仓库时,会触发一系列的通知和生产单流转过程变量的更新操作。
这部分操作,从变更内容来讲,是必须要完成的(产品业务逻辑定义的)。但是从任务优先级和紧急度来看,既不优先也不紧急(意味着,即使未通知到,或未重新计算相关变量,也不会导致业务流转出错,只是降低了用户体验而已)。
如果一个接口中这种操作,占用了较多的处理时间,则需要做拆分。将任务push到消息队列中,然后交给另一个server从消息队列取得任务,然后更新表以及缓存等。

低频更新缓存redis

redis更多用来当做缓存使用,保存低频的变更信息,比如各租户的底层功能开关。访问频繁但变更频率低,可以看做多db层的加速。
这种数据更新后会自动触发redis的刷新,没有更新不会主动刷新。
用到才会查询=》入缓存,也不需要预热

看板优化

看板数据的慢查询部分从redis中加载,redis中定时刷新,等价于将慢查询或复杂计算和页面展示异步化。
缺点:降低实时性
优点:提高页面刷新速度,提升用户体验。

面临问题

大租户拖慢小租户:本质原因是共享了同一个数据表,表数据过大不可避免导致查询速度下降
解决方案:微服务可以将数据打散,降低单个数据库负载,但是单表则无法降低,可以采用主从+读写分离进行优化,从服务器可采用多个服务器,这样可降低查询负载。

更新矛盾:有些工厂坚持旧版好用,坚持用旧版,不接受新版
大多数坚持旧版客户,其实只是用不习惯新版而已。昨天能点的按钮今天找不到了。所以这更多是沟通问题,需要产品部门出升级文档,阐述这次迭代升级内容以及原有旧版的功能映射等关系,方便用户理解。
这方面也反向产品部门需求 的合理性,我们就开发了很多功能,客户升级后感觉反而难用了,就是产品部门没有把握好用户需求,凭感觉提需求。

功能开关:有些简单的功能开关会导致后台复杂度急剧提升,甚至需要填充额外数据信息。
解决方式:功能开关更多的负责控制展示逻辑(展示不展示,展示哪些,展示顺序),不负责对内部执行逻辑的过多切入。这种变更长期会导致系统数据混乱,不论是对客户还是服务提供商都是非常危险的。

定制版

特性

独立代码分支,独立机器,独立数据库,独立域名等

可解决哪些问题

个性需求,比如计价工资核算等严格来说不属于MES或ERP范畴,但是由于系统内部有报工信息,所以可以实现对计价工资的支持,一些复杂的工种区分,计件的阶梯计工资等。
公司的审计需求,部分公司是科创板上市公司,对公司经营数据有一定的安全性要求。像订单,采购单,生产单,生产计划等,对制造业来讲还是比较重要和私密的数据。如果放到公版,会有一定安全风险。毕竟对小公司而言,是没有专业的信息安全部门的,对普通软件研发而言,安全领域还是比较陌生的。
公司独立域名,独立部署可以实现挂到公司独立域名下,不使用saas公共域名,看起来可能更正规些。

引入新问题

共版的这个功能我们也要,反正你们有现成的,不用付钱吧
长期分离导致代码差异大,并且新功能需要补充新数据进行支撑。简单来说(产品)妥协一时爽,研发火葬场。

无法解决问题

定制化最大问题在于高成本,这个对客户存在,对于研发方依然存在,由于无法公用,导致客户感觉单价高,而对于研发而言,研发成本由于无法多家摊平,而本身研发人员费用相对较高,所以利润空间有限。

未来前景

saas整体前景还是比较悲观的,这方面可参考前辈姜孝鹏的经历,如果这种saas资深前辈都无法获得成功,那么其他saas前景可想而知。巨头扶持的比如钉钉目前尚且处于亏损状态,这可是顶级流量支持+大公司背书的saas。所以,难度可想而知。
个人感觉,国内的浅层客户一般不愿意付费(毕竟人手一份的windows都大多盗版)。深层的客户大多都需要定制,一旦定制saas本身的成本优势就没了,如果没有很大价格优势,人家当然更愿意自研。
至少就个人经验,续费率很惨,而新客户销售提成占比较高,获客成本太高。

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×