随着业务需求越来越多,公司整体的技术框架变的越来越复杂,对于系统的整体架构我也有了更深入一层的思考。这里分享自己的一些观点,希望能与看到这篇文字的人共同探讨。
背景
目前公司的状况是,核心系统仍旧是ERP系统,关于ERP是什么具体可以看这里。围绕ERP系统这条主线,在公司内部并行了部分内部管理系统,包括OA,CRM,HR,BI等系统;对外部包括有Web应用(网站管理,微信管理),线上销售,门店导购等系统。而这里想说的是其中关于web应用系统这一方面。
业务系统发展
初期状况
最早上线的系统主要是公司官网,线上社区和网上商城系统,也就是今天网站管理系统的基础。这部分分为三块,包含CMS,BBS和SHOP系统,那时的研发能力还没有那么强,因此都是用一些网上的开源系统二次开发搭建。
目前状况
随着网络的变化,后续上线的就是目前的移动端,包括微信公众平台,企业号平台等管理系统。也因为研发能力的进一步增强,开始采用自主研发的方式,开发符合自己定制化需求的平台。
接下来对于可能要上线的线上销售系统,无论是采用第三方平台,还是自主研发,对数据及部分业务的对接整合还是需要在内部进行。
到了目前这个时期,我想应该是算作中期,要做的可能也不仅仅是野蛮的拓展系统,而是要逐渐的整合系统,做到系统精炼,但用户体验上升。这也是随着整体的风向自然的发展。
系统发展遇到的问题
其实写了这么多,想说的重点也都是在这一块,那就是技术方面的房展。初期用开源系统做二次开发的时期,自然不会考虑到这些问题。那时候随便找一个虚拟主机,随便的下载了源码修修补补实现了功能,然后就上线了。
那个时期没有那么多的讲究,真正讲究的也都成了大神,公司那时用了较为流行的帝国CMS,Discuz,ECShop,甚至商派的人来公司谈合作,都还以正在用ECShop为傲,岂知人家的业务重点早已经不在这一块了。
而现在来看,考虑的方面其实就要多很多了。目前新的技术日新月异,新的需求也不断出现,原因都在于网民的增加,移动端的普及,甚至这里面微信也为HTML5的盛行出了一份不小的力。而在我们这里,随着业务的增加,也逐渐出现了一些问题。
高并发问题
随着需求的增多,上线的微信系统会员已近40万,但实际的访问量其实并不算高,只有在发布优惠抢购活动时,瞬间出现的高并发才让人措手不及。
有抢购以及秒杀的活动场景,常会出现卡死的情形,缓存没有做,分布式没有做,服务器IO也并不是那么给力,瓶颈基本都是来自服务端并发数,当然本地数据库也同样是另一个瓶颈。
系统间对接问题
这也是出现在系统越来越多,而资源整合却没有那么完善造成的。前面说过,以ERP系统为核心,其他数据基本需要与ERP系统进行对接,而ERP的这套系统,存在如下问题:
- 系统API与文档缺乏
- 外包开发效率不高
- 设计思想不够新
缺乏API接口,所有的数据对接基本需要通过直接连接业务库,在经过数据的同事搭建数据仓库进行数据加工后,这部分的问题稍微得到环节,但这也仅仅是报表部分的问题得到解决(也就是读的部分),更新业务库数据(插入或者更新数据)则依旧需要直接写业务库,无论是安全性还是稳定性,哪个方面都存在隐患。
外包的开发效率不做讨论,而设计思想不够新的问题,其实就也是不太能满足目前更多的需求,这点上来看,一个集成了所有功能的完整系统也许不是主流,为了适应快速迭代的需要,平台化的系统才更能适应多变的需求。当然底层是要做到稳定的。
开发架构问题
对于自主开发的部分产品,上线初期的规划没能做到标准化,没有严格的开发规范,在后期需求变更时,需要对当初的功能进行修改,重新理解的时间会有不少。
初期选型的硬件环境,如果选型不够通用,后期如果切换,或者发现稳定性或效率不能满足时,切换的成本就比较大。
其实在标准化,规范和环境选择上,初期也是花了不少时间去比对选择,就目前来看还是可以的,只是总是有更好的方案在前面,让人总觉得还有很多需要去做,去完善。
小结
本次基本介绍了在公司初期业务系统发展以及系统发展后开发中遇到的问题等,下一节我将大概说一下自己的解决想法,写的不对也请大家指正。预告一下关键信息:
- 前端与后端的分离
-
后端选择选择java还是PHP