今天这篇文章是架构师大刘的故事，架构师大刘——3 个 180 的男人（身高、体重、房子…………的贷款）
如果你想将来成为一名架构师，不妨看看大刘的经历。
大刘对架构师一直持有两个基本观点：
-
高级程序员和架构师是两种完全不同的物种，但足够强即可物种跨越。
-
不是每个程序员都有机会可以成为架构师，但准备的足够多即可争到机会。
大刘自己亦是如此。
多年前，大刘已经是一位高级程序员了。分给他的任务，完成的比团队中的任何一个同事速度都快，比任何一个同事质量都高，在完成自身任务之余，他甚至可以腾出手来帮别人。
当时，大刘公司有自己的电商平台，同时还从外接了一些项目单子，去维持公司的盈利。无论是电商平台，还是项目单子，都是用的同一套开发框架——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就是架构师了？有点水啊！架构师到底是一个什么样的岗位？不同的公司，对架构师有不同的要求，有的要求技术很强，有的要求技术+业务结合的好，有的要求手写框架，有的要求擅用框架解决问题……有的公司压根就没有架构师这个岗位。
-
我们都希望成为一名架构师，某些时候是更希望自己是众多程序员当中的那位“技术一哥”。我当年也是非常渴望成为架构师。
-
我们需要保持对技术的强烈热爱，很可能因为这种热爱，要做一些比较*的超出既定工作范畴的事情，这些事情既能极大提高我们的技术水平和视野，也能帮助团队的产品质量得到极大的提升，这是双赢的事情。
-
有些机会，我们需要自己去把握住，去主动出击，去向机会亮剑，亮出我们的才能，亮出我们的态度，只有这样，才能向我们向往的职业岗位迈出坚实的一大步。
所谓不负此生，唯此而已。
最后，希望这篇文章对你有帮助。原创不易，希望得到你的三连支持。
你好，我是四猿外。
一家上市公司的技术总监，管理的技术团队一百余人。
我从一名非计算机专业的毕业生，转行到程序员，一路打拼，一路成长。
我会把自己的成长故事写成文章，把枯燥的技术文章写成故事。
欢迎关注我的公众号，关注后可以领取高并发、算法学习资料。