13518219792
在軟件開(kāi)發(fā)領(lǐng)域，自從架構(gòu)這個(gè)詞被廣泛傳播之后，產(chǎn)生的架構(gòu)模式也非常多，架構(gòu)關(guān)注點(diǎn)也在增加。但回到“道”的層面，架構(gòu)的定義或者說(shuō)本質(zhì)還是：
網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、小程序開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了涿州免費(fèi)建站歡迎大家使用！
架構(gòu)，又名軟件架構(gòu)，是有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。
————摘自《百度百科》
很多做業(yè)務(wù)功能的增刪改查開(kāi)發(fā)感受到無(wú)趣的小伙伴常把做架構(gòu)想象成一片樂(lè)土，沒(méi)有嘈雜的業(yè)務(wù)聲音干擾，可以專心做一番牛X的技術(shù)。會(huì)把架構(gòu)單純的理解成，牛X的性能、牛X的TPS、高可用，支撐了多少PV等等。但是其實(shí)這些只是架構(gòu)很小的一部分，并不是全部。在互聯(lián)網(wǎng)時(shí)代之前都是C/S程序的天下，那個(gè)時(shí)候并沒(méi)有對(duì)性能等有像現(xiàn)在這樣的關(guān)注度，但是就已經(jīng)有架構(gòu)之說(shuō)了。 世上本無(wú)架構(gòu)，只是由于團(tuán)隊(duì)越大越需要對(duì)整體的規(guī)則做約定，好讓大家往同一個(gè)方向發(fā)力，避免各自為戰(zhàn)，產(chǎn)生大量的內(nèi)耗，所以才逐漸形成了架構(gòu)。這條路就是“世上本無(wú)路，只是因?yàn)樽叩娜硕嗔俗兂闪寺贰薄?/p>
為什么說(shuō)一個(gè)軟件架構(gòu)是很重要的呢？當(dāng)我們的團(tuán)隊(duì)人數(shù)只有2、3個(gè)人，甚至只有1個(gè)人單槍匹馬的情況下，可能架構(gòu)凸顯的作用不是那么的明顯，但是如果團(tuán)隊(duì)大了之后相信下面的這些現(xiàn)象會(huì)比較常見(jiàn)：
新上一個(gè)系統(tǒng)，往往不是獨(dú)立存在的，一般都需要與現(xiàn)存的系統(tǒng)進(jìn)行交互，而需要集成交互的地方可能還很多，哪些集成是本系統(tǒng)需要實(shí)現(xiàn)的？同時(shí)，一般會(huì)劃分為多個(gè)階段開(kāi)發(fā)，怎樣界定系統(tǒng)的邊界呢？
軟件系統(tǒng)是一個(gè)由多個(gè)模塊組成的整體。因此當(dāng)上游開(kāi)發(fā)與我們負(fù)責(zé)的模塊銜接老是出問(wèn)題時(shí)，自己再做更多的努力也無(wú)法扭轉(zhuǎn)上游模塊的質(zhì)量差帶來(lái)的負(fù)面效果。（我想大家這時(shí)候肯定是抓狂的。）
每次看到別人寫(xiě)的代碼，老覺(jué)得自己來(lái)寫(xiě)的話肯定不會(huì)這么寫(xiě)。比他寫(xiě)的更好。（我們做技術(shù)的，自我感覺(jué)良好是個(gè)常態(tài)：）。）
在某些場(chǎng)景下，自己腦子里有多套方案來(lái)實(shí)現(xiàn)，但是對(duì)孰優(yōu)孰劣沒(méi)太大感覺(jué)，最終基本上就是拍腦袋選了一個(gè)。
某塊代碼維護(hù)的次數(shù)多了，特別是中間由多個(gè)人接手過(guò)后，代碼風(fēng)格各異，難以理解。
相似的代碼在好幾個(gè)地方出現(xiàn)，特別是一些非業(yè)務(wù)性的代碼，比如日志處理等。再甚是在大型的分布式系統(tǒng)中，不同子程序使用了不同的同類型中間件，同樣導(dǎo)致維護(hù)成本大增。
在2個(gè)相依賴項(xiàng)目邊界處的設(shè)計(jì)產(chǎn)生了分歧，并且站在各自的角度看都有道理。
任何事物都是有兩面性的，并不是說(shuō)上面的這些問(wèn)題，我們通過(guò)架構(gòu)就要往另外一個(gè)極端去走。比如在大型的分布式系統(tǒng)中，不同子程序的確有必要在某些時(shí)刻選擇同類型的其它中間件。如Kafka和RabbitMQ雖都是MQ，但在特定的場(chǎng)景下能發(fā)揮的價(jià)值是無(wú)法相互替代的。
所以我們做架構(gòu)有一點(diǎn)也是比較重要的，就是去Balance，選擇一個(gè)投入產(chǎn)出比最優(yōu)的方案。關(guān)于這點(diǎn)第四段中會(huì)多說(shuō)幾句。
除此之外，架構(gòu)的主要目的是為了讓大家往同一個(gè)方向，在同一個(gè)標(biāo)準(zhǔn)之上去發(fā)散擴(kuò)張。一是把控硬性的下限標(biāo)準(zhǔn)，提高整體的最短版，二是提高上限水平位，也就是天花板位置，提供更大的發(fā)展空間。好比造一幢大樓，把框架結(jié)構(gòu)設(shè)計(jì)好搭好，讓大家形成一個(gè)共識(shí)，什么是承重墻不能破壞，什么是創(chuàng)變空間可以自定義。在這樣的基礎(chǔ)下各自發(fā)展。這個(gè)看上去是個(gè)限制，但卻是做架構(gòu)最重要的任務(wù)，所謂再多的文檔，再多的最佳實(shí)踐都比不上一條約束。降低復(fù)雜度、降低理解難度，是實(shí)實(shí)在在的收益。最怕的就是憑空假設(shè)帶來(lái)的過(guò)度浪費(fèi)。
更甚之，我們做架構(gòu)追求的理想國(guó)度是一個(gè)大家擁有一致共識(shí)的世界，架構(gòu)是大家都像吃飯喝水這樣習(xí)以為常的習(xí)慣。去理解或者接手其它人負(fù)責(zé)的項(xiàng)目的時(shí)候就好像是自己寫(xiě)的一樣。這個(gè)時(shí)候就消滅架構(gòu)了，就好比現(xiàn)在沒(méi)有人會(huì)教你如何吃飯一樣。（就當(dāng)YY一下吧：）。）
上面提到更多的是做架構(gòu)的目的，那么要做好架構(gòu)，主要就是要做好抽象，做抽象的方式是類比，做類比的方式可以使用用例圖。所以建議大家多畫(huà)圖，通過(guò)畫(huà)圖來(lái)將大腦中抽象的結(jié)果直觀的體現(xiàn)在前面，再來(lái)進(jìn)一步分析合理性。主要推薦2種圖的類別，一種就是前面提到的用例圖。如下圖：
另外一種是魯棒圖，如圖：
整個(gè)過(guò)程的主要目的是：
描述其與外部實(shí)體（系統(tǒng)和最終用戶）的交互。
標(biāo)識(shí)系統(tǒng)和外部實(shí)體間的信息和控制流。
之前有一篇專門(mén)整理圖的文章《軟件開(kāi)發(fā)中會(huì)用到的圖》，有興趣的小伙伴可以在我公眾號(hào)中查閱。
理想的世界里，我們程序的邊界設(shè)計(jì)恰好匹配于業(yè)務(wù)邊界。然而我們作為工程師首先要承擔(dān)業(yè)務(wù)需求的壓力，只能擠時(shí)間去做這些非業(yè)務(wù)性工作。也因此老項(xiàng)目的業(yè)務(wù)邊界也并不總是如新項(xiàng)目那樣明晰。
這意味著做任何架構(gòu)的改動(dòng)要考慮優(yōu)先級(jí)，特別在拆分業(yè)務(wù)領(lǐng)域之前認(rèn)真地思考業(yè)務(wù)的邊界。排定優(yōu)先級(jí)，考量拆分的收益與風(fēng)險(xiǎn)。劃分業(yè)務(wù)的邊界，則需要更多的思考拆分后的未來(lái)將如何溝通協(xié)作，然后再考慮技術(shù)因素。在技術(shù)因素前，主要考量這幾點(diǎn)：
是否擁有獨(dú)立的團(tuán)隊(duì)來(lái)維護(hù)，以及是否擁有發(fā)展為一項(xiàng)獨(dú)立業(yè)務(wù)的潛力。（非必要的情況下，一定要避免共享內(nèi)核的開(kāi)發(fā)方式）
圍繞領(lǐng)域而非 feature，有明確的維護(hù)團(tuán)隊(duì)，避免過(guò)于細(xì)粒度。
拆分或者組合之后，能否改善現(xiàn)有的協(xié)作流程。
能否幫助區(qū)分核心、非核心業(yè)務(wù)，改善穩(wěn)定性。
上面這些完成了之后，便是選擇合適的中間件、技術(shù)框架來(lái)滿足技術(shù)層面的要求，這個(gè)的選拔主要以下面幾點(diǎn)來(lái)考量：
如果是直接引入第三方的中間件的話，成熟度如何？是否有大公司在用？（有大公司的口碑背書(shū)的肯定大大加分）
近期的社區(qū)活躍度如何？（用于考量是否有更多的人在一起踩坑，降低各自遇到坑的數(shù)量和概率）
硬指標(biāo)，當(dāng)前場(chǎng)景的硬性要求是否滿足。如性能、對(duì)關(guān)鍵部分或者未來(lái)的可擴(kuò)展性等。
軟指標(biāo)，復(fù)雜度、可維護(hù)性等。這里可以羅列幾個(gè)競(jìng)品的優(yōu)劣勢(shì)。
最重要的是要自己去親自驗(yàn)證上面的幾點(diǎn)，并且做一定的模擬工作。
如果曾經(jīng)用過(guò)或者有其中一部分的經(jīng)驗(yàn)可復(fù)用，這是加分項(xiàng)，畢竟在使用的過(guò)程中才發(fā)現(xiàn)hold不住它，那是災(zāi)難性的！
之前有聽(tīng)到過(guò)一句話，概括的很精辟。好的架構(gòu)必須需要貼合業(yè)務(wù)，那么把業(yè)務(wù)+技術(shù)演變成一個(gè)數(shù)學(xué)公式來(lái)表達(dá)可以理解為：2個(gè)數(shù)字的和等于10，求如何組合能得到最大的乘積。那不是3*7，也不是4*6，而是5*5。
所以架構(gòu)不是生搬硬套，為了架構(gòu)（搞事情）而架構(gòu)，趕時(shí)髦，或者說(shuō)裝X。我們應(yīng)避免通過(guò)個(gè)人的主觀意愿來(lái)主導(dǎo)。比如自己覺(jué)得某個(gè)中間件好，就”拿著錘子到處找釘子“，這一敲下來(lái)，看著不錯(cuò)，但是帶來(lái)的成本和風(fēng)險(xiǎn)被忽略了。可能有更好的解決方案，或者完全沒(méi)必要在當(dāng)下敲這一釘子下去。
好的架構(gòu)需要評(píng)判投入產(chǎn)出比，收益更高的就是更好的架構(gòu)，就如下圖的公式。產(chǎn)出可以理解為我們因此獲得的好處（諸如可靠性、安全性、可擴(kuò)展性、可維護(hù)性、可伸縮性、性能等），成本是我們改造花費(fèi)的投入，如人力物力和時(shí)間。特別注意的是風(fēng)險(xiǎn)這點(diǎn)，是很重要也是很容易被大家忽略的一點(diǎn)，是起到指數(shù)級(jí)作用的。選擇的方案再好，如果都是一些hold不住的技術(shù)，那么風(fēng)險(xiǎn)就是無(wú)窮大，導(dǎo)致減號(hào)右側(cè)無(wú)限趨近于0，最終的結(jié)果就是收益是負(fù)數(shù)，投入的成本打水漂，甚至還要加上其它額外的付出。
上面提到的這些關(guān)注點(diǎn)都是架構(gòu)師的職責(zé)，另外特別重要的一點(diǎn)是，架構(gòu)師必須要是個(gè)有追求的“好碼農(nóng)”！！！（劃重點(diǎn)）。軟件架構(gòu)師不像建筑師，其面對(duì)的本身是一個(gè)抽象的事物，如果再脫離了實(shí)操，這基本和紙上談兵無(wú)異。所以實(shí)際工作中的難點(diǎn)、要點(diǎn)都得清楚，并且能夠給出解決方案或者方向。另外只有熟悉實(shí)操才能更準(zhǔn)確的評(píng)估成本
成為了一個(gè)真正的“好碼農(nóng)”就向架構(gòu)師邁出第一步了。而后呢，需要不斷以深 --> 廣 --> 深 --> 廣的節(jié)奏去開(kāi)疆?dāng)U土，擴(kuò)大自己的知識(shí)領(lǐng)域，當(dāng)然需要以貼近當(dāng)前工作內(nèi)容的知識(shí)為主，這是第二步。到了這還沒(méi)完，還有打造三板斧：業(yè)務(wù)能力、溝通能力、個(gè)人魅力。
題外話，在國(guó)內(nèi)，純技術(shù)的架構(gòu)師沒(méi)有應(yīng)用型的架構(gòu)師吃的開(kāi)。所以此文皆以應(yīng)用型架構(gòu)師的職能要求為參考。
回到文章開(kāi)頭，架構(gòu)的表現(xiàn)形式有很多，從本質(zhì)上單體應(yīng)用的架構(gòu)設(shè)計(jì)思想和分布式系統(tǒng)是一致的，所謂服務(wù)化其實(shí)也是模塊化的思想，只是維度的不同，導(dǎo)致用到的一些工具或者環(huán)境不同，但這都是“術(shù)”層面的東西。光學(xué)這些招數(shù)，永遠(yuǎn)也學(xué)不完。架構(gòu)之路漫長(zhǎng)，繼續(xù)前行，共勉。
作者：Zachary_Fan
出處：https://blog.51cto.com/4596298/2147603
如果你想及時(shí)得到個(gè)人自寫(xiě)文章的消息推送，歡迎掃描下面的二維碼~。
