成為一名架構師是每個程序員的夢想，但這并不意味著如果您做得好，就能成為一名架構師。 好的程序員和架構師之間存在的差距是非常明顯的，這個差距是“不確定性”。對于編程，基本上沒有不確定性。而就架構設計而言，它本質是不確定的，對于同一個系統，公司A和公司B制作的體系結構可能會非常不同，但最終它們都可以正常工作。 對于相同的解決方案，設計者A認為應該這樣做，設計師B認為應該做到這一點，這似乎是有道理的。與編程相比，架構設計沒有像編程語言那樣的語法來約束，更多的時候是面對多種可能性時進行選擇。

在充分了解眾多的互聯網公司架構設計后，會發現有幾個共性的原則隱含其中，這就是：合適原則、簡單原則、演化原則，架構設計時遵循這幾個原則，有助于做出最好的選擇。

　　合適原則

　　合適原則宣言：“合適優于業界領先”。

優秀的技術人員都有很強的技術情結，當他們做方案或者架構時，總想不斷地挑戰自己，想達到甚至優于業界領先水平是其中一個典型表現，因為這樣才能夠展現自己的優秀，才能在年終KPI績效總結里面驕傲地寫上“設計了XX方案，達到了和Google相同的技術水平”“XX方案的性能測試結果大大優于阿里集團的YY方案”。

但現實是，大部分這樣想和這樣做的架構，最后可能都以失敗告終!我在互聯網行業見過“億級用戶平臺”的失敗案例，2011年的時候，某個幾個人規模的業務團隊，雄心勃勃的提出要做一個和騰訊QQ(那時候微信還沒起來)一拼高下的“億級用戶平臺”，最后結果當然是不出所料的失敗了。

簡單原則

　　簡單原則宣言：“簡單優于復雜”。

軟件架構設計是一門技術活。所謂技術活，從歷史上看，無論是瑞士的鐘表，還是瓦特的蒸汽機;無論是萊特兄弟發明的飛機，還是摩托羅拉發明的手機，無一不是越來越精細、越來越復雜。因此當我們進行架構設計時，會自然而然地想把架構做精美、做復雜，這樣才能體現我們的技術實力，也才能夠將架構做成一件藝術品。

由于軟件架構和建筑架構表面上的相似性，我們也會潛意識地將對建筑的審美觀點移植到軟件架構上面。我們驚嘆于長城的宏偉、泰姬陵的精美、悉尼歌劇院的藝術感、迪拜帆船酒店的豪華感，因此，對于我們自己親手打造的軟件架構，我們也希望它宏偉、精美、藝術、豪華……總之就是不能寒酸、不能簡單。

團隊的壓力有時也會有意無意地促進我們走向復雜的方向，因為大部分人在評價一個方案水平高低的時候，復雜性是其中一個重要的參考指標。例如設計一個主備方案，如果你用心跳來實現，可能大家都認為這太簡單了。但如果你引入ZooKeeper來做主備決策，可能很多人會認為這個方案更加“高大上”一些，畢竟ZooKeeper使用的是ZAB協議，而ZAB協議本身就很復雜。其實，真正理解ZAB協議的人很少(我也不懂)，但并不妨礙我們都知道ZAB協議很優秀。

　　演化原則

　　演化原則宣言：“演化優于一步到位”。

軟件架構從字面意思理解和建筑結構非常類似，事實上“架構”這個詞就是建筑領域的專業名詞，維基百科對“軟件架構”的定義中有一段話描述了這種相似性：從和目的、主題、材料和結構的聯系上來說，軟件架構可以和建筑物的架構相比擬。例如，軟件架構描述的是一個軟件系統的結構，包括各個模塊，以及這些模塊的關系;建筑架構描述的是一幢建筑的結構，包括各個部件，以及這些部件如何有機地組成成一幢完美的建筑。然而，字面意思上的相似性卻掩蓋了一個本質上的差異：建筑一旦完成(甚至一旦開建)就不可再變，而軟件卻需要根據業務的發展不斷地變化。　

通過上述關于架構設計三原則的介紹，相信您對架構設計有了進一步的理解吧，想了解更多關于架構設計的信息，請繼續關注中培偉業。