程序猿,该自私一点
程序猿,该自私一点
zengzexin27 发表于1年前
程序猿,该自私一点
  • 发表于 1年前
  • 阅读 34
  • 收藏 0
  • 点赞 0
  • 评论 1

腾讯云 技术升级10大核心产品年终让利>>>   

摘要: “我不是柳下惠,美女坐怀我还是会乱,所以唯一能做的,是不给任何美女有坐怀的机会。”——马英九

       这个问题的思考,起源于楼主的工作,楼主所在的办公室,出了个由于表结构修改,导致程序出错的问题,看到了用户发来的邮件,说起了2014年的事情,楼主想到了陈年往事。遥想当年,楼主就是那个事情的男猪脚之一,此处省略1024个字(为什么是1024,我不解释,程序猿都懂的)。。。。。触景生情,潸然泪下。楼主认为这个字段,绝对是亚马逊的那只蝴蝶,会引起德州的一场龙卷风。

        

        楼主在忧伤的时候,不禁想到,如果楼主这次还是主角,楼主能全身而退?答案是不行,楼主就妄下结论,如果每个人碰到同样的问题,都会有同样的错误,那么这个问题,就与个人能力无关,不是某个人的问题,是整个开发体系的问题。同时,楼主不禁大惊失色,心生恐惧,还有多少只蝴蝶在翩翩起舞,只是没引起风暴。楼主的第一反应是抓蝴蝶,这个想法让楼主更加惊悚,楼主发现现在竟然没能力抓蝴蝶,根本不知道蝴蝶在哪里,系统啥时候出问题,或早或晚,全凭运气。

       

        楼主虽然愚钝,但是还是明白人,知道软件开发是个很严谨的东西,将系统的稳定性寄托在运气上,是不科学的。楼主负责的X具系统,目前的架构,非常薄弱,无法适应业务的发展,不大好维护,容易出问题了。用户提出修改程序,楼主或多或少会有抵触心理,为什么有这种心理,因为 楼主心里没底。 楼主都没信心了,怎么能给用户信心。 楼主想要重建信心,这种信心不是基于主观的想法,觉得这个模块有问题,那个模块没问题的,而是要有技术做保证。

 

               

        楼主想到这里,开始开朗起来了,程序猿是有选择的,程序猿可以给用户做程序,同样的,也可以给自己做程序,差别在于,为用户写的程序,会让你的明天更忙(道理很简单,因为你要维护),为自己写的程序,你的明天会更轻松,程序在帮你减轻工作的负担。楼主也在想,这么做是很有意义的,一个人如果不能对自己好,那怎么对别人好咯,因此,楼主得出结论,最先进,最好用,最稳定的程序要用在自己身上,这样才能帮助自己做出好的程序。但比较逗逼的是,楼主现在几乎还是刀耕火种,好在楼主从来都是懂得安慰自己的,没事,现在落后,说明还有很大的提升空间嘛,楼主没你们先进,但楼主可以上升的空间比你们大。

        

        问题又来了,程序猿该给自己什么程序。能想到要做的东西很多。楼主想到了“时间常有,时间优先”这句话。因此,楼主觉得,什么事情让你变得忙,就先去解决什么。楼主整理了一下最近碰到的一些问题,归结起来,楼主平常工作,只会做开发,运维做的不好,导致维护工作一直在蚕食楼主的时间。

        楼主觉得,运维的话,需要建设一套运维体系,这套体系可以做到预防故障,发现故障,处理故障:

1、数据是源头,数据库对象发生变化,是很频繁的事情,要建立数据库对象发生变化的订阅机制,主要是为了知道数据库对象修改的影响范围。吼吼~摁不死蝴蝶,但不能让你乱飞。就像关注微信公众号一样,有新消息就看看,比如你订阅了哪些数据库对象,这些对象发生变化后,自动会有个提醒,避免刚才说的问题,数据必须坚持先订阅后使用的原则,在底层管住数据。这件事情不难,建个表存元数据,再建个从表保存订阅关系的信息,定期比较表中的数据和生产数据库,有发生变化,给订阅的人发消息就好了。

但是接下来几条就比较难做了,

2、从源头预防错误数据进入数据库,我的方案是,部署自动化数据校验框架,在数据存盘的时候进行有效性校核,为了不增加业务代码的复杂度,这个校核是以拦截器的形式存在,独立于业务代码的,采用配置的方式,在数据发生变化时先进行校验。

