成為架構(gòu)師是每個(gè)程序員的夢(mèng)想温技，但并不意味著把編程做好就能夠自然而然地成為一個(gè)架構(gòu)師，優(yōu)秀程序員和架構(gòu)師之間還有一個(gè)明顯的鴻溝需要跨越套才，這個(gè)鴻溝就是“不確定性”携兵。

對(duì)于編程來(lái)說(shuō)静檬，本質(zhì)上是不能存在不確定的稻励，對(duì)于同樣一段代碼荒椭，不管是誰(shuí)寫(xiě)的唐片，不管什么時(shí)候執(zhí)行卢未，執(zhí)行的結(jié)果應(yīng)該都是確定的（注意：“確定的”并不等于“正確的”肪凛，有 bug 也是確定的）。而對(duì)于架構(gòu)設(shè)計(jì)來(lái)說(shuō)辽社，本質(zhì)上是不確定的伟墙，同樣的一個(gè)系統(tǒng)，A 公司和 B 公司做出來(lái)的架構(gòu)可能差異很大滴铅，但最后都能正常運(yùn)轉(zhuǎn)戳葵；同樣一個(gè)方案，A 設(shè)計(jì)師認(rèn)為應(yīng)該這樣做汉匙，B 設(shè)計(jì)師認(rèn)為應(yīng)該那樣做拱烁，看起來(lái)好像都有道理……相比編程來(lái)說(shuō)，架構(gòu)設(shè)計(jì)并沒(méi)有像編程語(yǔ)言那樣的語(yǔ)法來(lái)進(jìn)行約束噩翠，更多的時(shí)候是面對(duì)多種可能性時(shí)進(jìn)行選擇戏自。

可是一旦涉及“選擇”，就很容易讓架構(gòu)師陷入兩難的境地伤锚，例如：

是要選擇業(yè)界最先進(jìn)的技術(shù)擅笔，還是選擇團(tuán)隊(duì)目前最熟悉的技術(shù)？如果選了最先進(jìn)的技術(shù)后出了問(wèn)題怎么辦？如果選了目前最熟悉的技術(shù)猛们，后續(xù)技術(shù)演進(jìn)怎么辦念脯？

是要選擇 Google 的 Angular 的方案來(lái)做，還是選擇 Facebook 的 React 來(lái)做弯淘？Angular 看起來(lái)更強(qiáng)大绿店，但 React 看起來(lái)更靈活？

是要選 MySQL 還是 MongoDB庐橙？團(tuán)隊(duì)對(duì) MySQL 很熟悉惯吕，但是 MongoDB 更加適合業(yè)務(wù)場(chǎng)景？

淘寶的電商網(wǎng)站架構(gòu)很完善怕午，我們新做一個(gè)電商網(wǎng)站废登，是否簡(jiǎn)單地照搬淘寶就可以了？

還有很多類似的問(wèn)題和困惑郁惜，關(guān)鍵原因在于架構(gòu)設(shè)計(jì)領(lǐng)域并沒(méi)有一套通用的規(guī)范來(lái)指導(dǎo)架構(gòu)師進(jìn)行架構(gòu)設(shè)計(jì)堡距，更多是依賴架構(gòu)師的經(jīng)驗(yàn)和直覺(jué)，因此架構(gòu)設(shè)計(jì)有時(shí)候也會(huì)被看作一項(xiàng)比較神秘的工作兆蕉。

業(yè)務(wù)千變?nèi)f化羽戒，技術(shù)層出不窮，設(shè)計(jì)理念也是百花齊放虎韵，看起來(lái)似乎很難有一套通用的規(guī)范來(lái)適用所有的架構(gòu)設(shè)計(jì)場(chǎng)景易稠。但是在研究了架構(gòu)設(shè)計(jì)的發(fā)展歷史、多個(gè)公司的架構(gòu)發(fā)展過(guò)程（QQ包蓝、淘寶驶社、Facebook 等）、眾多的互聯(lián)網(wǎng)公司架構(gòu)設(shè)計(jì)后测萎，發(fā)現(xiàn)有幾個(gè)共性的原則隱含其中亡电，這就是：合適原則、簡(jiǎn)單原則硅瞧、演化原則份乒，架構(gòu)設(shè)計(jì)時(shí)遵循這幾個(gè)原則，有助于你做出最好的選擇腕唧。

合適原則

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

