架構設計三原則

成為架構師，可以說是絕大多數開發者的夢想。但是這個過程並不是一件簡單的事情，如果簡單的話，意味著供過於求，就代表著不值錢了。在目前國內，架構師也算是一個比較吃香的職業。對於年齡較大的小夥伴們，他們的選擇通常有這麼幾個?

第一、繼續開發者之路，畢竟現在30多歲的資深工程師也不少(通常這些人，對於公司來說，業務非常熟練(某工程師對公司好幾個業務十分熟悉，不少項目其中的核心代碼是其編寫(另外也考慮到如果真正是新人來對接，時間成本或者其他方面的成本是比較高昂的)，同時也比較穩定(基本上都已經成家有了自己的小孩，跳槽的頻率相對小）;

第二、走向管理之路，管理之路，通常是要麼是項目經理，要麼是TeamLeader，大小公司對此有不同的定義，有的規模畢竟大的公司，可以細分為項目總監、項目經理及其CTO或架構師;

第三、轉向產品或者運營方面;

第四、去當教師(通常去培訓機構當講師);

第五、自主創業(不過不多，一般情況下，充當技術合伙人的比較多，因為當技術合伙人，僅僅只是負責技術方面的設計和管理，不必承擔金錢方面的風險);

第六、自由職業(一般自由職業，通常是接私活，前提是私活足夠多，一般這種自由職業者通常身邊會有幾個在職或者非在職朋友一起合作,畢竟人多力量大）；

第七、成為專職作家(畢竟對於程序員來說，能夠寫書，將自己多年對技術方面的掌控和理解等分享給廣大的小夥伴們也是一件非常幸福的事情);

第八、沒有辦法不得不轉行(技術不過硬、人脈又不好、業務方面積累不深或者是在該領域十多年過去了，仍然做著重複的事情，而今有比其價格更低的人來替換其);

這篇文章不是再講程序員的以後方向和怎麼走接下來的路。主要還是圍繞著架構設計三大原則。上面的話只不過是臨時突然有些想法，所以就說說了。

另外貼一下架構師的薪資(以北京一線城市為例):

用友公司:

聯想集團:

從中可以普遍看到架構師的薪資通常在20K以上。當然了，能拿到多高，取決你自身所能提供的價值。

文章偏題太多，下面進入正題。

問:架構設計三原則有哪些？

答:主要有合適原則、簡單原則、演化原則。

一、合適原則

優秀的技術人員都有很強的技術情結(包括我自己，雖然在技術方面不夠優秀還需要學習很多東西),當他們做方案或者架構時，總想不斷地挑戰自己，想達到甚至優於業界領先水平是其中的一個典型表現，因為這樣才能夠展現自己的優秀，才能在年終KPI績效總結裡面驕傲地寫，「我設計了某某方案，達到目前知名某公司的一樣效果甚至優於其」。

但現實是，大部分這樣想的和這樣做的架構，最後可能都以失敗而告終。

為什麼會這樣?原因有如下幾個方面?

首先再理想的設計，也需要考慮實際情況，我們可以叫做實事求是或腳踏實地。

(1)將軍難打無把握之仗；

在互聯網公司，一般情況是你有多少個人就表示你能做的多麼大，也許這個觀點你並不贊同，比如阿里為例，最早的阿里公司肯定沒有現在這麼多人，系統也沒有這麼大，起初都是從幾個人開始的。關於這段歷史，大家有興趣可以看看關於阿里方面的傳記或者馬雲先生的傳記。

(2)羅馬不是一天建成的;

這個不用多說，一看就明白，前面(1)也是如此。

(3)冰山之下才是關鍵;

可能有人認為，業界領先的方案都是天才創建出來的，所以自己也要造一個業界領先方案，以此證明自己也是天才。確實是有這樣的天才，但更多的時候，業界領先的方案，其實都是「逼」出來的。

比如以之前某公司的一個產品經理需求為例，APP的背景根據手機殼變色。這個需求並非是不能實現的。當然了，這個需求看起來有些操蛋。

簡單來說，「業務」的發展到一定階段，量變導致質變，出現新的問題，已有的方式已經不能應對這些問題，需要用一種新的方案來解決，通過創新和嘗試，才有了業界領先的方案。

比如有不少IT小夥伴們動輒就說分散式、大數據、微服務之類的，但是前提是當業務發展到一定階段時遇到瓶頸，現有的架構或方案不能滿足業務的擴展。

二、簡單原則

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

前面我在談談架構設計的目的 這篇文章中說過，架構設計的目的就是應對並解決軟體日益龐大複雜的問題。

關於軟體領域的複雜性主要體現在這麼幾個方面?

1.結構的複雜性

比如最初在單體應用上，所以的請求集中在一個項目上，後來從這個整體系統，分出幾個子系統來，於是每次提供服務，都需要關聯這幾個子系統以達到實現功能的目的。一個兩個還好，但是三個四個乃至十個二十個，會怎麼樣呢？我的回答是，你可以以HTTP請求為例，請求有的時候也會因為網路延遲或者請求攜帶參數的問題導致請求失敗，你試著想像，為實現某一個功能關聯幾個子系統(需求請求幾個子系統)，我相信你就懂了。

通過這個例子，我們可以發現結構上複雜導致的問題有很多，以下我列舉幾個常見的問題?

(1)組件越多,就越有可能其中某個組件出現問題（組件你可以理解為多個子系統）;

(2)某個組件改動，會影響關聯的所有組件(從某個角度看，你可以理解為耦合性比較強);

(3)定位一個複雜系統中的問題總是比簡單系統更加困難;

2.邏輯的複雜性

意識到結構的複雜性後，我們第一個想到的可能是降低耦合性，如何降低呢？可能引用設計模式來達到這個目的，也有可能是減少分出的子系統數量來達到這個目的。

但是最粗暴最簡單最實際的做法就是，就是不分出子系統(組件)，全部在一個系統上。

糟糕的是，這樣是行不通的，原因不僅僅是因為結構的複雜性，還有邏輯的複雜性，比如如果某個組件的邏輯太過複雜，一樣會帶來不少問題。

關於邏輯的複雜性，我想強調一點是，為什麼程序員經常加班，先不說代碼質量問題(畢竟如果不是公司有一定的規章制度約束你，讓你必須這麼做，有的時候，我們為了圖快，很少考慮代碼整體的簡潔(優雅)或有沒有更好的實現方案，一般就是拿起鍵盤立刻實現完成任務就OK，因為在大多數情況，我也是這麼做的，沒有比在短時間內儘快完成上面交代下來的任務更為重要，畢竟薪水和享受的待遇掌握在上面手裡)。有一點與代碼質量關係不是特別大，那就是業務的複雜度，過於複雜的業務，涉及好幾個系統，萬一改了這個沒有改好，就會影響其他的系統。

三、演化原則

其實軟體的變化就好比生物的進化，並不是一蹴而就的。它也有一個演變的過程。

以生物為例:

(1)首先，生物要適應環境;

(2)其次，生物需要不斷繁殖，將有利的基因傳遞下去，將不利的基因剔除出去;

(3)最後，當環境變化時，生物能夠快速的適應環境，如果不能適應自然就會淘汰(這也就是嚴復曾經說過的「物競天擇，適者生存」);

軟體架構設計同樣是類似的過程:

(1)首先，設計出來的架構要滿足當前的業務需求(畢竟公司盈利是首要目的,不然，哪有錢發工資或者享受公司的各種福利呢);

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

(3)最後，當業務發生變化時，架構要擴展、重構，甚至重寫;代碼也許需要重寫，但有價值的經驗、教訓、邏輯、設計等(類似生物的基因)卻可以在新架構中延續下去;

架構師在進行架構設計時需要牢記這個原則，時刻提醒自己不要貪大求全或者盲目照抄。應該認真分析當前業務的特點，明確業務所面臨的主要問題，設計合理的架構，快速落地以滿足業務需要，然後再運行過程中不斷完善架構，不斷隨著業務演化架構。

小結:

架構設計三原則已經談完了，希望給小夥伴們有所啟發。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！