一、前言
如果說(shuō)編程只是單純的承接產(chǎn)品需求開發(fā)系統(tǒng)功能,那么基本可以把程序開發(fā)簡(jiǎn)單理解成按照需求PRD, 尤其是在一些大公司中,會(huì)有易用的、完善的、標(biāo)準(zhǔn)的架構(gòu)體系和運(yùn)維服務(wù),例如:RPC、MQ、Redis集群、分布式任務(wù)、配置中心、分庫(kù)分表組件、網(wǎng)關(guān)等搭配出來(lái)的系統(tǒng)架構(gòu)。也因此 讓程序員只關(guān)心業(yè)務(wù)開發(fā),有成熟的系統(tǒng)架構(gòu)、有標(biāo)準(zhǔn)的開發(fā)流程、有通用的功能設(shè)計(jì),對(duì)于團(tuán)隊(duì)效能提升來(lái)說(shuō)是非常好的事。但一部分程序員正因?yàn)橛羞@樣的 如果是框架和中間件的存在,是了讓程序員只關(guān)心業(yè)務(wù)開發(fā)。那為什么你面試的時(shí)候會(huì)被問(wèn)到核心組件的設(shè)計(jì)和原理呢? 在這個(gè)年代,別放棄學(xué)習(xí)是你幾乎唯一的生存途徑。 二、多線程和鎖沒用過(guò)?面試必問(wèn)的 互聯(lián)網(wǎng)應(yīng)用中有些業(yè)務(wù)場(chǎng)景開發(fā),確實(shí)很少能用到多線程,也幾乎不需要你去加鎖。即使你能用到多線程的地方也可以用其他更好的方式處理,就像你需要多個(gè)線程把數(shù)據(jù)落庫(kù),那么就可以使用異步MQ的方式,把壓力分散到各個(gè)應(yīng)用實(shí)例上去。而這一開發(fā)方式的演變,是因?yàn)楝F(xiàn)在的應(yīng)用開發(fā)和部署都是基于分布式的思想,所以也就很少會(huì)有非得用線程來(lái)壓榨單實(shí)例CPU。 在基于RPC+MQ+數(shù)據(jù)庫(kù)路由+網(wǎng)關(guān),以及各類配合的組件下,構(gòu)建出的分布式應(yīng)用,在某些時(shí)候是改變了我們的開發(fā)模式的??赡茉瓉?lái)我們需要大量使用多線程在單個(gè)實(shí)例下的開發(fā)思路,在使用分布式架構(gòu)后,就需要轉(zhuǎn)變這一思想,所以隨時(shí)而來(lái)的使用多線程和鎖的場(chǎng)景也會(huì)減少。 圖 14-1 分布式簡(jiǎn)化的應(yīng)用部署 但,也不是就沒有多線程和鎖的業(yè)務(wù)場(chǎng)景,就比如我們的核心組件中,數(shù)據(jù)庫(kù)連接池、分布式任務(wù)中,都會(huì)涉及到多線程和鎖的使用。也有一些類似商品秒殺的場(chǎng)景,同樣需要使用到鎖。 那么,使用多線程為了更大限度的利用資源提升效率,加鎖是為了在同一個(gè)資源有競(jìng)爭(zhēng)的情況保證業(yè)務(wù)流程的正確性。就像:數(shù)據(jù)庫(kù)連接池為了合理分配數(shù)據(jù)庫(kù)資源、商品秒殺是為了庫(kù)存的競(jìng)爭(zhēng)。 可是,在沒有需要競(jìng)爭(zhēng)和分配資源的情況下,一般并不會(huì)在分布式場(chǎng)景下使用到多線程。假如我們做一個(gè)用戶資源單次計(jì)數(shù)的操作,那么原來(lái)的應(yīng)用是單實(shí)例還是可以加鎖累加計(jì)數(shù)的。但現(xiàn)在是分布式應(yīng)用部署,也就是你可能這一時(shí)刻是A實(shí)例提供你的需求,當(dāng)你再次刷新頁(yè)面后可能訪問(wèn)到的就是B實(shí)例。這時(shí)候在想做一些實(shí)例上的累加,就沒那么方便了。 這也就是在分布式應(yīng)用框架的應(yīng)用中,讓你能用到多線程和鎖的地方并不多的原因。但如果你有需要去了解一些中間件或者核心組件的設(shè)計(jì)時(shí),就需要了解相關(guān)的核心知識(shí)。 很多紙上談兵的技術(shù),也就是你造輪子、造火箭、成為架構(gòu)師的根基! 如果你還想奔著這條路能走的更遠(yuǎn),就需要繼續(xù)學(xué)習(xí)。 三、你的成長(zhǎng)階段目標(biāo)?就編程開發(fā)這條道路而言,每一個(gè)成長(zhǎng)階段的目標(biāo)都會(huì)有它隨著帶來(lái)的難以攻克的
隨著年齡的增長(zhǎng),每一階段都有難以跨越的難。而那些看上去突破了瓶頸,達(dá)到了你想要的高度的人。其實(shí)每一個(gè)階段,他們都跑在前面。 但就單純的技術(shù)成長(zhǎng)而言,其實(shí)理論知識(shí)并不難,只要你學(xué)就還能會(huì),只是付出的時(shí)間成本不同罷了。但過(guò)了理論知識(shí)這一關(guān)后,接下來(lái)要面對(duì)的是創(chuàng)造能力,也就是為什么你感覺自己會(huì)了那么多技術(shù)內(nèi)容,但是實(shí)際開發(fā)時(shí)卻總感覺寫不出好代碼的階段。 會(huì)了核心技術(shù)但又寫不出好代碼,就很像是: 所以,多實(shí)戰(zhàn)一些項(xiàng)目代碼,多看一些設(shè)計(jì)模式,會(huì)讓你更好的理解代碼該怎么用,也就能提升突破當(dāng)前的階段屏障。😄推薦小傅哥的《重學(xué)Java設(shè)計(jì)模式》,公眾號(hào):bugstack蟲洞棧,回復(fù):設(shè)計(jì)模式,下載。 四、怎么成長(zhǎng)為架構(gòu)師?講到架構(gòu)師,其實(shí)真的挺難因?yàn)閳?bào)名一個(gè)課程學(xué)習(xí)完就能成為架構(gòu)師。架構(gòu)師的成長(zhǎng)更多的取決你們的研發(fā)組是否需要一個(gè)架構(gòu)師,也同時(shí)需要你在這個(gè)崗位起到應(yīng)有的作用。 如果你還不是架構(gòu)師,但想成為架構(gòu)師。那么還取決于你的老板是否愿意把你培養(yǎng)成架構(gòu)師,以及你自己的多方面能力是否具備。另外,并不一定高級(jí)開發(fā)就低于架構(gòu)師。高級(jí)開發(fā)有時(shí)候比架構(gòu)師做的事更專一、更核心。 那么除了圖 14-3 對(duì)于架構(gòu)師的能力概況,有哪些具體的事項(xiàng)呢?
**做好架構(gòu),遠(yuǎn)看是部門效率,近看是解決爛代碼!**很多時(shí)候的急,可能讓整個(gè)工程爛掉。爛的越來(lái)越多,最終也會(huì)影響業(yè)務(wù)發(fā)展。那么這些爛代碼都怎么來(lái)的呢?
爛,來(lái)自于很多方面,而且這并不是你報(bào)名個(gè)課程就能學(xué)到的。業(yè)務(wù)、產(chǎn)品、研發(fā),三方共同努力才能更好的減少爛的出現(xiàn),而這些也是每一個(gè)研發(fā)都應(yīng)該努力的方向,也幾乎是你要成為架構(gòu)師的必經(jīng)之路。 五、總結(jié)
六、系列推薦
|
|