別再增刪改查了！后端的盡頭是分布式
大家好，今天這篇文章和大家聊聊后端工程師的相關(guān)技術(shù)。
老實(shí)講我已經(jīng)好幾年沒(méi)有做過(guò)后端了，所以如果單純只是講技術(shù)的話，可能會(huì)有一些技術(shù)點(diǎn)已經(jīng)落后時(shí)代了。但是整體的思路以及后端這個(gè)領(lǐng)域的特點(diǎn)還是可以講講的，所以今天這篇技術(shù)的硬干貨可能較少，主要還是啟發(fā)性為主。
什么是后端？
首先來(lái)聊聊什么是后端。
對(duì)于沒(méi)有做過(guò)后端的同學(xué)來(lái)說(shuō)，可能覺(jué)得后端就是服務(wù)器后臺(tái)的開(kāi)發(fā)，如果已經(jīng)畢業(yè)了，在互聯(lián)網(wǎng)公司工作過(guò)的小伙伴可能會(huì)了解清晰一些，后端整天都在做各種增刪改查的操作，所以有些人覺(jué)得后端的工作就是增刪改查。
如果從功能服務(wù)上來(lái)區(qū)分的話，后端負(fù)責(zé)的是網(wǎng)站、app所有后臺(tái)響應(yīng)的功能。我們?nèi)粘？梢砸?jiàn)到的，比如淘寶、比如微信上所有大大小小的功能，所有的后臺(tái)邏輯都是后端實(shí)現(xiàn)的。舉個(gè)例子好了，比如淘寶購(gòu)物，我們?cè)谑謾C(jī)上的操作只有下單付錢(qián)。但是這背后有一大串邏輯，比如說(shuō)檢查庫(kù)存，檢查你的賬戶余額，再比如進(jìn)行轉(zhuǎn)賬，再比如提交訂單，再比如提交和訂單關(guān)聯(lián)的發(fā)貨單……我們看到的頁(yè)面上只是簡(jiǎn)單顯示下單成功了，但實(shí)際上后臺(tái)執(zhí)行了很長(zhǎng)一段程序。
后端做的就是這些用戶看不見(jiàn)，但是非常重要的功能。之前看過(guò)一個(gè)笑話，說(shuō)的是有一個(gè)小公司由于做了菠菜軟件，所以被警察抓了。但是警察不懂，所以只抓了所有的前端，因?yàn)橛X(jué)得前端能看見(jiàn)頁(yè)面，知道這個(gè)是一個(gè)菠菜軟件，明知故犯。而警察覺(jué)得后端只是維護(hù)維護(hù)的，可能不知情就給放了。但其實(shí)所有的邏輯部分都在后端手上，后端肯定比前端還要清楚……
聽(tīng)起來(lái)好像還可以對(duì)吧，但在實(shí)際工作當(dāng)中，后端的工作尤其是剛?cè)腴T(mén)的就相對(duì)比較乏味了，往往就是一水的增刪改查。這也不能怪，因?yàn)楹蠖送ǔ：蛿?shù)據(jù)庫(kù)直接交互，對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)最直接的操作就是增刪改查這四種。不知道會(huì)不會(huì)有同學(xué)看到這里覺(jué)得，那后端的工作是不是很簡(jiǎn)單呢？需要用到的技術(shù)也不多呢？
實(shí)際上又錯(cuò)了，后端這個(gè)崗位非常繁雜，涉及的技術(shù)也是出了名的多。說(shuō)白了，增刪改查雖然簡(jiǎn)單，但是想要把增刪改查做好卻并不容易。
后端有哪些技術(shù)？
如果這個(gè)問(wèn)題問(wèn)一個(gè)老后端，他掰掰手指可以給你羅列出一堆的名詞來(lái)。比如設(shè)計(jì)模式、數(shù)據(jù)庫(kù)優(yōu)化、框架、JVM、網(wǎng)絡(luò)編程、并發(fā)編程、鎖設(shè)計(jì)……
這么多名詞我們要是一個(gè)一個(gè)過(guò)估計(jì)得寫(xiě)成百科全書(shū)，所以我們簡(jiǎn)單一些。我把它簡(jiǎn)單總結(jié)了一下，大概可以分成三個(gè)部分。分別是語(yǔ)言、框架以及分布式。
語(yǔ)言
先從語(yǔ)言開(kāi)始，這里的語(yǔ)言并不只是簡(jiǎn)單的Java、或者是Go這種語(yǔ)言基礎(chǔ)，還會(huì)結(jié)合語(yǔ)言本身的特性涉及很多其他的東西。
以Java為例，除了需要了解和掌握J(rèn)ava常用的各種語(yǔ)言特性以及功能之外，還需要對(duì)Java這門(mén)語(yǔ)言本身的一些特點(diǎn)進(jìn)行了解。比如說(shuō)Java的GC（垃圾回收）原理，我們什么情況下會(huì)觸發(fā)Java的GC，Java的GC又是如何操作的，它帶來(lái)的影響又是什么？我們針對(duì)頻繁GC的情況怎么優(yōu)化？
再比如JVM，JVM當(dāng)中都有哪些配置，這些配置會(huì)有哪些影響？我們什么時(shí)候需要修改JVM的配置？
再比如Java多態(tài)、抽象類、接口、泛型這些進(jìn)階的用法，再比如基于Java實(shí)現(xiàn)的設(shè)計(jì)模式……
你看，雖然都是圍繞Java這一門(mén)語(yǔ)言展開(kāi)的，但是涉及到的技術(shù)卻一點(diǎn)也不少。這些可以說(shuō)都是后端的基礎(chǔ)，一個(gè)剛畢業(yè)的新人可能不懂，但是對(duì)于老法師而言，這些都是必會(huì)的技能。如果基礎(chǔ)沒(méi)打牢，在以后的職業(yè)發(fā)展當(dāng)中很容易翻車。
框架
不管是什么語(yǔ)言，做后端幾乎都會(huì)有一些自己的框架。
框架這個(gè)詞是從英文framework翻譯過(guò)來(lái)的，很多人理解不好。其實(shí)簡(jiǎn)單一些舉個(gè)例子，如果把做一個(gè)完整的后臺(tái)程序比喻成起房子，那么框架就相當(dāng)于是毛坯房。顯然相比于自己費(fèi)心費(fèi)力去打地基、造骨架，直接從別人那里把現(xiàn)成的毛坯房搬運(yùn)過(guò)來(lái)要容易得多。落實(shí)到具體的內(nèi)容上，如果我們從零開(kāi)始實(shí)現(xiàn)一個(gè)后臺(tái)程序的話，我們需要做很多事情，比如說(shuō)通過(guò)socket監(jiān)聽(tīng)網(wǎng)絡(luò)端口，再比如多線程處理獲取的請(qǐng)求，再比如組裝前端需要的數(shù)據(jù)格式等等……
而框架當(dāng)中已經(jīng)替我們做好了這些事情，我們都只需要安裝好框架，這些事情都可以省略。Java現(xiàn)在比較主流的框架是SSM框架，Spring + SpringMVC + MyBatis。這三個(gè)框架各有作用，組合在了一起可以很容易創(chuàng)建出功能強(qiáng)大代碼簡(jiǎn)潔的后端程序。
正是由于框架非常重要，所以僅僅停留在會(huì)用上是不夠的，老法師們還需要對(duì)框架的原理甚至是源碼做更深入的了解。
分布式
分布式后端當(dāng)中的一個(gè)大塊，也是最重要的一大塊，所以本文的標(biāo)題才會(huì)說(shuō)后端的盡頭是分布式。
分布式在后端當(dāng)中又可以分為兩塊，一塊是分布式中間件，還有一塊是系統(tǒng)設(shè)計(jì)。沒(méi)做過(guò)后端的應(yīng)該沒(méi)有聽(tīng)說(shuō)過(guò)，中間件對(duì)于后端來(lái)說(shuō)非常重要，也是非常常用的工具?？梢园阎虚g件理解成通用服務(wù)或者是企業(yè)內(nèi)的通用工具，我以消息系統(tǒng)舉個(gè)例子。消息系統(tǒng)顧名思義主要是用來(lái)傳遞消息，可以簡(jiǎn)單看成是一個(gè)消息隊(duì)列，可以根據(jù)程序員的需要將消息存儲(chǔ)在隊(duì)列當(dāng)中，使用方可以根據(jù)自己的需要來(lái)進(jìn)行讀取。比如ABC三個(gè)team都需要使用某一份日志，有了消息系統(tǒng)之后，ABC只需要各自監(jiān)聽(tīng)消息系統(tǒng)，進(jìn)行消費(fèi)即可。如果采用上游分發(fā)數(shù)據(jù)的做法，上游需要維護(hù)一個(gè)下游的分發(fā)list，而且數(shù)據(jù)也需要重復(fù)發(fā)送許多次，非常不優(yōu)雅。
除了消息系統(tǒng)之外，還有很多其他的中間件，比如負(fù)責(zé)緩存、存儲(chǔ)數(shù)據(jù)的分布式存儲(chǔ)，再比如RPC框架等等。
另外一塊是系統(tǒng)設(shè)計(jì)，因?yàn)楹蠖吮旧砭褪腔诜植际皆O(shè)計(jì)的，幾乎沒(méi)有人的后端程序只運(yùn)行在一臺(tái)機(jī)器上，往往都會(huì)有多臺(tái)機(jī)器同時(shí)相應(yīng)。多臺(tái)機(jī)器和一臺(tái)機(jī)器的區(qū)別并不僅僅是機(jī)器數(shù)量更多而已，會(huì)產(chǎn)生一系列數(shù)據(jù)一致性的問(wèn)題。架構(gòu)師們要做的就是根據(jù)業(yè)務(wù)的需要設(shè)計(jì)系統(tǒng)，使得可以在滿足當(dāng)前要求的前提下，還能保證未來(lái)方便拓展，并且保證不會(huì)出現(xiàn)不能容忍的錯(cuò)誤。
淺談一下分布式
分布式系統(tǒng)本身是一個(gè)非常宏大的概念，也非常困難，容易脫發(fā)的同學(xué)不建議挑戰(zhàn)。我也沒(méi)有這個(gè)能力吃透整個(gè)體系，只能說(shuō)是略知一二。
我們都知道后端服務(wù)器做的數(shù)據(jù)請(qǐng)求最后往往都會(huì)抽象成增刪改查這四種操作，增就是插入一條數(shù)據(jù)。比如我們用戶注冊(cè)的功能，本質(zhì)上就是往注冊(cè)用戶的表當(dāng)中新增一條從前沒(méi)有過(guò)的記錄。刪也很好理解， 就是刪除一條記錄。比如我們注銷用戶的時(shí)候，就會(huì)刪除一條記錄。同理，改和查也都類似，改就是修改數(shù)據(jù)，查則是查詢數(shù)據(jù)。
增刪改查是后端服務(wù)器最基本也是最核心的操作，所以單核的服務(wù)器大概是下圖這個(gè)樣子。
單核的服務(wù)器顯然無(wú)論是存儲(chǔ)能力還是響應(yīng)能力都是有限的，你能想象微信十幾億用戶的所有數(shù)據(jù)都存在一臺(tái)機(jī)器上嗎？顯然這是不可能的，沒(méi)有機(jī)器能夠承受這么大的數(shù)據(jù)，這么大規(guī)模的請(qǐng)求。
既然扛不住，那么就必須要拆分，這一拆分問(wèn)題就出現(xiàn)了。我們假設(shè)拆分之后的集群里有ABC三臺(tái)機(jī)器在響應(yīng)請(qǐng)求，大概是下面這樣。
這個(gè)看起來(lái)毫無(wú)問(wèn)題對(duì)吧，我們來(lái)假設(shè)一個(gè)場(chǎng)景。假設(shè)我現(xiàn)在賬戶余額里有100塊，現(xiàn)在充值話費(fèi)50，然后再給張三轉(zhuǎn)賬100塊。顯然這是不行的，因?yàn)橛囝~不足。但如果我們的這兩個(gè)請(qǐng)求是落到兩臺(tái)不同的機(jī)器上同時(shí)處理呢？?jī)膳_(tái)機(jī)器各自檢查余額的時(shí)候都是滿足的，但是同時(shí)一執(zhí)行立刻就出現(xiàn)問(wèn)題了。
那要如何解決這個(gè)問(wèn)題呢？
這個(gè)時(shí)候一個(gè)比較好的策略就是不按照請(qǐng)求進(jìn)行拆分，而是按照用戶拆分，強(qiáng)制安排同一個(gè)用戶的請(qǐng)求一定會(huì)落到同一臺(tái)機(jī)器里，這樣就可以保證不會(huì)出現(xiàn)同時(shí)被執(zhí)行的情況。再比如我之前寫(xiě)過(guò)的關(guān)于微博的case，比如微博當(dāng)中一些大V動(dòng)輒幾千萬(wàn)粉絲，有沒(méi)有想過(guò)這些大V每次發(fā)推怎么提醒他們的粉絲？通過(guò)循環(huán)一個(gè)一個(gè)通知可行嗎？如果不這樣，又該怎么解決呢？
大家感興趣的話，可以閱讀一下下面這篇文章。
尾聲
怎么樣，大家把后端崗位所需要的技術(shù)都搞清楚了嗎？
正所謂剛?cè)腴T(mén)的后端做CURD，資深的后端搭框架，老后端設(shè)計(jì)系統(tǒng)。關(guān)于分布式這個(gè)部分，雖然很難，但也的確很有意思，很考驗(yàn)思維。但遺憾的是很多初學(xué)者做了一段時(shí)間CURD，就以為后端一直是CURD，還沒(méi)有體會(huì)到樂(lè)趣就放棄成長(zhǎng)了，不得不說(shuō)也是很遺憾了。
完