我的“技術架構”之旅

　　導語：很久沒寫過涉及技術的文章了，因為進行職業轉型後對技術有種很糾結的心態。熱愛——每每看到五顏六色的程式碼視窗就會心裡發酸，想起曾經那是生活中的一份燦爛心情；不自信——這麼久離開技術會不會已經落後生疏（雖然一直沒有脫離技術的學習與參與，但是失去了一線寫程式碼的實踐）。今天恰好去參加AWS（亞馬遜雲服務）的一個區域討論會，一位亞馬遜的架構師在為大家講解AWS雲服務及一些案例的架構設計，很多熟悉的概念，還有這位架構師的謙遜和真實，一切是那麼親切。所以心血來潮，想回顧一下自己做架構的職業之旅。

　　本想自己定義一下架構設計的要點，發現百度百科中總結的就很好“系統架構既需要掌控整體又需要洞悉區域性瓶頸並依據具體的業務場景給出解決方案，並能把各種目標需求進行不同維度的擴充套件。”提煉一下：

　　熟悉業務：技術本身是無“價值”的，要落地到具體的使用場景中為客戶/使用者解決問題。

　　掌控整體又要洞悉區域性瓶頸：我們時常要對技術實現進行最佳化、時常要解決各種隱藏的bug，但是正如“過早最佳化是萬惡之源”這句話的深刻含義一般，我們應該在明晰全域性的基礎上再去確定需要解決哪個區域性問題。

　　不同維度的擴充套件：面對不斷的變化，靈活性與可擴充套件性是我們進行架構設計所追求的目標。

　　這是一些做架構的核心要點，其中還有很多其他的點。看看我的點滴領悟。

　　第一階段：外包生涯

　　作為技術人員彷彿會本能的排斥去做IT外包的工作，彷彿這樣就會成為IT界“藍翔”的代言人。其實做外包人員並不意味著低端和無成長性，特別是對於在一些有著嚴格規範和標準的外包企業中，有對程式碼規範、註釋和文件的要求；由於只需要做業務中的一部分，這就要求把業務功能和介面設計的足夠分離。正是這段經歷讓我形成了規範的程式碼習慣和有了功能介面化、模組化的思維。

　　參考：華為程式碼規範文件，Google開源專案風格指南；書籍—《程式碼大全》

　　第二階段：研發單機軟體

　　這是自己第一次獨立負責研發一款軟體，開始接觸客戶瞭解業務，然後訴諸於程式碼實現。在這個過程中有一個印象極深的片段，接手的程式碼有一個長達千行的函式，程式碼命名隨意也沒有註釋，看得我雲裡霧裡。最後導致自己付出了大量的時間，包括利用debug工具一行行跟程式碼才瞭解清楚業務邏輯，心裡默默地走了數百遍的草泥馬。隨後我便用第一階段養成的好習慣開始進行眾多功能的分割，把這個千行的龐然大物分離成一個個套用的小函式，另外在程式碼（命名和註釋）上進行規範，不但利於自己後期的維護，我想也不至於難為下一個接手的研發人員。在這段經歷中，我開始有了把一些工具函式抽出來寫成工具類的意識（這期間還看了很多開源的程式碼，從其中抽出不少工具函式）。另外一個重點，就是對單一程式外掛機制的利用，比如可以靈活的調節介面展現元素，利用程式的動態載入機制（動態庫）來對程式進行區域性升級和邏輯改變。

　　參考：snort和tcpdump的原始碼充分實踐了程式的外掛機制；部落格文章—《提高工作效率的工具“類”》

　　第三階段：Client/Server端程式設計

　　C（B）/S架構意味著開始接觸網路程式設計、web程式設計。這個階段對自己影響最大的應該是分層的思想。網路協議棧分層的精妙設計和java SSH框架的使用都深深影響了自己，比如自己一個即時聊天系統的架構設計就充分使用了分層的思想，包括後期使用分層的思想搭建了一些業務無關的技術平臺，便利了自身也充實了公司的技術貨架。

　　參考：部落格文章—《IM系統架構設計之淺見》，技術平臺原始碼github—高效能TCP網路伺服器程式，基於TCP協議的遠端過程呼叫框架客戶端實現

　　第四階段：轉向Linux系統、服務端程式設計

　　2011年時隨著網際網路/移動網際網路的風暴愈加狂烈，90%以上的後端服務都是Linux承載，客戶端技術又太碎片化，所以自己提前預判，將自己的技術棧從Windows全面轉向Linux，從客戶端轉向服務端。如果說自己的架構生涯裡轉折點只能選一個，我會選這個階段。Linux體系和windows就是兩種不同的文化，其中《Unix程式設計藝術》這本書可以說是我的精神導師，我閱讀了不下四遍。書中的很多思想都成為我今後做架構的依據和準則，比如“模組原則：使用簡潔的介面拼合簡單的部件；”,濃縮成一個詞一句話“KISS——Keep It Simple，Stupid!”。當Martin Fowler與James Lewis還未提出微服務的概念時，依據這些思想我已經做了很多微服務的設計和實踐。

　　參考：部落格文章—《三讀《UNIX程式設計藝術》——UNIX哲學》《服務端架構中的“閘道器伺服器”》

　　第五階段：搭建網際網路平臺級產品

　　這個階段因為自己的角色已經不僅僅是個技術人員，而是已經深入到業務和產品設計以及運營中去。這時的思路是一定要以業務指導架構設計，我們不可能考慮全面所有事，架構可以隨著業務發展慢慢演化。但此時的架構範疇已經不單單是某個程式的架構，而是技術選型、架構設計、效能最佳化、安全、系統釋出、運維監控、業務資料分析等對整個業務鏈的支撐。

　　參考：待總結（包含移動APP，智慧硬體、web開發、資料庫、雲服務、高併發等等）

　　以上就是今天心血來潮的一些主要節點的回憶，其實還有很多的點點滴滴，正是由於這些點滴構成了自己的技術思想和職業生涯。敬曾經作為技術人員的自己，敬所有還在技術崗位的程式猿兄弟美眉們。