今天這篇文章是架構師大劉的故事，架構師大劉——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就是架構師了？有點水啊！架構師到底是一個什么樣的崗位？不同的公司，對架構師有不同的要求，有的要求技術很強，有的要求技術+業務結合的好，有的要求手寫框架，有的要求擅用框架解決問題……有的公司壓根就沒有架構師這個崗位，
-
我們都希望成為一名架構師，某些時候是更希望自己是眾多程式員當中的那位“技術一哥”，我當年也是非常渴望成為架構師，
-
我們需要保持對技術的強烈熱愛，很可能因為這種熱愛，要做一些比較狂熱的超出既定作業范疇的事情，這些事情既能極大提高我們的技術水平和視野，也能幫助團隊的產品質量得到極大的提升，這是雙贏的事情，
-
有些機會，我們需要自己去把握住，去主動出擊，去向機會亮劍，亮出我們的才能，亮出我們的態度，只有這樣，才能向我們向往的職業崗位邁出堅實的一大步，
所謂不負此生，唯此而已，
最后，希望這篇文章對你有幫助，原創不易，希望得到你的三連支持，
你好，我是四猿外，
一家上市公司的技術總監，管理的技術團隊一百余人，
我從一名非計算機專業的畢業生，轉行到程式員，一路打拼，一路成長，
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事，
歡迎關注我的公眾號，關注后可以領取高并發、演算法學習資料，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/296115.html
標籤：其他