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

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

　　合適原則

　　合適原則宣言：“合適優(yōu)于業(yè)界領先”。

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

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

簡單原則

　　簡單原則宣言：“簡單優(yōu)于復雜”。

軟件架構設計是一門技術活。所謂技術活，從歷史上看，無論是瑞士的鐘表，還是瓦特的蒸汽機;無論是萊特兄弟發(fā)明的飛機，還是摩托羅拉發(fā)明的手機，無一不是越來越精細、越來越復雜。因此當我們進行架構設計時，會自然而然地想把架構做精美、做復雜，這樣才能體現(xiàn)我們的技術實力，也才能夠?qū)⒓軜嬜龀梢患囆g品。

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

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

　　演化原則

　　演化原則宣言：“演化優(yōu)于一步到位”。

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

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