阿里架構設計之初體驗，送給準備進階架構的朋友（我的總結）

1 基本概念和目的

架構設計的目的是爲了解決系統複雜度帶來的問題，並非要面面俱到，不須要每一個架構都具有高性能、高可用、高擴展等特色，而是要識別出實際業務實際狀況的複雜點，而後有有針對性地解決問題，即：有的放矢，而不是貪大求全。 在實際狀況中，不必定每一個系統都要作架構設計，須要結合實際狀況。有時候最簡單的設計開發效率反而是最高的，架構設計畢竟要投入時間和人力，這部分投入若是用來儘早編碼，項目也許會更快。

2 架構設計複雜度來源

高性能

高可用

可擴展性

低成本、安全、規模

3 架構設計三原則

合適原則

GFS爲什麼在Google誕生，而不是在Microsoft誕生，其中Google有那麼龐大的數據是一個主要因素，而不是由於Google的工程師比Microsoft的工程師更加聰明。

真正優秀的架構都是企業在當前人力、條件、業務等各方面約束條件下設計出來的，可以合理地將資源整合一塊兒併發揮出最大功效，而且能迅速落地。這也是不少BAT出來的架構師到了小公司或者創業團隊反而作不出成績的緣由，由於沒有大公司的平臺、資源、積累，只是生搬硬套大公司的作法，失敗的效率很是高。

簡單原則

不管是結構的複雜性仍是邏輯的複雜性，都會存在各類問題，因此架構設計時若是簡單方案和複雜的方案均可以知足需求，最好選擇簡單的方案。《UNIX編程藝術》總結的KISS（Keep It Simple,Stupid!）原則同樣適用於架構設計。

演化原則

對於軟件系統來講，變化纔是主題。軟件架構須要根據業務的發展而不斷變化。 若是沒有把握「軟件架構須要根據業務發展不斷變化」這個本質，在作架構設計的時候就很容易陷入一個誤區：試圖一步到位設計一個軟件架構，指望無論業務如何變化，架構都穩如磐石。

爲了實現這樣的目標，要麼照搬業界大公司公開發表的方案；要麼投入龐大的資源和時間來作各類各樣的預測、分析、設計。不管哪一種作法，後果都很明顯：投入巨大，落地遙遙無期。更讓人沮喪的是，就算跌跌撞撞拼死拼活終於落地，卻發現不少預測和分析都是不靠譜的。

實踐中，架構師要提醒本身不要貪大求全，遵循演化優於一步到位的原則，由於業務的發展和變化老是很快的，**不管多牛的團隊，都不可能完美預測全部的業務發展和變化路徑。實踐中能夠參考以下建議：

首先，設計出來的架構要知足當時的業務須要。

其次，架構要不斷地在實際應用過程當中迭代，保留優秀的設計，修復有缺陷的設計，改正錯誤的設計，去掉無用的設計，使得架構逐漸完善。

第三，當業務發生變化時，架構要擴展、重構，甚至重寫；代碼也許會重寫，但有價值的經驗、教訓、邏輯、設計等卻能夠在新架構中延續。

在這裏推薦一個學習架構的羣：617434785，進羣能夠免費獲取到架構學習資料，但願可以幫到如今想要進階架構，遇到職業瓶頸的朋友。

4 架構設計的流程