談談系統架構這個東西

架構這個詞在很多人看來都是很高大上的一個東西。事實上，搞架構的這些人卻也都是些大神，至少都是在這個領域浸淫N久的專家級人物。現在很火的全棧工程師這個概念，就是架構師的另一種表現形式。

之于架構，其含義無非是從技術細節跳出來自上而下宏觀地看待系統的一個思維，就好比建築設計一樣。架構師的角色和建築設計師在某種意義上是相同的。在微網誌上看到蔡學镛分享過這麼一個架構設計流程的圖，從中或多或少能看出架構設計一個大概的流程。

首當其沖的，肯定是需要對整個系統的業務進行拆分，進行業務設計，目的就是要捋清楚系統是幹什麼的，能提供什麼功能，對系統的需求要做到詳盡的分析和考慮。不過這部分，在我參與過的一些項目看來，尤其是對現在普遍使用的靈活開發流程來說，無需考慮的太面面俱到，但至少不能太窄或者偏離正軌，後續的開發過程會不斷的回報回來進行調整。

接下來，系統的業務明确之後，互動設計和領域模組化便可以同時執行。當然，這裡我是覺得互動設計和架構師是沒啥關系的，頂多就是兩者要相輔相成。而領域模組化這個就顯得很重要了。領域模組化是業務設計的主要邏輯，把現實中的業務轉化成抽象的對象，這個确實是能力的展現了。我覺得這一部分很多出色的架構師相比其他人突出的一個很關鍵的地方。

技術子產品設計則是在了解了系統的業務需求之後，對整體的一個技術架構上的設計。這裡對于技術架構，我一直有一個分不太清楚的東西，就是軟體架構和系統架構。說到底，這兩者都是軟體層面的含義，所不同的是前者到了代碼層面，而系統架構則是到了軟體層面。軟體架構是位于系統架構之上的。一個系統，使用了Spring、Hibernater然後用了MVC設計模式，這就是軟體架構；一個系統分成負載均衡子產品、Link子產品、隊列子產品、資料子產品、推送子產品等等則就是系統架構。再往下就應該是部署架構了，比如系統部署了幾個結點、結點之間的關系、網絡的規劃結構、系統的高可用、可擴充等等。當然對于一個系統來說，資料的設計是可以拿出來重點進行的，畢竟對于網際網路應用來說，資料 is all，系統的很多性能、效率問題是和資料的存儲設計有密切關系的。

到最後，業務之上的這些設計會反作用于業務，将系統的關鍵點回報回來，進而對業務進行調整，進而再推進整個架構的流程。現在很火的靈活開發，某種角度看來就是一個不斷疊代、回報的過程，是傳統架構設計的一種演化形式。

談到架構，那麼如何才能具有架構能力呢？借鑒在知乎上看到一個回答：

視野開闊，知道可以直接用哪個開源項目來滿足這樣那樣的需求。多數時候其實我們并不需要重複造輪子。視野窄的架構師會放着捷徑不走，不斷讓團隊重複造輪子，直至把項目拖死。

精通設計模式，但又不泛用。不設計過度，不在各種細節問題上需求蔓延。所有架構設計都是為了滿足産品需求的，不滿足需求或者過度設計都是菜鳥行為。

把系統拆分成多個子系統或子產品，子產品之間盡量松耦合，使得原先隻能串行的開發任務，可以并行開展，也就是說良好的設計可以通過投入更多人力來縮短工期。反之拙劣的設計需要一個人維護一大坨代碼，無法通過加人并行開發來縮短工期。

能清楚地知道系統的瓶頸在什麼地方，不斷地定位技術難度、研發進度、性能、記憶體等各方面的瓶頸，不斷調整骨幹力量解決瓶頸，在風險爆發之前就消除隐患。

行業經驗帶來的直覺和預見性，可以預先需求可能産生怎樣的變化，提前把可擴充性、後向相容性設計好。但仍然不要過度設計

以上對架構的一些了解，很多地方自認還是有點迷糊。在進行系統設計的時候，也經常摸不着頭腦，把不同層次的東西混為一談。記得蔡學镛大神之前還分享過一張圖檔，對架構講的挺透徹的。不明白的時候看看這個，會有種茅塞頓開的感覺。

原文出處：後端技術雜談

<a href="http://www.rowkey.me/blog/2014/06/04/sys-arch/" target="_blank">原文連結</a>

轉載請與作者聯系，同時請務必标明文章原始出處和原文連結及本聲明。