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