今天的下午茶活動，與很多技術圈的老朋友詳談甚歡，聽到了幾位老朋友的分享頗為受益，我也給小夥伴分享我的一點心得。

技術成長需要什麼架構知識？

初入工程師這行時我有一個夢想，希望具備強大技術架構能力，讓服務於億級使用者的產品穩定運行於其上，今天我看到身邊很多架構師都走到這一步。

但對於當年剛入行的我來講，要達到這一點還只是個夢想，因為那時我並不知道應該怎樣構建這樣的架構，甚至連需要學習哪些知識都不知道。

我相信很多工程師在成長的路程上也跟我一樣，會被一個大大的問號困擾很久：如果要成為一個大牛，應該需要什麼樣的技術路線？

今天跟大家分享下通過觀察身邊的案例，我總結的一些在技術成長方面的心得體會。

架構師是怎樣煉成的？讓我們從聖鬥士說起。

技術人成長之路四階段

小時候有一部我特別喜愛的動畫片——聖鬥士星矢，現在來看，這儼然就是一個技術大牛的成長之路。（小編：校長果然是老司機了：）

1. 從接受訓練成為聖鬥士，就像剛剛入門的初級工程師

大多數的應屆畢業生，雖然之前學習了程式語言及演算法基礎，能用程式碼解決一些簡單的業務問題，但編碼規範與真正的業務開發實踐的要求還是有些距離。

個別彪悍的同學，畢業時能力已經達到中高階工程師的水平了，就可以略過這個階段。

這一階段最重要的是夯實程式設計基礎，養成好的開發習慣。比如：基礎庫API的使用、併發執行緒機制、基礎演算法、優雅的單元測試等。

這個階段與其挑選薪資，不如挑選合適的鍛鍊環境，比如尋找有良好的技術氛圍、有合適的導師，有挑戰的專案的團隊。

2. 到獲得青銅聖衣打敗暗黑聖鬥士，就像中/高階工程師

工作 1 – 3 年的工程師，在實戰中積累了一些開發經驗，瞭解常用技術框架原理並可以在實際工作中快速搭建服務；瞭解常用的設計模式，讓程式的擴充套件性變得更好，也可以開始勝任解決相對複雜的一些問題，負責中等規模的服務開發和維護；

這一階段最重要的是尋找可能的機會進行架構實踐，學習別人的架構經驗，最終總結吸收為自己的經驗或理論。多研究下典型場景的架構設計很重要，比如：典型社交場景的微博架構，典型電商場景的京東淘寶架構等。

如果公司有合適的歷練專案，則多向專案中的前輩學習。但更多的人遭遇的可能是不那麼理想的環境

這種情況下，在滿足專案交付時間的前提下，可以更主動去積極尋找專案中可以值得優化的點，通過網上閱讀的案例，引入更合適的技術來解決，給自己創造使用一流技術的實踐機會。

3. 到擊敗白銀聖鬥士，就像架構師

此階段，部分 3 – 5 年或經驗更久的工程師，隨著在工作中不斷遇到複雜問題和技術挑戰，工程師對原有的技術框架和設計模式有了更深的理解，再根據實際場景的應變，開始能夠獨立設計和維護大型服務功能。他們具備針對特定場景完成合適的架構設計的能力，在團隊中承擔高階工程師或架構師角色；

上文之所以說部分工程師，是因為並不是所有人都能跨過中高階工程師這個檻，成為一名合格架構師。

這一階段是架構知識由泛到專的過程。在特定業務場景下，能夠對架構有清晰的目標，並利用已有架構技巧實現目標與成本的平衡，最終滿足業務要求。比如作為一個合格的網際網路架構師，需要理解常用快取、儲存資源的特性及優缺點，具備架構選型和實現的能力。

另外，我覺得在大多數人看來，中、高階工程師差異還是很大的；而高階工程師和架構師反而過渡不是那麼明顯。

4. 再到戰勝十二黃金聖鬥士救出自由女神雅典娜

工程師到這個階段，已經不能用時間年限來衡量了，更多的是需要對這個行業的熱愛和合適的成長平臺。

隨著具體場景下架構設計實踐經驗的增多，一小部分架構師能夠把這些經驗抽象為一種通用的理論，形成架構設計的理念，並能夠用這種理念指導影響團隊中的其他人，加上對於技術如何應用到行業的深刻理解，成為一個公司的首席架構師；

成長為首席架構師，除了個人的努力和不斷學習總結積累外，一個好的實踐鍛鍊平臺至關重要。

