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