您的位置:首页 > 运维架构 > 网站架构

大刘终于当上架构师了

2021-08-31 12:02 429 查看

今天这篇文章是架构师大刘的故事,架构师大刘——3 个 180 的男人(身高、体重、房子…………的贷款)

如果你想将来成为一名架构师,不妨看看大刘的经历。

大刘对架构师一直持有两个基本观点:

  1. 高级程序员和架构师是两种完全不同的物种,但足够强即可物种跨越。

  2. 不是每个程序员都有机会可以成为架构师,但准备的足够多即可争到机会。

大刘自己亦是如此。

多年前,大刘已经是一位高级程序员了。分给他的任务,完成的比团队中的任何一个同事速度都快,比任何一个同事质量都高,在完成自身任务之余,他甚至可以腾出手来帮别人。

当时,大刘公司有自己的电商平台,同时还从外接了一些项目单子,去维持公司的盈利。无论是电商平台,还是项目单子,都是用的同一套开发框架——SSH,也就是:

Struts + Spring2 + Hibernate3

这其中,有三个主要技术问题是迟迟没有解决的。

1. Hibernate 的 Session使用问题

Hibernate 的 Session 滥用,在大刘公司内部长期存在。这种情况造成的后果就是:

  • 要么资源狂占内存,使得应用崩溃;
  • 要么 Session 提前关闭,导致存储数据报错,数据丢失。

对这种问题,大刘他们的做法就是根据出现的错误栈,对应的修改下出错的方法。比如,临时 Google 查一下,去换种获取 Session 的 API 调用;又或者就修改下逻辑,创建个新的 Session 了事。

因此,大刘发现在他们的项目里获取 Session 的方式,那叫一个五花八门。估计 Hibernate 的作者看了,都会非常吃惊——“我竟然还写过这种获取 Session 的 API 呢?”

而这些花样繁多的获取方式,又进一步刺激了项目在线上的各种问题,这些问题又造成了各种 Session 的乱用的进一步泛滥。

恶性循环啊!

2. 缓存使用问题

在大刘他们的系统中,或多或少都用了外部缓存。缓存组件是当时最流行的 Memcached。

但是,由于对 Hibernate 没有深入了解,这套缓存并没有和 Hibernate 综合在一起使用,于是问题就来了。

缓存数据和数据库中的数据出现了各种脱节:

  • 查询数据的时候,本来可以走缓存的时候没有走;
  • 更新数据的时候,又经常忘记同步缓存状态。

说出来都不怕丢人,缓存命中率可能都不到 20%。

性能堪忧啊!

3. Spring 对框架对象的管理问题

在使用 Spring上,也是个笑话。

最大的问题是,有些人和 Spring 感觉有仇,他就是不让 Spring 去管理对象的生命周期。

这造成的问题就是,NPE 异常在线上成了过年的烟花一样,处处盛放。要不就是,本来应该是单例的地方,却出现了好几个亲兄弟,好家伙,搁那里玩克隆人呢。

解决起个小问题,都能让人着急的脱水。

错误不断啊!

面对以上那三个问题的折磨,大刘却不得不忍受着。因为大刘当时只是个高级程序员,受技术水平和话语权所限制,明知道有问题,但是想解决问题又有点有心无力。

大刘自己默默地学习、看书,去不断熟悉 Hibernate 和 Spring,除了日常写已经写腻了的 CRUD 代码以外,他对业务代码之间的关系也做了十分深入的研究。当用户发起请求后,从系统收到请求,一直到业务流程完全结束,大刘对其中的各种技术细节都摸了个滚瓜烂熟。

但是,他却不敢对系统做任何工作以外的改动。

直到有一次,有一个月的时间,大刘几乎每天都陷在解决那三个技术问题引发的线上错误的泥沼里,当然,整个团队都是一样的状态。不知道别人能不能忍受,大刘终于受不了了,他有自己的技术梦想,有对自己的技术要求,不能忍受在屎坑中游泳的日子。

于是,大刘行动了。

那时候大刘工作已经五六七八年了,做事也没那么莽撞了。为了证明他能搞定那几个问题,他需要一套证据,一套他亲自验证过的证据。是什么证据呢?

大刘先把当时的项目拷贝了一份,然后熬了几周的夜,就着一本《Pro Hibernate3》的英文电子书和一本廖雪峰写的《Spring 2.0核心技术与最佳实践》,把里面所有不对劲的问题,愣是统统的改了一遍。

改完代码后,又找运维同事借了机器,完全部署了一套改过的系统。

然后,通过 Memcached 的 stats 命令,去统计出了缓存命中率,此时,这套改过的系统的缓存命中率已经从不到 20% 提升到了 80% 以上。

接着,又用压测命令,那时候还是 Apache 的 ab 命令,对改过的系统、原有系统进行了压测,得出了一个对比报告。

做完这些,大刘拿着这些东西,径直去找了直属领导,和领导诚恳的谈了谈,说出他想对系统不合理使用框架的地方进行改造,并且已经把改造这事儿自己独立完成了 90% 以上。

领导听完,看着压测对比报告久久没说话。那个时候,大刘的心紧张的像极了一团天津麻花,甚至想,大不了就带着压测报告和改造的经验去找下家了。

没想到的是,领导开心极了。领导告诉大刘,早就想规范整个项目了,想对整个系统的技术进行精确的改造和深度的优化,但是一直没能找到一个人能挑起大梁来,现在他支持大刘全面去负责牵头搞技术优化和系统改造的事情。

那几周没白熬夜!大刘通过自己的疯狂输出,得到了一个能全面审视、改造这套系统的机会,并且可以根据自身对 Hibernate、Spring、缓存的研究,把一些最佳实践应用到实际项目中。

