IT架構(gòu)的構(gòu)建思路

1、 IT架構(gòu)的構(gòu)建思路目 錄 TOC o 1-3 h z u HYPERLINK l _Toc526847553 一、架構(gòu)的定義 PAGEREF _Toc526847553 h 3 HYPERLINK l _Toc526847554 二、架構(gòu)是做什么？ PAGEREF _Toc526847554 h 3 HYPERLINK l _Toc526847555 三、做架構(gòu)的最佳實踐 PAGEREF _Toc526847555 h 6 HYPERLINK l _Toc526847556 四、什么是好架構(gòu) PAGEREF _Toc526847556 h 9 HYPERLINK l _Toc52684755

2、7 五、如何成為架構(gòu)師 PAGEREF _Toc526847557 h 11 HYPERLINK l _Toc526847558 六、結(jié)語 PAGEREF _Toc526847558 h 11一、架構(gòu)的定義在軟件開發(fā)領(lǐng)域，自從架構(gòu)這個詞被廣泛傳播之后，產(chǎn)生的架構(gòu)模式也非常多，架構(gòu)關(guān)注點也在增加。但回到“道”的層面，架構(gòu)的定義或者說本質(zhì)還是：“架構(gòu)，又名軟件架構(gòu)，是有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)大型軟件系統(tǒng)各個方面的設(shè)計?！闭园俣劝倏贫?、架構(gòu)是做什么？很多做業(yè)務(wù)功能的增刪改查開發(fā)感受到無趣的小伙伴常把做架構(gòu)想象成一片樂土，沒有嘈雜的業(yè)務(wù)聲音干擾，可以專心做一番牛X的技術(shù)。會把架構(gòu)單

3、純的理解成，牛X的性能、牛X的TPS、高可用、支撐了多少PV等等。但是其實這些只是架構(gòu)很小的一部分，并不是全部。在互聯(lián)網(wǎng)時代之前都是C/S程序的天下，那個時候并沒有對性能等有像現(xiàn)在這樣的關(guān)注度，但是就已經(jīng)有架構(gòu)之說了。世上本無架構(gòu)，只是由于團隊越大越需要對整體的規(guī)則做約定，好讓大家往同一個方向發(fā)力，避免各自為戰(zhàn)，產(chǎn)生大量的內(nèi)耗，所以才逐漸形成了架構(gòu)。這條路的形成之由就是“世上本無路，只是因為走的人多了變成了路”。為什么說一個軟件架構(gòu)是很重要的呢？當我們的團隊人數(shù)只有2、3個人，甚至只有1個人單槍匹馬的情況下，可能架構(gòu)凸顯的作用并不是那么的明顯。但是如果團隊大了，相信下面的這些現(xiàn)象會比較常見：新

4、上一個系統(tǒng)，往往不是獨立存在的，一般都需要與現(xiàn)存的系統(tǒng)進行交互，而需要集成交互的地方可能還很多，那么哪些集成是本系統(tǒng)需要實現(xiàn)的？同時，一般會劃分為多個階段開發(fā)，怎樣界定系統(tǒng)的邊界呢？軟件系統(tǒng)是一個由多個模塊組成的整體。因此當上游開發(fā)與我們負責(zé)的模塊銜接老是出問題時，自己做再多的努力也無法扭轉(zhuǎn)上游模塊質(zhì)量差帶來的負面效果。（我想大家這時候肯定是抓狂的。）每次看到別人寫的代碼，老覺得自己來寫的話肯定不會這么寫，肯定比他寫的更好。（我們做技術(shù)的，自我感覺良好是個常態(tài)）在某些場景下，自己腦子里有多套方案來實現(xiàn)，但是對孰優(yōu)孰劣沒太大感覺，最終基本上就是拍腦袋選了一個。某塊代碼維護的次數(shù)多了，特別是中間由

5、多個人接手過后，代碼風(fēng)格各異，難以理解。相似的代碼在好幾個地方出現(xiàn)，特別是一些非業(yè)務(wù)性的代碼，比如日志處理等。再甚是在大型的分布式系統(tǒng)中，不同子程序使用了不同的同類型中間件，同樣導(dǎo)致維護成本大增。在2個相依賴項目邊界處的設(shè)計產(chǎn)生了分歧，并且站在各自的角度看都有道理。任何事物都是有兩面性的，并不是說有了上面的這些問題，我們通過架構(gòu)就要往另外一個極端去走。比如在大型的分布式系統(tǒng)中，不同子程序的確有必要在某些時刻選擇同類型的其它中間件。如Kafka和RabbitMQ雖都是MQ，但在特定的場景下能發(fā)揮的價值是無法相互替代的。所以我們做架構(gòu)有一點也是比較重要的，就是去Balance，選擇一個投入產(chǎn)出比最

6、優(yōu)的方案。關(guān)于這點第四段中會多說幾句。除此之外，架構(gòu)的主要目的是為了讓大家往同一個方向，在同一個標準之上去發(fā)散擴張。一是把控硬性的下限標準，提高整體的最短版，二是提高上限水平位，也就是天花板位置，提供更大的發(fā)展空間。好比造一幢大樓，把框架結(jié)構(gòu)設(shè)計好搭好，讓大家形成一個共識，什么是承重墻不能破壞，什么是創(chuàng)變空間可以自定義。在這樣的基礎(chǔ)下各自發(fā)展。這個看上去是個限制，但卻是做架構(gòu)最重要的任務(wù)，所謂再多的文檔，再多的最佳實踐都比不上一條約束。降低復(fù)雜度、降低理解難度，是實實在在的收益。最怕的就是憑空假設(shè)帶來的過度浪費。更甚之，我們做架構(gòu)追求的理想國度是一個大家擁有一致共識的世界，架構(gòu)是大家都像吃飯喝