優(yōu)秀的技術(shù)人員都有很強(qiáng)的技術(shù)情結(jié)，當(dāng)他們做方案或者架構(gòu)時(shí)枣接，總想不斷地挑戰(zhàn)自己颂暇，想達(dá)到甚至優(yōu)于業(yè)界領(lǐng)先水平是其中一個(gè)典型表現(xiàn)，因?yàn)檫@樣才能夠展現(xiàn)自己的優(yōu)秀月腋，才能在年終 KPI 績(jī)效總結(jié)里面驕傲地寫(xiě)上“設(shè)計(jì)了 XX 方案蟀架，達(dá)到了和 Google 相同的技術(shù)水平”“XX 方案的性能測(cè)試結(jié)果大大優(yōu)于阿里集團(tuán)的 YY 方案”。

但現(xiàn)實(shí)是榆骚，大部分這樣想和這樣做的架構(gòu)片拍，最后可能都以失敗告終！曾在互聯(lián)網(wǎng)行業(yè)見(jiàn)過(guò)“億級(jí)用戶平臺(tái)”的失敗案例妓肢，2011 年的時(shí)候捌省，某個(gè)幾個(gè)人規(guī)模的業(yè)務(wù)團(tuán)隊(duì)，雄心勃勃的提出要做一個(gè)和騰訊 QQ（那時(shí)候微信還沒(méi)起來(lái)）一拼高下的“億級(jí)用戶平臺(tái)”碉钠，最后結(jié)果當(dāng)然是不出所料的失敗了纲缓。

【大數(shù)據(jù)開(kāi)發(fā)學(xué)習(xí)資料領(lǐng)取方式】：加入大數(shù)據(jù)技術(shù)學(xué)習(xí)交流扣扣群458345782，私信管理員即可免費(fèi)領(lǐng)取開(kāi)發(fā)工具以及入門(mén)學(xué)習(xí)資料

為什么會(huì)這樣呢喊废？

再好的夢(mèng)想祝高，也需要腳踏實(shí)地實(shí)現(xiàn)！這里的“腳踏實(shí)地”主要體現(xiàn)在下面幾個(gè)方面污筷。

1. 將軍難打無(wú)兵之仗

大公司的分工比較細(xì)工闺，一個(gè)小系統(tǒng)可能就是一個(gè)小組負(fù)責(zé)，比如說(shuō)某個(gè)通信大廠瓣蛀，做一個(gè) OM 管理系統(tǒng)就有十幾個(gè)人陆蟆，阿里的中間件團(tuán)隊(duì)有幾十個(gè)人，而大部分公司惋增，整個(gè)研發(fā)團(tuán)隊(duì)可能就 100 多人叠殷，某個(gè)業(yè)務(wù)團(tuán)隊(duì)可能就十幾個(gè)人。十幾個(gè)人的團(tuán)隊(duì)诈皿，想做幾十個(gè)人的團(tuán)隊(duì)的事情林束，而且還要做得更好，不能說(shuō)絕對(duì)不可能稽亏，但難度是可想而知的诊县。

沒(méi)那么多人，卻想干那么多活措左，是失敗的第一個(gè)主要原因依痊。

2. 羅馬不是一天建成的

業(yè)界領(lǐng)先的很多方案，其實(shí)并不是一堆天才某個(gè)時(shí)期靈機(jī)一動(dòng)怎披，然后加班加點(diǎn)就做出來(lái)的胸嘁，而是經(jīng)過(guò)幾年時(shí)間的發(fā)展才逐步完善和初具規(guī)模的。阿里中間件團(tuán)隊(duì) 2008 年成立，發(fā)展到現(xiàn)在已經(jīng)有十年了易桃。我們只知道他們抗住了多少次“雙 11”涉茧，做了多少優(yōu)秀的系統(tǒng)，但經(jīng)歷了什么樣的挑戰(zhàn)毫胜、踩了什么樣的坑书斜，只有他們自己知道！這些挑戰(zhàn)和踩坑酵使，都是架構(gòu)設(shè)計(jì)非常關(guān)鍵的促進(jìn)因素荐吉，單純靠拍腦袋或者頭腦風(fēng)暴，是不可能和真正實(shí)戰(zhàn)相比的口渔。

沒(méi)有那么多積累样屠，卻想一步登天，是失敗的第二個(gè)主要原因缺脉。

3. 冰山下面才是關(guān)鍵

