侵入式程序之殇

  终于写一点技术的东西了。什么是侵入式的程序?你开发完了,其他的人直接引入你写完的库包。比如Java的SDK。或者你作为本地代理进程,放到业务的机器上,代理业务的一些操作。

  这种使用方式非常的经典。但是规模效应一出,给程序维护人员带来了巨大的痛苦。

  宕机率这个指标,一些非常优秀的公司,大概在万分之几。而且因为业界潮流,就是上云。容器的宕机率会偏高。

  云的优势之一就是,分布式场景的容错。一旦出现异常,可以快速替换容器,做到弹性伸缩等等。听起来很美好。但是,云会引起更高的单点故障率。容器的稳定性是比物理机要差许多。

  由于这个因素,侵入式程序,一般抛error的概率会很高。再加上业界大厂基本上都在数十万到百万这种规模的机器。几乎每天都会有业务找上门,来质询你的代码是不是有问题。

  哪怕是成功率在99.9999%,规模之下 必定出故障。也意味着必定有业务找上门。你需要给不同的业务每天讲n遍,解释这个问题。

  而且排查故障的难题在于,故障的尸体难保存,没什么现场。库包和业务代码耦合,不清楚业务的项目到底是怎么用的,无法确认完整的代码逻辑。当然,最难的人员流动因素。负责项目的人,很多也是不了解项目细节的,新来的人接手了老项目,去给前辈们填坑。

  项目设计,尽量往集中式的方向上走。尽量使用http接口,去解耦服务之间的关系。在服务维护上,可以少很多蛋疼的事情。

  如果真的避免不了,必须使用侵入式的设计。需要做好监控,近实时的管控业务服务上的代码运行状况。无论是排查定位,还是解决背锅问题,都是有力的线索证据。

  如果连监控都无法做到,(确实有这种可能的,数十万台机器数据上报,不是什么服务都扛得住的)。

  那就只能烧香拜佛,杀程序猿祭天了。我非常佩服,维护这种组件的技术同学。技术牛逼,想象力丰富,排查问题纯靠想象力和经验猜。心态还好,不然坚持不了几天,就该跑路了。

  集中式不是没有问题,太多的项目为了简单。疯狂的把微服务,堆成了巨服务。巨服务维护不了了,跑路,再找一个舒服的项目。所有的东西堆在一个数据库里,堆在一个集群里,一个微服务上。就好像得了巨人症,身高三四米,出行坐地铁得跪着,进出屋子得蹲着。突然有一天,基础组件服装店要统一服装制式,发现没有制作3米多人群的服装。没有办法,业务就只能去撕逼,为什么你们没有以客户为中心,怎么不去考虑清楚,尽推些乱七八糟的东西。(狗头保命,确实存在一些人,推一些乱七八糟的东西)

  年底了,希望大家跳槽找工作,避开这种坑项目。

  
全部评论

相关推荐

4 收藏 评论
分享
牛客网
牛客企业服务