7、水這樣習(xí)以為常的習(xí)慣。去理解或者接手其它人負責(zé)的項目的時候就好像是自己寫的一樣。這個時候就消滅架構(gòu)了，就好比現(xiàn)在沒有人會教你如何吃飯一樣。（就當YY一下吧）三、做架構(gòu)的最佳實踐上面提到更多的是做架構(gòu)的目的。那么要做好架構(gòu)，主要就是要做好抽象。做抽象的方式是類比，做類比的方式可以使用用例圖，所以建議大家多畫圖，通過畫圖來將大腦中抽象的結(jié)果直觀的體現(xiàn)在前面，再來進一步分析合理性。主要推薦2種圖的類別，一種就是前面提到的用例圖。如下圖：另外一種是魯棒圖，如圖：整個過程的主要目的是：描述其與外部實體（系統(tǒng)和最終用戶）的交互；標識系統(tǒng)和外部實體間的信息和控制流。理想的世界里，我們程序的邊界設(shè)計恰好匹配于

8、業(yè)務(wù)邊界。然而我們作為工程師首先要承擔(dān)業(yè)務(wù)需求的壓力，只能擠時間去做這些非業(yè)務(wù)性工作。也因此老項目的業(yè)務(wù)邊界也并不總是如新項目那樣明晰。這意味著做任何架構(gòu)的改動要考慮優(yōu)先級，特別在拆分業(yè)務(wù)領(lǐng)域之前，要認真地思考業(yè)務(wù)的邊界，排定優(yōu)先級，考量拆分的收益與風(fēng)險。劃分業(yè)務(wù)的邊界，則需要更多的思考拆分后的未來將如何溝通協(xié)作，然后再考慮技術(shù)因素。在技術(shù)因素前，主要考量這幾點：是否擁有獨立的團隊來維護，以及是否擁有發(fā)展為一項獨立業(yè)務(wù)的潛力。（非必要的情況下，一定要避免共享內(nèi)核的開發(fā)方式）圍繞領(lǐng)域而非 feature，有明確的維護團隊，避免過于細粒度。拆分或者組合之后，能否改善現(xiàn)有的協(xié)作流程。能否幫助區(qū)分核心

9、、非核心業(yè)務(wù)，改善穩(wěn)定性。上面這些完成了之后，便是選擇合適的中間件、技術(shù)框架來滿足技術(shù)層面的要求，這個的選拔主要以下面幾點來考量：如果是直接引入第三方的中間件的話，成熟度如何？是否有大公司在用？（有大公司的口碑背書的肯定大大加分）近期的社區(qū)活躍度如何？（用于考量是否有更多的人在一起踩坑，降低各自遇到坑的數(shù)量和概率）硬指標，當前場景的硬性要求是否滿足。如性能、對關(guān)鍵部分或者未來的可擴展性等。軟指標，復(fù)雜度、可維護性等。這里可以羅列幾個競品的優(yōu)劣勢。最重要的是要自己去親自驗證上面的幾點，并且做一定的模擬工作。如果曾經(jīng)用過或者有其中一部分的經(jīng)驗可復(fù)用，這是加分項，畢竟在使用的過程中才發(fā)現(xiàn)hold不住

10、它，那是災(zāi)難性的！四、什么是好架構(gòu)之前有聽到過一句話，概括的很精辟。好的架構(gòu)必須需要貼合業(yè)務(wù)。那么把業(yè)務(wù)+技術(shù)演變成一個數(shù)學(xué)公式來表達可以理解為：2個數(shù)字的和等于10，求如何組合能得到最大的乘積。那不是3*7，也不是4*6，而是5*5。所以架構(gòu)不是生搬硬套，不是為了架構(gòu)（搞事情）而架構(gòu)，趕時髦，或者說裝X。我們應(yīng)避免通過個人的主觀意愿來主導(dǎo)。比如自己覺得某個中間件好，就“拿著錘子到處找釘子”，這一敲下來，看著不錯，但是帶來的成本和風(fēng)險被忽略了。可能有更好的解決方案，或者完全沒必要在當下敲這一釘子下去。好的架構(gòu)需要評判投入產(chǎn)出比，收益更高的就是更好的架構(gòu)，就如下圖的公式：產(chǎn)出可以理解為我們因此獲

11、得的好處（諸如可靠性、安全性、可擴展性、可維護性、可伸縮性、性能等），成本是我們改造花費的投入，如人力物力和時間。特別注意的是風(fēng)險這點，是很重要也是很容易被大家忽略的一點，是起到指數(shù)級作用的。選擇的方案再好，如果都是一些hold不住的技術(shù)，那么風(fēng)險就是無窮大，導(dǎo)致減號右側(cè)無限趨近于0，最終的結(jié)果就是收益是負數(shù)，投入的成本打水漂，甚至還要加上其它額外的付出。五、如何成為架構(gòu)師上面提到的這些關(guān)注點都是架構(gòu)師的職責(zé)，另外特別重要的一點是，架構(gòu)師必須要是個有追求的“好碼農(nóng)”（劃重點）。軟件架構(gòu)師不像建筑師，其面對的本身是一個抽象的事物，如果再脫離了實操，這基本和紙上談兵無異。所以實際工作中的難點、要點都得清楚，并且能夠給出解決方案或者方向。另外只有熟悉實操才能更準確的評估成本。成為了一個真正的“好碼農(nóng)”就向架構(gòu)師邁出第一步了。而后呢，需要不斷以深廣深廣的節(jié)奏去開疆擴土，擴大自己的知識領(lǐng)域，當然需要以貼近當前工作內(nèi)容的知識為主，這是第二步。到了這還沒完，還有打造三板斧：業(yè)務(wù)能力、溝通能力、