可能有人認(rèn)為痪欲，業(yè)界領(lǐng)先的方案都是天才創(chuàng)造出來(lái)的，所以自己也要造一個(gè)業(yè)界領(lǐng)先的方案攻礼，以此來(lái)證明自己也是天才业踢。確實(shí)有這樣的天才，但更多的時(shí)候礁扮，業(yè)界領(lǐng)先的方案其實(shí)都是“逼”出來(lái)的陨亡！簡(jiǎn)單來(lái)說(shuō)，“業(yè)務(wù)”發(fā)展到一定階段深员，量變導(dǎo)致了質(zhì)變负蠕，出現(xiàn)了新的問(wèn)題，已有的方式已經(jīng)不能應(yīng)對(duì)這些問(wèn)題倦畅，需要用一種新的方案來(lái)解決遮糖，通過(guò)創(chuàng)新和嘗試，才有了業(yè)界領(lǐng)先的方案叠赐。GFS 為何在 Google 誕生欲账，而不是在 Microsoft 誕生？個(gè)人認(rèn)為 Google 有那么龐大的數(shù)據(jù)是一個(gè)主要的因素芭概，而不是因?yàn)?Google 的工程師比 Microsoft 的工程師更加聰明赛不。

沒(méi)有那么卓越的業(yè)務(wù)場(chǎng)景，卻幻想靈光一閃成為天才罢洲，是失敗的第三個(gè)主要原因踢故。

回到前面提到的“億級(jí)用戶平臺(tái)”失敗的例子，分析一下原因惹苗。沒(méi)有騰訊那么多的人（當(dāng)然錢差得更多）殿较，沒(méi)有 QQ 那樣海量用戶的積累，沒(méi)有 QQ 那樣的業(yè)務(wù)桩蓉，這個(gè)項(xiàng)目失敗其實(shí)是在一開(kāi)始就注定的淋纲。注意這里的失敗不是說(shuō)系統(tǒng)做不出來(lái)，而是系統(tǒng)沒(méi)有按照最初的目標(biāo)來(lái)實(shí)現(xiàn)院究，上面提到的 3 個(gè)失敗原因也全占了洽瞬。

所以本涕，真正優(yōu)秀的架構(gòu)都是在企業(yè)當(dāng)前人力、條件伙窃、業(yè)務(wù)等各種約束下設(shè)計(jì)出來(lái)的菩颖，能夠合理地將資源整合在一起并發(fā)揮出最大功效，并且能夠快速落地对供。這也是很多 BAT 出來(lái)的架構(gòu)師到了小公司或者創(chuàng)業(yè)團(tuán)隊(duì)反而做不出成績(jī)的原因位他，因?yàn)闆](méi)有了大公司的平臺(tái)氛濒、資源产场、積累，只是生搬硬套大公司的做法舞竿，失敗的概率非常高京景。

簡(jiǎn)單原則

簡(jiǎn)單原則宣言：“簡(jiǎn)單優(yōu)于復(fù)雜”。

軟件架構(gòu)設(shè)計(jì)是一門(mén)技術(shù)活骗奖。所謂技術(shù)活确徙，從歷史上看，無(wú)論是瑞士的鐘表执桌，還是瓦特的蒸汽機(jī)鄙皇；無(wú)論是萊特兄弟發(fā)明的飛機(jī)，還是摩托羅拉發(fā)明的手機(jī)仰挣，無(wú)一不是越來(lái)越精細(xì)伴逸、越來(lái)越復(fù)雜。因此當(dāng)我們進(jìn)行架構(gòu)設(shè)計(jì)時(shí)膘壶，會(huì)自然而然地想把架構(gòu)做精美错蝴、做復(fù)雜，這樣才能體現(xiàn)我們的技術(shù)實(shí)力颓芭，也才能夠?qū)⒓軜?gòu)做成一件藝術(shù)品顷锰。

由于軟件架構(gòu)和建筑架構(gòu)表面上的相似性，我們也會(huì)潛意識(shí)地將對(duì)建筑的審美觀點(diǎn)移植到軟件架構(gòu)上面亡问。我們驚嘆于長(zhǎng)城的宏偉官紫、泰姬陵的精美、悉尼歌劇院的藝術(shù)感州藕、迪拜帆船酒店的豪華感万矾，因此，對(duì)于我們自己親手打造的軟件架構(gòu)慎框，我們也希望它宏偉良狈、精美、藝術(shù)笨枯、豪華……總之就是不能寒酸薪丁、不能簡(jiǎn)單遇西。