3、程序实在控制不住,比如分布式事务,由于分布式事务的数据一致性和系统可用性,两者必须舍弃一个,比较主流的做法是放弃数据一致性,用最终一致性取代强一致性。因此,是不可能通过事务来控制数据的一致性,就只能主动寻找错误数据,做一个框架,抽取通用的数据检查规则,部署自动化的数据检查任务,每天跑任务,降低错误数据在系统的停留时间,进而反推程序的问题,及早发现问题。

4、以上都防不住,系统还是发生故障了,就要处理故障了,这方面设备处值得我们学习,他们是这样管理工具的,机坪上的工具设备发生故障后,如果工具没法马上移走,库房保管员,会去挂红牌,避免有人使用故障工具。对我们来说,错的程序不用没太大事,最坏的结果就是业务人员骂几句,起码不影响数据。一用事情就大了。某个模块出现故障后,首先要能告知用户该模块有的故障,以及故障的影响范围,其次要有一个熔断机制,出现符合熔断条件的情况,就自动停用掉,告知业务人员该模块开发人员在维护,还有大概可以使用的时间点。

5、最后是关于如何恢复故障导致的错误数据,我们在恢复数据的时候不能太依赖于数据库备份,数据库备份这种不是很靠谱的东西,有的有有的没有,要建立数据回退机制。我想到了一个逆向操作的方法,在程序每次执行sql语句的时候,同时自动生成逆向的语句,例如执行删除的时候生成插入语句,执行插入的时候生成删除语句,执行更新的时候,生成相反的更新语句,用于回退数据,事务无非包括增删改三种语句,一个事务对应着一个逆向事务。

        总结一下,运维在整个软件开发体系中,应该是在一个非常重要的位置,但在实际工作中,没有得到相符的重视程度。楼主也是这样的,没有足够重视,系统用代码堆出来,而不是设计出来,缺乏良好的架构和对业务收放自如的扩展性,X具系统做了两期,回过头来看,业务是做到行业领先,那技术呢,依旧落后,现在看着这系统也挺无奈的,想要把技术拉回正轨要经历非常曲折的路线,我希望在我身上发生的教训,不要出现在其他人身上。

        

        

        借用一个很形象的成语,叫做“围魏救赵”,开发就像进攻,运维就像防守,你看你都打到赵国了,但是魏国的首都守不住了,还是得回来。我认为以我们现有系统的规模,运维应该重于架构和开发,随着系统规模越来越大,重要性也将跟着提高,投入精力在架构和开发,倒不如老老实实搞好运维,这种投入很有价值,可以让我们和用户对我们的系统更加有信心,这也是系统建设提速的基础。

 

---------------------------------------------未来的分界线----------------------------------------------

        虽然楼主觉得遗留系统的改造很困难,工作量很大,但是楼主很乐观,多年的经验告诉楼主软件的发展规律。好的架构、平台是买不回来的,也不是找几个开源的软件拼凑一下就能拼凑成的,也是设计不出来的,而是长期演变才落地生根的。

        当你面对技术系统无可奈何的时候,请不要抱怨现在的系统设计如何如何不合理,技术如何如何落后。就算,你现在在全新的项目中实践最牛逼的架构,但是经过技术革新,人员变迁,这套架构也会慢慢落伍,这时候系统将会成为遗留系统,那时候处境和现在没多大差别,一样会碰到遗留系统的问题。只有具备对遗留系统架构进行演化和技术升级的能力,才有能力保持系统在技术上持续具备竞争力。

        关于遗留系统改造,不一定要亲身实践,也可以从别的项目中寻找经验,比如XMS系统升级,这件事情很有代表性,XMS系统的业务很强大,系统也很庞大,为什么会以推倒重建这种方式升级,千里之堤毁于蚁穴,XMS系统即将没了,楼主觉得应该找找这个蚁穴在哪里,是一个还是好几个,是不是系统没了蚁穴就跟着没了,这些蚁穴是否只存在于系统层面,其他层面上有没有,如果还有,是坐视不管,等着下一次决堤还是想想应对的办法。

------------------------------------------------结束的分割线---------------------------------------------------------------

        

 

 

共有 人打赏支持
zengzexin27
粉丝 0
博文 15
码字总数 14529
评论 (1)
zengzexin27
非常感谢建文,在结束后,给我一个关于oracle的undo和redo的建议,是一个方向,可以更好地理解如何做取消和重做
×
zengzexin27
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: