一、架構的作用

可能對于很多的公司，其實架構本身的重要性并不大。大家一定明白這回事，架構在實際的開發，在大多數的場景下其實用處并沒有書籍和資料中講的那樣重要，甚至是可有可無。這樣講是不有些可笑？是不是覺得挺意外的？但這就是事實。大家可以看看網上對架構師的一些抨擊就明白了。那么為什么會這樣呢？有以下幾個原因：

1. 大多數的公司和和大多數的項目都規模較小，架構的優勢無法體現或者說體現不明顯。這就導致架構的意義無法被大家重視。一個只有幾千行代碼的小程序，大多數情況下，架構能有多大的優勢？
2. 現實的工期太短。往往很多項目不光規模小，開發時間還特別緊，都不愿意甚至不安排架構設計
3. 開源的依賴。很多公司，特別是中小公司，往往習慣于找個開源的項目，在上面改改，然后就推出了。開源的架構就是項目的架構（沒毛病）
4. PPT架構師的誤導。在一些公司，特別是大廠中，存在著不少的PPT架構師，他們的主要作用就是把各種高大上的技術和架構以及思想雜合（而不是有機的融合），搞一個看上去很炫但實際沒啥用的架構。它們的目的不是做設計，是為了做宣傳
   那架構到底有沒有用呢？當然有用，而且非常大。項目規模越大，軟件越是復雜，架構越能體現它的優秀之處。不過，不能因循守舊，僵化應用從而形成本本主義和教條主義。要因地制宜，實事求是來進行架構的選型和設計。

二、架構的選型

假如面臨一個項目由自己來確定一個架構，如果這是第一次自主進行架構設計，那么第一件事，就是在需求確定的情況下，如何進行架構的選型。正如上面所分析的，要因地制宜，實事求是的進行選擇。這話說得，正確而沒啥用。那就說一點有用的，來解釋下這句話。

1. 根據項目的大小來選擇
   這個最容易選擇，如果一個規模較小的程序，比如幾千行代碼或功能很少的程序。架構的意義一般來說不大。怎么簡單怎么來，怎么方便怎么干。
2. 要根據需求的特點來選擇
   這個很容易理解，以一個網站為例，并發是多少？數據量有多大？數據讀多還是寫多或者都多等等，從而確定相關的架構選型。舉一個簡單的例子，公司只是做一個展示形象的網站，那基本就可以不考慮架構，做得漂亮一些就可以了。如果數據量很在并且讀多寫少，就可以使用緩存架構，使用Redis或其它內存型數據庫。
3. 根據公司的開發人員的情況來選擇
   這個就是根據開發人員的現在技術能力和水平和選型，比如都是菜鳥，如無必要就不必上一些微服務之類的復雜的架構。另外使用消息架構時，公司的開發人員更熟悉哪個就用個。最典型的就是網絡開發，是使用同步還是異步架構？同步簡單但異步對開發人員能力要求高。
4. 根據適當的擴展預期來選擇
   公司的業務在未來兩到三年，會有一個什么樣的發展，公司的發展方向是什么？就可以適當的選用一些容易擴展的架構來實現設計。比如公司是做軟硬件一起的項目，那么軟件就需要把未來幾年可能的公司的相關的硬件都要預留一些擴展，比如使用工廠+庫的架構設計。
5. 根據項目的總成本確定
   比如公司的可投入的人力成本和時間成本以及相關的軟硬件成本等。舉個例子，公司開發人員挺多，技術水平也高，但公司只給這個項目一個人，時間還緊，錢也少。就得考慮使用簡單的架構先完成功能。然后有時間再進行重構甚至重寫。

但實際情況是，往往一個項目不是上面一種條件確定的，它一定是全部或幾種共同來確定架構的選型。同時，這其中可能每個條件的權重還有所不同，甚至可能隨著時間這些權重還是變化，這就需要架構師來動態進行調整了。

三、選型的原則和驗證

在上面分析了很多架構選型的方法，那么如何應用他們呢？有以下幾個原則，當然這個原則是個人推薦，不是書籍資料上的公認的，算是私有原則：
1、如果架構選型可大可小，就選小
比如開發一個網站，從單體架構到垂直架構到分布式到微服務等等，選擇的話，在條件允許的情況下，越簡單越好。不要問為什么。
2、如果架構選型可保守可適度可激進，盡可能選擇保守。
這里說的是實際的項目而不是一些實驗性質的或半實驗性質的。說白了就是能簡單則簡單，不要自己給自己找麻煩。等多做幾次架構設計就都明白了
3、如果對未來擴展模楞兩可，盡量不選擴展型架構
這種事情，不多說，明白的都明白，不明白的做幾回就明白了。說句真心的，大概率是用不上的
4、如果可控范圍內，設計者想選用新架構新技術就用
老人常說：“誰拿鋤誰定苗”，想怎么舒服就怎么來
5、如果多種選擇可選擇，哪個方便哪個簡單選哪個
不要自己難為自己，也不要難為手下兄弟們
當然，這些私有原則不能拿到臺面上，但實際是很有用處的，至于對錯，見仁見智吧。

最后，如何能夠認為選型是正確的呢？其實就是項目完成的復盤結果，如果基本達到項目的目的，選型就算成功了。對，基本達到項目要求，或者說達到項目最低要求就算成功了。很多項目，包括大公司也一樣，在整個開發過程，它們的架構會有一個不斷調整的過程。所以，如一個架構基本能堅持到最后并達到了基本的需求，就算成功了。

四、總結

越是抽象，越是靈活。所以做為架構的選型和調整，目的都只有一個，服務于最終的項目成果。架構選擇既要靈活又要符合實際情況，如果能找一個整體的平衡點順利的實現架構目標，那么這個架構就是一個不錯的架構。