團(tuán)隊(duì)的壓力有時(shí)也會(huì)有意無(wú)意地促進(jìn)我們走向復(fù)雜的方向，因?yàn)榇蟛糠秩嗽谠u(píng)價(jià)一個(gè)方案水平高低的時(shí)候严嗜，復(fù)雜性是其中一個(gè)重要的參考指標(biāo)粱檀。例如設(shè)計(jì)一個(gè)主備方案，如果你用心跳來(lái)實(shí)現(xiàn)漫玄，可能大家都認(rèn)為這太簡(jiǎn)單了茄蚯。但如果你引入 ZooKeeper 來(lái)做主備決策，可能很多人會(huì)認(rèn)為這個(gè)方案更加“高大上”一些睦优，畢竟 ZooKeeper 使用的是 ZAB 協(xié)議渗常，而 ZAB 協(xié)議本身就很復(fù)雜。其實(shí)汗盘，真正理解 ZAB 協(xié)議的人很少皱碘，但并不妨礙我們都知道 ZAB 協(xié)議很優(yōu)秀。

剛才說(shuō)的這些原因隐孽，會(huì)在潛意識(shí)層面促使初出茅廬的架構(gòu)師癌椿，不自覺(jué)地追求架構(gòu)的復(fù)雜性。然而菱阵，“復(fù)雜”在制造領(lǐng)域代表先進(jìn)踢俄，在建筑領(lǐng)域代表領(lǐng)先，但在軟件領(lǐng)域晴及，卻恰恰相反都办，代表的是“問(wèn)題”。

軟件領(lǐng)域的復(fù)雜性體現(xiàn)在兩個(gè)方面：

1. 結(jié)構(gòu)的復(fù)雜性

結(jié)構(gòu)復(fù)雜的系統(tǒng)幾乎毫無(wú)例外具備兩個(gè)特點(diǎn)：

組成復(fù)雜系統(tǒng)的組件數(shù)量更多抗俄；

同時(shí)這些組件之間的關(guān)系也更加復(fù)雜脆丁。

以圖形的方式來(lái)說(shuō)明復(fù)雜性：

2 個(gè)組件組成的系統(tǒng)：

3 個(gè)組件組成的系統(tǒng)：

4 個(gè)組件組成的系統(tǒng)：

5 個(gè)組件組成的系統(tǒng)：

結(jié)構(gòu)上的復(fù)雜性存在的第一個(gè)問(wèn)題是，組件越多动雹，就越有可能其中某個(gè)組件出現(xiàn)故障槽卫，從而導(dǎo)致系統(tǒng)故障。這個(gè)概率可以算出來(lái)胰蝠，假設(shè)組件的故障率是 10%（有 10% 的時(shí)間不可用）歼培，那么有 3 個(gè)組件的系統(tǒng)可用性是（1-10%）×（1-10%）×（1-10%）= 72.9%，有 5 個(gè)組件的系統(tǒng)可用性是（1-10%）×（1-10%）×（1-10%）×（1-10%）×（1-10%）=59%茸塞，兩者的可用性相差 13%躲庄。

結(jié)構(gòu)上的復(fù)雜性存在的第二個(gè)問(wèn)題是，某個(gè)組件改動(dòng)钾虐，會(huì)影響關(guān)聯(lián)的所有組件噪窘，這些被影響的組件同樣會(huì)繼續(xù)遞歸影響更多的組件。還以上面圖中 5 個(gè)組件組成的系統(tǒng)為例效扫，組件 A 修改或者異常時(shí)倔监，會(huì)影響組件 B/C/E直砂，D 又會(huì)影響 E。這個(gè)問(wèn)題會(huì)影響整個(gè)系統(tǒng)的開(kāi)發(fā)效率浩习，因?yàn)橐坏┳兏婕巴獠肯到y(tǒng)静暂，需要協(xié)調(diào)各方統(tǒng)一進(jìn)行方案評(píng)估、資源協(xié)調(diào)谱秽、上線配合洽蛀。

結(jié)構(gòu)上的復(fù)雜性存在的第三個(gè)問(wèn)題是，定位一個(gè)復(fù)雜系統(tǒng)中的問(wèn)題總是比簡(jiǎn)單系統(tǒng)更加困難疟赊。首先是組件多郊供，每個(gè)組件都有嫌疑，因此要逐一排查听绳；其次組件間的關(guān)系復(fù)雜颂碘，有可能表現(xiàn)故障的組件并不是真正問(wèn)題的根源异赫。

