聊聊架构设计做些什么来谈如何成为架构师
閱讀目錄
- 架構(gòu)的定義
- 架構(gòu)是做什么？
- 做架構(gòu)的最佳實(shí)踐
- 什么是好架構(gòu)
- 如何成為架構(gòu)師
- 結(jié)語(yǔ)
又有2周時(shí)間沒(méi)冒泡了，最近實(shí)在沒(méi)有大塊的時(shí)間來(lái)寫文章，就當(dāng)找個(gè)理由。。。
也因?yàn)樗槠臅r(shí)間多了，所以開始刷某乎了，關(guān)注了架構(gòu)相關(guān)的板塊，也順手回答了一些問(wèn)題。發(fā)現(xiàn)有很多同道中人正在經(jīng)歷著我前兩年經(jīng)歷的階段，對(duì)于做架構(gòu)沒(méi)有相對(duì)具象的一些理解，更沒(méi)有系統(tǒng)化的認(rèn)識(shí)。所以把最近回答的一些內(nèi)容整理一下，權(quán)當(dāng)記錄，留給3年后的自己~
按慣例，容許我裝X開頭~
?
一、架構(gòu)的定義
在軟件開發(fā)領(lǐng)域，自從架構(gòu)這個(gè)詞被廣泛傳播之后，產(chǎn)生的架構(gòu)模式也非常多，架構(gòu)關(guān)注點(diǎn)也在增加。但回到“道”的層面，架構(gòu)的定義或者說(shuō)本質(zhì)還是：
架構(gòu)，又名軟件架構(gòu)，是有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。
————摘自《百度百科》
?
二、架構(gòu)是做什么？
很多做業(yè)務(wù)功能的增刪改查開發(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è)階段開發(fā)，怎樣界定系統(tǒng)的邊界呢？
- 軟件系統(tǒng)是一個(gè)由多個(gè)模塊組成的整體。因此當(dāng)上游開發(fā)與我們負(fù)責(zé)的模塊銜接老是出問(wèn)題時(shí)，自己再做更多的努力也無(wú)法扭轉(zhuǎn)上游模塊的質(zhì)量差帶來(lái)的負(fù)面效果。（我想大家這時(shí)候肯定是抓狂的。）
- 每次看到別人寫的代碼，老覺(jué)得自己來(lái)寫的話肯定不會(huì)這么寫。比他寫的更好。（我們做技術(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í)候就好像是自己寫的一樣。這個(gè)時(shí)候就消滅架構(gòu)了，就好比現(xiàn)在沒(méi)有人會(huì)教你如何吃飯一樣。（就當(dāng)YY一下吧：）。）
?
三、做架構(gòu)的最佳實(shí)踐
上面提到更多的是做架構(gòu)的目的，那么要做好架構(gòu)，主要就是要做好抽象，做抽象的方式是類比，做類比的方式可以使用用例圖。所以建議大家多畫圖，通過(guò)畫圖來(lái)將大腦中抽象的結(jié)果直觀的體現(xiàn)在前面，再來(lái)進(jìn)一步分析合理性。主要推薦2種圖的類別，一種就是前面提到的用例圖。如下圖：
?
?
另外一種是魯棒圖，如圖：
整個(gè)過(guò)程的主要目的是：
- 描述其與外部實(shí)體（系統(tǒng)和最終用戶）的交互。
- 標(biāo)識(shí)系統(tǒng)和外部實(shí)體間的信息和控制流。
最后附一篇之前整理的《軟件開發(fā)中會(huì)用到的圖》的文章地址，有興趣的同學(xué)可以擴(kuò)展閱讀下：https://www.cnblogs.com/Zachary-Fan/p/developdiagram.html。
?
理想的世界里，我們程序的邊界設(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)核的開發(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)考量：
- 如果是直接引入第三方的中間件的話，成熟度如何？是否有大公司在用？（有大公司的口碑背書的肯定大大加分）
- 近期的社區(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)難性的！
?
四、什么是好架構(gòu)
之前有聽(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ù)，投入的成本打水漂，甚至還要加上其它額外的付出。
?
五、如何成為架構(gòu)師
上面提到的這些關(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é)奏去開疆?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)師吃的開。所以此文皆以應(yīng)用型架構(gòu)師的職能要求為參考。
?
六、結(jié)語(yǔ)
回到文章開頭，架構(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://www.cnblogs.com/Zachary-Fan/p/architecturetoarchitect.html
?
?
?關(guān)于作者：張帆（Zachary，個(gè)人微信號(hào)：Zachary-ZF）。堅(jiān)持用心打磨每一篇高質(zhì)量原創(chuàng)。歡迎掃描右側(cè)的二維碼~。
定期發(fā)表原創(chuàng)內(nèi)容：架構(gòu)設(shè)計(jì)丨分布式系統(tǒng)丨產(chǎn)品丨運(yùn)營(yíng)丨一些思考。
?
如果你是初級(jí)程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關(guān)注我的公眾號(hào)「跨界架構(gòu)師」，回復(fù)「技術(shù)」，送你一份我長(zhǎng)期收集和整理的思維導(dǎo)圖。
如果你是運(yùn)營(yíng)，面對(duì)不斷變化的市場(chǎng)束手無(wú)策。又或者想了解主流的運(yùn)營(yíng)策略，以豐富自己的“倉(cāng)庫(kù)”。歡迎關(guān)注我的公眾號(hào)「跨界架構(gòu)師」，回復(fù)「運(yùn)營(yíng)」，送你一份我長(zhǎng)期收集和整理的思維導(dǎo)圖。
轉(zhuǎn)載于:https://www.cnblogs.com/Zachary-Fan/p/architecturetoarchitect.html
總結(jié)
以上是生活随笔為你收集整理的聊聊架构设计做些什么来谈如何成为架构师的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： DB知识点记录
- 下一篇： springboot入门_shiro