就像高可用架構方向，如果沒有親身經歷過高併發、海量資料的服務架構設計和開發的過程，很難憑空想象可能的場景問題和技術挑戰，實踐經驗的總結抽象也就無從談起；

在這個成長的過程中，聖鬥士們通過不斷的磨難激發出了第六感、小宇宙，從而使他們變得越來越強大；而工程師也是在解決服務效能瓶頸、伺服器宕機、異常峰值應對、分散式資料一致性、海量資料儲存等問題中，不斷的總結出經驗和教訓，從而變得越來越有經驗。最終，極個別的一些首席架構師脫穎而出，成為了大師。

吳軍博士在《矽谷之謎》中也提到，這類工程師通過對行業及技術的理解，具備做出行業最好產品的能力，並進一步可以做出給世界帶來驚喜的產品，比如 iPhone 及 Google Glass 的總設計師。

高可用架構群就有很多首席架構師級別的前輩，他們在技術架構、技術管理等方面傳到解惑，成為技術人員成長的引路人。

在技術人員成長的各個階段，需要具備的知識和技能不同，從最初的語法規範的學習，到後來設計模式的靈活運用，再到對架構的理解和抽象，對技術人的素質要求越來越高。特別是架構知識，這是技術人成長中非常具有挑戰的那部分，涉及了方方面面的問題，看似雜亂無章，實際還是有跡可循的。

架構知識拓撲

所謂架構，在網際網路的場景，就是保障服務高效能、高可用、可擴充套件的一系列技術措施。架構的維護成本是評價其好壞的重要因素。

1. 網際網路架構的要求

具體來看就是通過一系列的技術手段達到以下要求：

• 效能要足夠快以能夠滿足業務需求；
• 業務流量峰值能夠扛得住；
• 突發異常流量能夠應對的來；
• 部分伺服器宕機不影響整理服務；
• 能夠隨著業務的增長保持有節奏的容量擴容；
• 再高階點就是，資源成本要足夠低，研發效率要足夠高，支援異地容災，資源彈性伸縮提高資源利用率等。

然而，所有這些針對架構的要求和保證，都需要建立在一定標準之上，如果沒有標準，服務的好壞，效能的高低就沒法界定，所以，為服務制定 SLA（Service-Level Agreement）就變得非常重要。

2. SLA 設定

SLA 從效能、容量、程度三個方面對服務好壞做了約定，比如一個服務的 SLA 可以簡單的描述為：

99.9% 請求響應時間 < 100ms；最大 QPS 2W；

這裡就規定了最大容量 2W QPS，效能上99.9% 的請求小於 100ms 響應，其中 99.9% 就是程度，這 3 個指標會讓我們很好的瞭解服務的狀況。

SLA 體系是架構的基礎，即作為對外部的保證，也是對內部的約束。

3. 監控的要求

另一方面，好的架構應該時刻了解服務所處的狀態，以保證能適時作出合適的應對策略，這讓監控體系變得非常重要。就像打紅警遊戲，有個間諜衛星和電力儀表盤是多麼重要！

所以，你需要知道如何能讓你的監控系統實時準確的反饋相關資料資訊，實時、方便、直觀是衡量一個監控系統好壞的重要指標。

總結：拓撲結構

有了以上兩個重要基礎，架構設計變得不再那麼困難，通過 SLA，你已經知道目標是什麼、通過監控體系，你已經知道問題在哪裡，剩下的就是通過一系列措施去解決它們。比如，選擇合適的儲存資源，適當的容錯和降級策略，為了架構解耦而做的服務治理和隔離，高可用的異地容災，為了極致效能而做的網路拓撲調整，以及為了運維效率和資源利用率做的彈性伸縮。這些知識相互關聯，互為制約，是設計一個好的架構的重要知識基礎。

下圖是我在負責微博多個專案的 SLA 時候提出的架構要點。

架構知識都掌握了也不一定就能設計出好的架構，還需要針對具體業務場景靈活的變通。一般分為 2 個層次：術與道。

架構上的術與道

在前面提到，架構師與首席架構師都具備架構設計的能力和經驗，但他們卻有著術與道的區別。架構上的術，就是針對特定場景的解決方案；架構上的道，是一種思想和理論，能夠指導很多通用問題的解決，它更有整理性、全域性觀。