2. 邏輯的復(fù)雜性

意識(shí)到結(jié)構(gòu)的復(fù)雜性后椅挣，我們的第一反應(yīng)可能就是“降低組件數(shù)量”，畢竟組件數(shù)量越少塔拳，系統(tǒng)結(jié)構(gòu)越簡(jiǎn)鼠证。最簡(jiǎn)單的結(jié)構(gòu)當(dāng)然就是整個(gè)系統(tǒng)只有一個(gè)組件，即系統(tǒng)本身靠抑，所有的功能和邏輯都在這一個(gè)組件中實(shí)現(xiàn)量九。

不幸的是，這樣做是行不通的颂碧，原因在于除了結(jié)構(gòu)的復(fù)雜性荠列，還有邏輯的復(fù)雜性，即如果某個(gè)組件的邏輯太復(fù)雜载城，一樣會(huì)帶來(lái)各種問(wèn)題肌似。

邏輯復(fù)雜的組件，一個(gè)典型特征就是單個(gè)組件承擔(dān)了太多的功能诉瓦。以電商業(yè)務(wù)為例川队，常見(jiàn)的功能有：商品管理、商品搜索睬澡、商品展示固额、訂單管理、用戶管理煞聪、支付斗躏、發(fā)貨、客服……把這些功能全部在一個(gè)組件中實(shí)現(xiàn)昔脯，就是典型的邏輯復(fù)雜性啄糙。

邏輯復(fù)雜幾乎會(huì)導(dǎo)致軟件工程的每個(gè)環(huán)節(jié)都有問(wèn)題馋艺，假設(shè)現(xiàn)在淘寶將這些功能全部在單一的組件中實(shí)現(xiàn)，可以想象一下這個(gè)恐怖的場(chǎng)景：

系統(tǒng)會(huì)很龐大迈套，可能是上百萬(wàn)捐祠、上千萬(wàn)的代碼規(guī)模，“clone”一次代碼要 30 分鐘桑李。

幾十踱蛀、上百人維護(hù)這一套代碼，某個(gè)“菜鳥(niǎo)”不小心改了一行代碼贵白，導(dǎo)致整站崩潰率拒。

需求像雪片般飛來(lái)，為了應(yīng)對(duì)禁荒，開(kāi)幾十個(gè)代碼分支猬膨，然后各種分支合并、各種分支覆蓋呛伴。

產(chǎn)品勃痴、研發(fā)、測(cè)試热康、項(xiàng)目管理不停地開(kāi)會(huì)討論版本計(jì)劃沛申，協(xié)調(diào)資源，解決沖突姐军。

版本太多铁材，每天都要上線幾十個(gè)版本，系統(tǒng)每隔 1 個(gè)小時(shí)重啟一次奕锌。

線上運(yùn)行出現(xiàn)故障著觉，幾十個(gè)人撲上去定位和處理，一間小黑屋都裝不下所有人惊暴，整個(gè)辦公區(qū)鬧翻天饼丘。

……

不用多說(shuō)，肯定誰(shuí)都無(wú)法忍受這樣的場(chǎng)景缴守。

但是葬毫，為什么復(fù)雜的電路就意味更強(qiáng)大的功能，而復(fù)雜的架構(gòu)卻有很多問(wèn)題呢屡穗？根本原因在于電路一旦設(shè)計(jì)好后進(jìn)入生產(chǎn)贴捡，就不會(huì)再變，復(fù)雜性只是在設(shè)計(jì)時(shí)帶來(lái)影響村砂；而一個(gè)軟件系統(tǒng)在投入使用后烂斋，后續(xù)還有源源不斷的需求要實(shí)現(xiàn)，因此要不斷地修改系統(tǒng)，復(fù)雜性在整個(gè)系統(tǒng)生命周期中都有很大影響汛骂。

功能復(fù)雜的組件罕模，另外一個(gè)典型特征就是采用了復(fù)雜的算法。復(fù)雜算法導(dǎo)致的問(wèn)題主要是難以理解帘瞭，進(jìn)而導(dǎo)致難以實(shí)現(xiàn)淑掌、難以修改，并且出了問(wèn)題難以快速解決蝶念。

以 ZooKeeper 為例抛腕，ZooKeeper 本身的功能主要就是選舉，為了實(shí)現(xiàn)分布式下的選舉媒殉，采用了 ZAB 協(xié)議担敌，所以 ZooKeeper 功能雖然相對(duì)簡(jiǎn)單，但系統(tǒng)實(shí)現(xiàn)卻比較復(fù)雜廷蓉。相比之下全封，etcd 就要簡(jiǎn)單一些，因?yàn)?etcd 采用的是 Raft 算法桃犬，相比 ZAB 協(xié)議刹悴，Raft 算法更加容易理解，更加容易實(shí)現(xiàn)疫萤。

綜合前面的分析颂跨，我們可以看到敢伸，無(wú)論是結(jié)構(gòu)的復(fù)雜性扯饶，還是邏輯的復(fù)雜性，都會(huì)存在各種問(wèn)題池颈，所以架構(gòu)設(shè)計(jì)時(shí)如果簡(jiǎn)單的方案和復(fù)雜的方案都可以滿足需求尾序，最好選擇簡(jiǎn)單的方案∏椋《UNIX 編程藝術(shù)》總結(jié)的 KISS（Keep It Simple, Stupid!）原則一樣適應(yīng)于架構(gòu)設(shè)計(jì)每币。

演化原則

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

軟件架構(gòu)從字面意思理解和建筑結(jié)構(gòu)非常類似琢歇，事實(shí)上“架構(gòu)”這個(gè)詞就是建筑領(lǐng)域的專業(yè)名詞兰怠，維基百科對(duì)“軟件架構(gòu)”的定義中有一段話描述了這種相似性：

從和目的、主題李茫、材料和結(jié)構(gòu)的聯(lián)系上來(lái)說(shuō)揭保，軟件架構(gòu)可以和建筑物的架構(gòu)相比擬。

例如魄宏，軟件架構(gòu)描述的是一個(gè)軟件系統(tǒng)的結(jié)構(gòu)秸侣，包括各個(gè)模塊，以及這些模塊的關(guān)系；建筑架構(gòu)描述的是一幢建筑的結(jié)構(gòu)味榛，包括各個(gè)部件椭坚，以及這些部件如何有機(jī)地組成成一幢完美的建筑。

然而搏色，字面意思上的相似性卻掩蓋了一個(gè)本質(zhì)上的差異：建筑一旦完成（甚至一旦開(kāi)建）就不可再變善茎，而軟件卻需要根據(jù)業(yè)務(wù)的發(fā)展不斷地變化！

古埃及的吉薩大金字塔频轿，4000 多年前完成的巾表，到現(xiàn)在還是當(dāng)初的架構(gòu)。

中國(guó)的明長(zhǎng)城略吨，600 多年前完成的集币，現(xiàn)在保存下來(lái)的長(zhǎng)城還是當(dāng)年的結(jié)構(gòu)。

美國(guó)白宮翠忠，1800 年建成鞠苟，200 年來(lái)進(jìn)行了幾次擴(kuò)展，但整體結(jié)構(gòu)并無(wú)變化秽之，只是在旁邊的空地?cái)U(kuò)建或者改造內(nèi)部的布局当娱。

對(duì)比一下，我們來(lái)看看軟件架構(gòu)考榨。

Windows 系統(tǒng)的發(fā)展歷史：

如果對(duì)比 Windows 8 的架構(gòu)和 Windows 1.0 的架構(gòu)跨细，就會(huì)發(fā)現(xiàn)它們其實(shí)是兩個(gè)不同的系統(tǒng)了！

Android 的發(fā)展歷史：

同樣河质，Android 6.0 和 Android 1.6 的差異也很大冀惭。

對(duì)于建筑來(lái)說(shuō)，永恒是主題掀鹅；而對(duì)于軟件來(lái)說(shuō)散休，變化才是主題。軟件架構(gòu)需要根據(jù)業(yè)務(wù)的發(fā)展而不斷變化乐尊。設(shè)計(jì) Windows 和 Android 的人都是頂尖的天才戚丸，即便如此，他們也不可能在 1985 年設(shè)計(jì)出 Windows 8扔嵌，不可能在 2009 年設(shè)計(jì)出 Android 6.0限府。

如果沒(méi)有把握“軟件架構(gòu)需要根據(jù)業(yè)務(wù)發(fā)展不斷變化”這個(gè)本質(zhì)，在做架構(gòu)設(shè)計(jì)的時(shí)候就很容易陷入一個(gè)誤區(qū)：試圖一步到位設(shè)計(jì)一個(gè)軟件架構(gòu)痢缎，期望不管業(yè)務(wù)如何變化胁勺，架構(gòu)都穩(wěn)如磐石。

為了實(shí)現(xiàn)這樣的目標(biāo)牺弄，要么照搬業(yè)界大公司公開(kāi)發(fā)表的方案姻几；要么投入龐大的資源和時(shí)間來(lái)做各種各樣的預(yù)測(cè)宜狐、分析、設(shè)計(jì)蛇捌。無(wú)論哪種做法抚恒，后果都很明顯：投入巨大，落地遙遙無(wú)期络拌。更讓人沮喪的是俭驮，就算跌跌撞撞拼死拼活終于落地，卻發(fā)現(xiàn)很多預(yù)測(cè)和分析都是不靠譜的春贸。

考慮到軟件架構(gòu)需要根據(jù)業(yè)務(wù)發(fā)展不斷變化這個(gè)本質(zhì)特點(diǎn)混萝，軟件架構(gòu)設(shè)計(jì)其實(shí)更加類似于大自然“設(shè)計(jì)”一個(gè)生物，通過(guò)演化讓生物適應(yīng)環(huán)境萍恕，逐步變得更加強(qiáng)大：

首先逸嘀，生物要適應(yīng)當(dāng)時(shí)的環(huán)境。

其次允粤，生物需要不斷地繁殖崭倘，將有利的基因傳遞下去，將不利的基因剔除或者修復(fù)类垫。

第三司光，當(dāng)環(huán)境變化時(shí)，生物要能夠快速改變以適應(yīng)環(huán)境變化悉患；如果生物無(wú)法調(diào)整就被自然淘汰残家；新的生物會(huì)保留一部分原來(lái)被淘汰生物的基因。

軟件架構(gòu)設(shè)計(jì)同樣是類似的過(guò)程：

首先售躁，設(shè)計(jì)出來(lái)的架構(gòu)要滿足當(dāng)時(shí)的業(yè)務(wù)需要坞淮。

其次，架構(gòu)要不斷地在實(shí)際應(yīng)用過(guò)程中迭代迂求，保留優(yōu)秀的設(shè)計(jì)碾盐，修復(fù)有缺陷的設(shè)計(jì)，改正錯(cuò)誤的設(shè)計(jì)揩局，去掉無(wú)用的設(shè)計(jì)，使得架構(gòu)逐漸完善掀虎。

第三凌盯，當(dāng)業(yè)務(wù)發(fā)生變化時(shí)，架構(gòu)要擴(kuò)展烹玉、重構(gòu)驰怎，甚至重寫(xiě)；代碼也許會(huì)重寫(xiě)二打，但有價(jià)值的經(jīng)驗(yàn)县忌、教訓(xùn)、邏輯、設(shè)計(jì)等（類似生物體內(nèi)的基因）卻可以在新架構(gòu)中延續(xù)症杏。

架構(gòu)師在進(jìn)行架構(gòu)設(shè)計(jì)時(shí)需要牢記這個(gè)原則装获，時(shí)刻提醒自己不要貪大求全，或者盲目照搬大公司的做法厉颤。應(yīng)該認(rèn)真分析當(dāng)前業(yè)務(wù)的特點(diǎn)穴豫，明確業(yè)務(wù)面臨的主要問(wèn)題，設(shè)計(jì)合理的架構(gòu)逼友，快速落地以滿足業(yè)務(wù)需要精肃，然后在運(yùn)行過(guò)程中不斷完善架構(gòu)，不斷隨著業(yè)務(wù)演化架構(gòu)帜乞。

即使是大公司的團(tuán)隊(duì)司抱，在設(shè)計(jì)一個(gè)新系統(tǒng)的架構(gòu)時(shí)，也需要遵循演化的原則黎烈，而不應(yīng)該認(rèn)為團(tuán)隊(duì)人員多状植、資源多，不管什么系統(tǒng)上來(lái)就要一步到位怨喘，因?yàn)闃I(yè)務(wù)的發(fā)展和變化是很快的津畸，不管多牛的團(tuán)隊(duì)，也不可能完美預(yù)測(cè)所有的業(yè)務(wù)發(fā)展和變化路徑必怜。