查看原文
其他

业务架构的设计思考

老虎高 说点特别的 2018-12-04

阅读本文大概需要 3 分钟 。

如题。


写在开头:人生一辈子最开心的事就是用你的真诚和善良赚到了陌生人的信任,久而久之成为朋友,并且一直信任你,支持你,跟随你;这是用钱都买不到的人格魅力,堂堂正正做人,明明白白做事。


扯的有点远,回到今天的主题:由于我从事医疗行业已经好几年了,见过的应用系统大大小小的也不少了。再者,关于数据库方面也有一些心得。这么说吧,好比新买了一台电脑,看上去牛逼哄哄的,结果拿着360体检跑了一下分,60分还不到,远远不及格。一个字:垃圾。


那么针对于设计这点事,今天认真谈一下。



1、关于应用前端的设计。


前端是用户登录系统之后,一眼就能望到的界面,也是门面。说通俗一点,这就跟相亲一样,你到底是钻石王老五还是小奶糕,很大程度上会决定这次的相亲的成功率。所以第一感觉很重要。有的公司采用前端和后端分离式设计。前端页面一般会用js去渲染,之后在通过页面和后端数据整合。有的公司会采用模块化开发,每天上班第一件事就会进行commit更新代码,本地的时候测试的好好的,结果UPDATE后,问题出来一大堆。所以,设计前端的,一般都要求有很强的审美观。前端攻城狮达不到,大点的公司专门会雇个UI设计师或者美工。所以前端的水也是特别深的,什么叫美?王八看绿豆,看对眼了那就叫美。什么叫前端的设计思想?他是一种经验,一种在生活中我们开发所遇到问题的解决方案的汇总,一种模式,一种思想。并且不是固定的,因为随着外在技术环境的发展,生产环境的变化,业务的不断复杂化,我们也在不断总结,所以他也在不停的变化。


这几年,前端框架一般采用React、Vue、Angular。涉及到的语言一般用js、h5、jquery、ajax、bootstrap等。其实不论采用何种语言,能写出来很不错的前端就是更好的。哪怕用php能造出来所谓的轮子也就值了。



菜单可以设计在同一个页面的最好不要分开设计或者设计二级菜单,这样用户又多了一个步骤。会感觉到麻烦。有的公司我看到一个菜单有5,6个子菜单,还不支持并行操作,这种逻辑真是搞不懂。



总之一句话:弄得好看、适用,就对了。毕竟客户大大说啥都是对的。。


2、后端的设计


后端的设计就比较复杂了,逻辑性要求比较强。我举个简单的栗子:比如要设计一个医院的门诊收费系统,那么在数据库中就要有部门表、人员表、以及人员角色权限表、给患者收费的项目价格表等等。这些表又需要关联起来,通过某个表的id或者特定的字段id去关联。然后在后端的代码中通过sql去关联就可以达到实现的效果了。当然在这里说说很简单,真要做起来确实是需要耗费很大的精力的,但是后端攻城狮不就是吃这碗饭的吗?干什么不麻烦呀。。


再者,表中的主键和外键是避免不了设计的。以及索引。数据量一大,索引就会起到关键性的作用。会加快N倍数据查询速率。这一点我相信大多数的项目人员或者dba是体会比较深刻的。当然,同时索引是一把双刃剑。我见过有的傻逼dba,把表中的列都加上了索引,在应用业务飙升的时候,系统反而拖慢了。这就相当于馒头好吃,连住给吃了十几二十个馒头,撑饱了!


分库、分表、导表、迁移


如果随着时间得推移,业务数据逐渐增长。业务就会被拖慢。这个时候就要去考虑进行分库、分表。建立表分区。有的公司会选择迁库,俗称一刀切割。最暴力也是很完美得一种解决方式。


导表是什么样的逻辑呢?比如海量超市顾客人员表,进去购物的时候会存一张人员表。那么顾客购物完毕之后,会再建立一张人员表,两张表的表结构一致,只是有个单独的字段用来区分标志。再考虑从应用上调取存储过程,把第一张表的数据导到第二张的表里面,这样就进行了业务数据的拆分,减轻了表的数据量。以后查询历史数据效率会高很多。有的人也许会问,如何进行导表呢?存储过程该咋么写?


其实存储中只需要在顾客结账完毕之后,存储先delete掉第一张表的数据,建立一张临时表,将临时表的数据批量插入第二张表即可。


3、应用和数据库升级。


根据几年来多次的升级经验,曾对升级中遇到的问题和方法进行了归类总结。在进一步优化程序结构的基础上可考虑自动升级。关于自动升级的方案设计如下:

第一,数据库层面解释。针对数据库结构升级的情况下分为以下几种。

新增表:新增表对数据库无大的影响,对现有程序也无大的影响。

新增字段:在大部分的表中增加字段也不会影响现有程序,可能和最初框架设计有关,部分表在增加字段后会造成错误,若造成错误建议修改中间层,完善系统。

新增配置:不会影响现有程序。

新增及修改索引:不会影响现有程序

新增及修改主键:不会影响但需要重组表结构。需手动处理

新增表字典信息:不会影响现有程序

新增存储:大部分存储升级不影响升级


根据升级应影响最小化的原则,升级最简流程如下:

先根据升级文件对脚本进行分级整理,在升级前对表结构进行升级(不包括主键重建等需要重组的步骤),部署可部署存储,增加系统配置。对老的服务层进行复制后拷入新的升级文件,并更新服务。将升级文件放入自动更新等待升级(关闭IIS)。升级当晚,关闭老服务,启动新服务。打开IIS即可完成升级。

程序设计理念如下:

对升级步骤进行流程化,根据现场服务层版本和时间索要升级文件,文件按照脚本存储及是否可升级前分类。程序进行数据库查询保存升级涉及到的动态库,存储及应用相关的配置文件进行保存。对于可进行提前升级的脚本直接进行导入执行,若存在可能影响升级后使用的配置进行提示,例如系统是否开启合理配置等。对需要手动执行的给出手动执行步骤提示及注意事项。对升级进行流程化改造。


请分析合理性及可行性。


闭门造车OR造轮子,万万是行不通的。做事情得做到极致才行。

老虎高1分钟前

你喜欢,我坚持。


END


往期文章:

陪读者们打响第一枪!

别用吃奶的劲去坑爹

我的前28年!


懂业务的技术人!

说点特别的。

文章已于修改

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存