最近學習了一些關於架構設計的知識想分享給大家。俗話說得好，不想當架構師的程序員不是好廚子。那麼如何成為一名架構師呢？接下來就聊一聊我的一些想法。
什麼是架構師
之前有同學問我，做了幾年技術，應該轉管理還是轉架構師？對於這位同學，我給他的答案是，你要先踏踏實實做好現在的工作。因為就他提的問題來看，應該是剛入行不久或者是在校學生。
專心做技術的，都想做架構師。但架構師並不是說技術做時間長了可以轉的。隨着你的知識深度和廣度的增加，在工作中會扮演更重要的角色，承擔更大的責任，最終自然而然就會接觸到架構設計的工作。
而架構師的主要工作，其實是利用架構設計知識以及豐富的工作經驗，在設計架構時，結合實際情況，在不同的選項中做出取捨。
架構設計的真正目的？
為什麼要進行架構設計？因為架構設計很重要？可是為什麼重要呢？似乎說不清楚。
因為可以提升開發效率嗎？也不一定，因為只有簡單的設計才會使開發效率更高。而架構設計出於多方面考慮，不得已會引入一些複雜度，因此架構設計並不一定能提升開發效率。
是為了大多數口中的“高可用”、“高性能”、“可擴展”嗎？其實也不是。我們的系統可能並不一定需要這些。
那架構設計的真正目的是什麼呢？我認為架構設計的真正目的是與系統複雜度做鬥爭。
系統複雜度的來源有：高性能、高可用、可擴展性、低成本、安全、規模。
前面我們聊到有些系統可能不需要高可用、高性能。有些同學可能不理解，這些難道不是軟件開發最基本的要求嗎？這樣的說法是存在一定偏差的。我們舉一個簡單的例子說明一下。
如果讓你為一所學校設計一個學生信息管理系統。針對上述幾個複雜度的來源，你會做出怎樣的取捨？我們來逐條分析一下。
首先是高性能，學校的學生最多也就幾萬人，而且平時也不可能幾萬人同時用系統。因此我們並不需要考慮高性能。數據的CRUD直接用關係型數據庫就足夠了。
然後是高可用，對於學生系統而言，即使宕機幾個小時，影響也不會太大。不過數據的可靠性還是要保證的，如果大量數據丟失而又沒有備份的話，數據修復將會是一項繁重的工作。所以這裏需要做一些數據高可靠的設計。
接下來是可擴展性，學生管理系統一般比較穩定，不會出現需要擴展的情況。因此我們也不太需要考慮可擴展性。
至此，我們在設計系統時習慣考慮的高可用、高性能和可擴展，在這個系統中都不需要過多關注了。我們再來看看剩下的幾個複雜度來源。
關於低成本，由於我們並不需要高可用和高性能的設計，所以幾台服務器的成本對於學校來說也不足為慮。
安全性而言，學生信息需要一定的安全保證，但也不必做到金融級安全。所以只需要做好數據庫權限管理，登錄密碼管理就足夠了。
最後是系統規模，學生管理系統往往不會很複雜。也不會迭代出許多功能。因此規模是比較固定且比較小的，不會帶來很多的複雜度。
從我們的分析中可以看出，學生管理系統是一個並不複雜的系統，我們真正需要着重考慮的就只有數據高可靠和數據安全兩方面。面對複雜的系統，我們也應該按照這個步驟來思考並設計出合理的架構。在合理的情況下，盡量減少系統的複雜度。
架構設計原則
前面我們提到，架構師的工作其實就是在多種選項中做出合理的取捨，取捨沒有對錯之分，只有是否合適一說。為了更好的做出選擇，架構設計應該遵循三個原則：合適原則、簡單原則、演化原則。下面我來一一介紹這三個原則。
合適原則
我們一直在說，架構設計中架構師要做出取捨，選擇合適的架構。之所以一直強調合適，是因為我們在架構設計過程中需要結合實際情況來考慮。
那麼脫離實際情況的設計通常是怎樣發生的呢？不知道大家在開發時有沒有遇到過這樣的需求：“我們決定做一個電商網站，就按照淘寶做一個一模一樣的吧。“這時作為開發的你一定是黑人問號臉，心裏也會萬馬奔騰。
在架構設計時也是一樣，最忌諱的就是不顧實際情況，盲目的使用業界最優的架構設計。有同學可能不太理解，使用最優設計有什麼錯呢？
這裏我們所說的實際情況就是你的業務。試想如果你的業務剛剛起步，QPS剛過百，這時，你設計的架構是能支持1000QPS還是3000QPS對於系統來說沒什麼區別。但對於開發成本來說就提升了不止3倍。而對於這樣的業務體量來說，開發團隊一般只有十幾人或幾十人這樣的規模。要讓這樣的團隊來開發的話，大概率是無法完成的。
演化原則
聊完了合適原則，我們再來聊一聊演化原則。就像北京的城市規劃一樣，它一定是先有二環，慢慢向外擴建，才逐漸有了三四五六環。而我們現在所使用的大多數軟件，也都是經過了許多版本的迭代才有了現在的功能。
對於一名合格的架構師來說，我們首先要遵循合適原則，然後再逐步演化。切不可想着一步到位，從而引起過度設計。當業務發展到一定階段時，我們不可避免的會需要對架構進行擴展、重構甚至重寫。在這一過程中，我們應該保留下好的設計，對不好的設計進行完善。就像淘寶的架構一樣，它是經歷了多次“雙十一”之後，才有了現在這樣能支撐每天上千億成交額的架構。
因此，我們在設計架構時要遵循的第二個原則就是循序漸進的演化原則，而不是追求一步到位。
簡單原則
最後再來說簡單原則。前面我們也說了，架構設計其實是在和系統的複雜度做鬥爭。為什麼要有簡單原則？我認為原因主要有兩點。
第一，複雜的架構開發成本更高。在開發資源有限的情況下，如果我們的架構設計很複雜，勢必會提升開發成本。而對於當今飛速發展的市場來說，時間就是生命。如果你設計的架構開發周期非常長，那麼公司也許就會放棄這個項目，那麼架構也就沒有存在的意義了。
第二，複雜的架構往往會帶來更多的故障。舉個栗子，電動牙刷和普通牙刷相比，壞的概率一定會高一點，電動牙刷可能出現刷頭磨損，電路問題，充電故障等等，而普通牙刷只會出現刷頭磨損的情況。也就是說，系統的組件越多，系統出現故障的概率也就越大。在此基礎上還有一個問題就是，一旦出了故障，定位問題的速度而言，簡單系統相較於複雜系統也有着很大的優勢。
至此，架構設計的三個原則我們都已經聊完了。細心的同學可能注意到了，我在詳細介紹時的順序和最開始提到的順序並不一致。這不是我不注意細節。而是我在詳細介紹時，對這三個原則的重要程度排了一個順序。這也是作為架構師的一種取捨，當三種原則無法同時滿足時，應該以哪個為重？這裏我的答案是合適>演化>簡單。
關於架構設計，我已經有了一個大體的認識，不知道在讀完本文以後你是否也有同樣的感覺。如果有任何困惑，歡迎和我一起討論交流。
最後，架構師是需要有很深的技術積累的，而我在這方面做得還不夠。所以後面還是要以技術積累為主，同時也會嘗試將架構設計的知識引入到日常工作中。後續有什麼新的體會我會繼續和大家分享。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能
※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享
※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選
※評比南投搬家公司費用收費行情懶人包大公開