此时的大刘,对架构师这个词,只是听说过,至于他是个什么概念,又需要做些什么,是完全不清楚的。不过,由于对 Hibernate 和 Spring 的深入研究,以及不断地在项目中实践各种它们的特性,大刘初步有了一些当架构师的感觉,知道了一套好的框架该是什么样子,以及它们为什么要这样设计。

再后来,公司的其他项目只要遇到了 Hibernate、Spring 相关的疑难杂症,都会过来问大刘,慢慢的同事们都知道,有个叫大刘的程序员技术还不错,大家给他起了个名:“SSH一哥”。

又经过了一年的摔打,大刘对架构师这个岗位已经有了自身的理解,知道架构师就是攻坚克难的技术骨干,知道架构师能掌握所有的技术选型,更知道架构师能光明正大的预研前沿技术。

大刘对架构师真的是向往极了,特别想成为这样的一种人。可惜,公司当时没架构师这个岗位,也没这个 title,真是犯愁啊。

再后来,大刘的领导晋升了,领导把他原来负责的事情一分为二:

  • 鉴于对大刘技术能力的认可和信任,几个相关项目的整体技术都让大刘负责;
  • 项目的日常管理工作,安排给了另外一位产品经理。

对于这样的安排,大刘倒是并不在意,他本身对管理工作也没什么兴趣,让他负责技术,能随他心意的去规范化开发项目,他已经很知足了。

但是,一件大事的出现,最终整个项目都给了大刘来管理,这是他万万没有想到的。

事情是这样,由于电商系统需要引流,为了吸引用户,产品和运营搞了很多活动,很多很多,多到了什么程度呢?多到了写的 if 语句可能占到系统代码的三成以上了的程度。

if(xx 满足 xx条件) {
//做xx事情
} else if(xx 满足 xx条件) {
//做xx事情
}

以上的这些代码,就像一条条择人而噬的鲨鱼,游荡在项目的字里行间。

多其实还好,也能忍。但最受不了的是,产品和运营自己也不知道活动会达到什么效果。结果就是,他们会不断的推陈出新,会不断地对活动修正。

这就难搞了。当时公司程序员人手本来就不够,不仅要维护电商系统,还要维护给客户做的各种系统,还要及时响应各种运营活动,响应的慢了还会被产品运营投诉。

不断地改啊改啊……终于有一天,一个程序员爆发了,疯狂的和负责管理的那个产品哥们儿对线。事实证明,祖安人是挑火的一把好手,于是嘛,产品和技术从动嘴终于到了动手的地步。

最终结果就是那位产品经理撒手不管项目了,那位程序员老哥被开除。

于是,就这么着,日常管理的这个事情也落到了大刘的头上了,技术和管理都是“SSH一哥”负责了。

但是公司对大刘的任命迟迟没有正式宣布,可能公司担心大刘资历尚欠,怕他 hold 不住吧。

对大刘来说,他能理解公司的这个考察期,想让领导吃上一颗定心丸,他就需要个机会证明自己。什么机会呢?还是运营活动和技术的矛盾这个事。

当时的问题大刘是非常明白的,根源就是产品运营给出的活动太多了,还频繁的各种修改,而这些活动规则的落地完全需要技术去实现,程序员们根本忙不过来。

如果把这些惹了大麻烦的活动,不管是新出还是修改,可以不让程序员们去修改代码就太好了。

于是,大刘引入了规则引擎这个东西,引擎用的是 JBoss Rules。

因为那个程序员老哥和产品经理的物理交流而走人了,所以,大刘手头有个招聘名额。此时,引入了规则引擎,正好就可以用上这个名额。

于是大刘招了一个程序员,专门负责改规则引擎的规则,这样,其他程序员就能解放出来干其他事情了。

总的来说,引入规则引擎这套方案实施的很好,大家都很满意,领导也非常满意。不久之后,大刘就正式的转正了。

可是,这不够啊,大刘想当架构师,现在这条路是技术管理。没有架构师的 title,对以后自己成为真正的专业的架构师不利啊。

因此,趁着领导满意之际,大刘向领导提出,能不能把 title改一改,改成架构师。

领导看着反正也没什么大碍,既没有增加什么成本,也没有什么负面影响,也就答应了这事儿。

于是大刘成了当时公司的第一位架构师。

以上就是大刘如何成为架构师的故事了。

你看,是不是这样:

  • 大刘能搞定SSH就是架构师了?有点水啊!架构师到底是一个什么样的岗位?不同的公司,对架构师有不同的要求,有的要求技术很强,有的要求技术+业务结合的好,有的要求手写框架,有的要求擅用框架解决问题……有的公司压根就没有架构师这个岗位。

  • 我们都希望成为一名架构师,某些时候是更希望自己是众多程序员当中的那位“技术一哥”。我当年也是非常渴望成为架构师。

  • 我们需要保持对技术的强烈热爱,很可能因为这种热爱,要做一些比较狂热的超出既定工作范畴的事情,这些事情既能极大提高我们的技术水平和视野,也能帮助团队的产品质量得到极大的提升,这是双赢的事情。

  • 有些机会,我们需要自己去把握住,去主动出击,去向机会亮剑,亮出我们的才能,亮出我们的态度,只有这样,才能向我们向往的职业岗位迈出坚实的一大步。

所谓不负此生,唯此而已。

最后,希望这篇文章对你有帮助。原创不易,希望得到你的三连支持。

你好,我是四猿外。

一家上市公司的技术总监,管理的技术团队一百余人。

我从一名非计算机专业的毕业生,转行到程序员,一路打拼,一路成长。

我会把自己的成长故事写成文章,把枯燥的技术文章写成故事。

欢迎关注我的公众号,关注后可以领取高并发、算法学习资料。

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: