敲開通往架構師的門

最近學習了一些關於架構設計的知識想分享給你們。俗話說得好，不想當架構師的程序員不是好廚子。那麼如何成爲一名架構師呢？接下來就聊一聊個人一些想法。

什麼是架構師

以前有同窗問我，作了幾年技術，應該轉管理仍是轉架構師？對於這位同窗，我給他的答案是，你要先踏踏實實作好如今的工做。由於就他提的問題來看，應該是剛入行不久或者是在校學生。

專心作技術的，都想作架構師。但架構師並非說技術作時間長了能夠轉的。隨着你的知識深度和廣度的增長，在工做中會扮演更重要的角色，承擔更大的責任，最終天然而然就會接觸到架構設計的工做。

而架構師的主要工做，實際上是利用架構設計知識以及豐富的工做經驗，在設計架構時，結合實際狀況，在不一樣的選項中作出取捨。

架構設計的真正目的？

爲何要進行架構設計？由於架構設計很重要？但是爲何重要呢？彷佛說不清楚。

由於能夠提高開發效率嗎？也不必定，由於只有簡單的設計纔會使開發效率更高。而架構設計出於多方面考慮，不得已會引入一些複雜度，所以架構設計並不必定能提高開發效率。

是爲了大多數口中的「高可用」、「高性能」、「可擴展」嗎？其實也不是。咱們的系統可能並不必定須要這些。

那架構設計的真正目的是什麼呢？我認爲架構設計的真正目的是與系統複雜度作鬥爭。

系統複雜度的來源有：高性能、高可用、可擴展性、低成本、安全、規模。

前面咱們聊到有些系統可能不須要高可用、高性能。有些同窗可能不理解，這些難道不是軟件開發最基本的要求嗎？這樣的說法是存在必定誤差的。咱們舉一個簡單的例子說明一下。

若是讓你爲一所學校設計一個學生信息管理系統。針對上述幾個複雜度的來源，你會作出怎樣的取捨？咱們來逐條分析一下。

首先是高性能，學校的學生最多也就幾萬人，並且平時也不可能幾萬人同時用系統。所以咱們並不須要考慮高性能。數據的CRUD直接用關係型數據庫就足夠了。

而後是高可用，對於學生系統而言，即便宕機幾個小時，影響也不會太大。不過數據的可靠性仍是要保證的，若是大量數據丟失而又沒有備份的話，數據修復將會是一項繁重的工做。因此這裏須要作一些數據高可靠的設計。

接下來是可擴展性，學生管理系統通常比較穩定，不會出現須要擴展的狀況。所以咱們也不太須要考慮可擴展性。

至此，咱們在設計系統時習慣考慮的高可用、高性能和可擴展，在這個系統中都不須要過多關注了。咱們再來看看剩下的幾個複雜度來源。

關於低成本，因爲咱們並不須要高可用和高性能的設計，因此幾臺服務器的成本對於學校來講也不足爲慮。

安全性而言，學生信息須要必定的安全保證，但也沒必要作到金融級安全。因此只須要作好數據庫權限管理，登陸密碼管理就足夠了。

最後是系統規模，學生管理系統每每不會很複雜。也不會迭代出許多功能。所以規模是比較固定且比較小的，不會帶來不少的複雜度。

從咱們的分析中能夠看出，學生管理系統是一個並不複雜的系統，咱們真正須要着重考慮的就只有數據高可靠和數據安全兩方面。面對複雜的系統，咱們也應該按照這個步驟來思考並設計出合理的架構。在合理的狀況下，儘可能減小系統的複雜度。

架構設計原則

前面咱們提到，架構師的工做其實就是在多種選項中作出合理的取捨，取捨沒有對錯之分，只有是否合適一說。爲了更好的作出選擇，架構設計應該遵循三個原則：合適原則、簡單原則、演化原則。下面我來一一介紹這三個原則。

合適原則

咱們一直在說，架構設計中架構師要作出取捨，選擇合適的架構。之因此一直強調合適，是由於咱們在架構設計過程當中須要結合實際狀況來考慮。

那麼脫離實際狀況的設計一般是怎樣發生的呢？不知道你們在開發時有沒有遇到過這樣的需求：「咱們決定作一個電商網站，就按照淘寶作一個如出一轍的吧。「這時做爲開發的你必定是黑人問號臉，內心也會萬馬奔騰。

在架構設計時也是同樣，最忌諱的就是不顧實際狀況，盲目的使用業界最優的架構設計。有同窗可能不太理解，使用最優設計有什麼錯呢？

這裏咱們所說的實際狀況就是你的業務。試想若是你的業務剛剛起步，QPS剛過百，這時，你設計的架構是能支持1000QPS仍是3000QPS對於系統來講沒什麼區別。但對於開發成原本說就提高了不止3倍。而對於這樣的業務體量來講，開發團隊通常只有十幾人或幾十人這樣的規模。要讓這樣的團隊來開發的話，大機率是沒法完成的。

演化原則

聊完了合適原則，咱們再來聊一聊演化原則。就像北京的城市規劃同樣，它必定是先有二環，慢慢向外擴建，才逐漸有了三四五六環。而咱們如今所使用的大多數軟件，也都是通過了許多版本的迭代纔有瞭如今的功能。

對於一名合格的架構師來講，咱們首先要遵循合適原則，而後再逐步演化。切不可想着一步到位，從而引發過分設計。當業務發展到必定階段時，咱們不可避免的會須要對架構進行擴展、重構甚至重寫。在這一過程當中，咱們應該保留下好的設計，對很差的設計進行完善。就像淘寶的架構同樣，它是經歷了屢次「雙十一」以後，纔有瞭如今這樣能支撐天天上千億成交額的架構。

所以，咱們在設計架構時要遵循的第二個原則就是按部就班的演化原則，而不是追求一步到位。

簡單原則

最後再來講簡單原則。前面咱們也說了，架構設計實際上是在和系統的複雜度作鬥爭。爲何要有簡單原則？我認爲緣由主要有兩點。

第一，複雜的架構開發成本更高。在開發資源有限的狀況下，若是咱們的架構設計很複雜，勢必會提高開發成本。而對於當今飛速發展的市場來講，時間就是生命。若是你設計的架構開發週期很是長，那麼公司也許就會放棄這個項目，那麼架構也就沒有存在的意義了。

第二，複雜的架構每每會帶來更多的故障。舉個栗子，電動牙刷和普通牙刷相比，壞的機率必定會高一點，電動牙刷可能出現刷頭磨損，電路問題，充電故障等等，而普通牙刷只會出現刷頭磨損的狀況。也就是說，系統的組件越多，系統出現故障的機率也就越大。在此基礎上還有一個問題就是，一旦出了故障，定位問題的速度而言，簡單系統相較於複雜系統也有着很大的優點。

至此，架構設計的三個原則咱們都已經聊完了。細心的同窗可能注意到了，我在詳細介紹時的順序和最開始提到的順序並不一致。這不是我不注意細節。而是我在詳細介紹時，對這三個原則的重要程度排了一個順序。這也是做爲架構師的一種取捨，當三種原則沒法同時知足時，應該以哪一個爲重？這裏個人答案是合適>演化>簡單。

關於架構設計，我已經有了一個大致的認識，不知道在讀完本文之後你是否也有一樣的感受。若是有任何困惑，歡迎和我一塊兒討論交流。

最後，架構師是須要有很深的技術積累的，而我在這方面作得還不夠。因此後面仍是要以技術積累爲主，同時也會嘗試將架構設計的知識引入到平常工做中。後續有什麼新的體會我會繼續和你們分享。