由術向道的轉變，是一個大量親身架構實踐和總結的過程。一方面這取決於你是否有一個好的發揮平臺，如果沒有這種鍛鍊平臺，大量的親身架構實踐將無從談起，這種轉變幾乎不可能實現；另一方面，經驗的總結和抽象也不是閉門造車，和業界的高手共同交流探討是避免走進誤區及快速拓展思路的好方法，所以經常的技術分享，適當的技術社群互動就顯得非常必要。

通過不斷的學習和努力，很多人可以成為架構師，但只有很少的人能成為首席，一個很重要的原因是，除了出色的學習、抽象、總結能力外，大量複雜問題的架構實踐至關重要；而這一點一般只有在較大的平臺才能遇到。

架構知識說了不少，我們如何高效的獲得這些知識呢？

技術閱讀

對於工程師來講，我一直認為我們生活在最好的時代。網際網路的蓬勃發展給了我們很多的歷練和成長機會，技術社群的繁榮讓我們自我學習和提高成為可能。在這個年代，技術人員的成長在一定程度取決於知識獲取及消化能力。

技術部落格，技術叢書，技術文章，技術公眾號，讓技術知識和思想在工程師群體中自由傳播，形成技術成長的肥沃土壤，比如從類似「ArchNotes」高可用架構這樣的公眾號就可以學到大量一線架構師分享的知識與經驗。

然而，伴隨著技術社群的繁榮，技術知識變得越來越豐富，甚至太豐富了，以至於我們幾乎無法全部消化這些資訊，我們需要有選擇、有甄別的來看；有些需要泛讀，有些則需要精讀甚至去實踐。

初級工程師在夯實基礎階段需要系統的學習基礎知識，這個階段看書會讓你的知識吸收更系統，部落格和技術文章作為輔助知識擴充套件就好了。其他階段則需要逐漸養成良好的知識獲取習慣，比如：每個月看一本專業方向的書，每天定時瀏覽固定方向的部落格或公眾號文章，確保系統知識和架構經驗都能夠不斷的獲取和吸收。

一般來講，技術部落格或者公眾號，是擴充套件技術視野，吸收他人實踐經驗的好的方式和渠道；技術叢書則是系統學習某一方面知識的最有效途徑。

這麼豐富的知識內容，這麼多樣的展現方式，是技術人共同分享貢獻的成果；每個身臨其中的技術人既是貢獻者，也是受益者，他們學習別人的經驗，分享自己的思想，在相互影響中共同進步。

學習與分享

關於學習與分享，讓我想起了 Tim 在高可用架構群第一次分享時候引用的那段話：

你有一個蘋果，我有一個蘋果，交換後每人還是一個蘋果；你有一種思想，我有一種思想，交換後每個人會有兩種思想

這句話完美詮釋了分享與交流的價值。

要成長就必須去不斷傾聽別人的分享，學習別人的經驗。分享知識的人多了，大家的學習成本就會降低，成長速度就會變快，大家就會相互促進更快的成長。

根據我自己的體會，對外分享還是一個自我總結、積累以及進一步提高的過程。為了避免分享給大家錯誤的知識，我一般會對分享內容進行多次 review，把之前模糊的、不十分確定的問題搞清楚（分享後被人問住或質疑總是分享者不想碰到的），這個過程往往讓我對問題的本質有新的認識。

好的分享還會帶來很多討論和諮詢，促進對問題的更全面認識和思考。比如 2015 年我在 ArchSummit 大會分享了《新浪微博高可用服務保障體系演進》，現場和會後有很多小夥伴專門來找我一起探討相關問題，其中有不少場景是我沒有遇到的，也給了我很多新的啟發。

所以，學習與分享是一個互相促進的過程，學習別人的經驗，把自己的實踐總結分享出來，技術慢慢的積累，再分享，不斷成長，不斷學習。。。

所以，我今年除了寫些技術文章，我還計劃給自己一個新的挑戰，寫一本關於架構的書：《大型網站高可用服務架構實踐》。

寫到這的時候，其實我猶豫了很久，想做為啥非要說出來？我之前寫過一些技術文章，感覺還不錯，所以，就有過寫一本書的想法，但真準備去做的時候，發現寫書和寫一篇技術文章差別非常大。技術文章一般闡述解決一個問題，但書是讓人系統學習某一領域的方式，需要有條理的闡述解決一系列問題，並且還需要讓大家有興趣堅持讀下去，想想都很有挑戰。

今天前面同學分享時提到，如果實在感覺困難就倒逼一下自己，所以為了讓自己能堅持下來，我就嘗試下這種方式，讓“太忙了、沒時間”等藉口少一些機會，說不定還能吸引一些感興趣的小夥伴一起參與。