40 張圖揭秘后端技術(shù)需要學(xué)啥
說到后端開發(fā)，難免會遇到各種所謂高大上的「關(guān)鍵詞 」，對于我們應(yīng)屆生小白，難免會覺得比較陌生，因為在學(xué)校確實比較少遇見這些所謂高大上的東西，那么今天就帶著學(xué)習(xí)的態(tài)度和大家分享這些看似可以裝逼可以飛的帶逼格的關(guān)鍵詞吧。
1 分布式
在學(xué)校里的項目中，一個 Web 系統(tǒng)可能咋們一個人就搞定，因為幾乎不考慮并發(fā)量，性能咋樣，所謂「過得去 」足矣，但是為了面試考慮，我們又不得不找點(diǎn)類似秒殺系統(tǒng)作為我們簡歷的支撐項目(即使已經(jīng)爛大街)。那么先問你第一個問題，為什么就采用了分布式的方案落地這個項目？
當(dāng)一個人或者幾十個使用你的系統(tǒng)，哎呀我去，請求秒回，效果倍棒，于是乎簡歷砰砰寫上卻多么牛X，當(dāng)面試官就會問你你這項目做了啥，測試過沒，并發(fā)量如何，性能如何？你就…..
當(dāng)訪問系統(tǒng)的用戶越來越多，可是我們的系統(tǒng)資源有限，所以需要更多的 CPU 和內(nèi)存去處理用戶的計算請求，當(dāng)然也就要求更大的網(wǎng)絡(luò)帶寬去處理數(shù)據(jù)的傳輸，也需要更多的磁盤空間存儲數(shù)據(jù)。資源不夠，消耗過度，服務(wù)器崩潰，系統(tǒng)也就不干活了，那么在這樣的情況怎么處理？
垂直伸縮
縱向生長。通過提升單臺服務(wù)器的計算處理能力來抵抗更大的請求訪問量。比如使用更快頻率的CPU，更快的網(wǎng)卡，塞更多的磁盤等。其實這樣的處理方式在電信，銀行等企業(yè)比較常見，讓摩托車變?yōu)樾∑?，更?qiáng)大的計算機(jī)，處理能力也就越強(qiáng)，但是對于運(yùn)維而言也就越來越復(fù)雜。那真的就這樣花錢買設(shè)備就完事了？
當(dāng)然不，單臺服務(wù)器的計算處理能力是有限的，而且也會嚴(yán)重受到計算機(jī)硬件水平的制約。
水平伸縮
一臺機(jī)器處理不過來，我就用多臺廉價的機(jī)器合并同時處理，人多力量大嘛，通過多臺服務(wù)器構(gòu)成分布式集群從而提升系統(tǒng)的整體處理能力。這里說到了分布式，那我們看看分布式的成長過程
記住一句話：系統(tǒng)的技術(shù)架構(gòu)是需求所驅(qū)動
最初的單體系統(tǒng)，只需要部分用戶訪問，
單體結(jié)構(gòu)
做系統(tǒng)的原因當(dāng)然是有需求，有價值，可賺錢。隨著使用系統(tǒng)的用戶越來越多，這時候關(guān)注的人越來越多，單臺服務(wù)器扛不住了，關(guān)注的人覺得響應(yīng)真慢，沒啥意思，就開始吐槽，但是這一吐槽，導(dǎo)致用戶更多，畢竟大家都愛吃瓜。
這樣下去不得不進(jìn)行系統(tǒng)的升級，將數(shù)據(jù)庫和應(yīng)用分離。
這樣子，咋們將數(shù)據(jù)庫和應(yīng)用程序分離后，部署在不同的服務(wù)器中，從1臺服務(wù)器變?yōu)槎嗯_服務(wù)器，處理響應(yīng)更快，內(nèi)容也夠干，訪問的用戶呈指數(shù)增長，這多臺服務(wù)器都有點(diǎn)扛不住了，怎么辦？
加一個緩存吧，我們不每次從數(shù)據(jù)庫中讀取數(shù)據(jù)，而將應(yīng)用程序需要的數(shù)據(jù)暫存在緩沖中。緩存呢，又分為本地緩存和分布式的緩存。分布式緩存，顧名思義，使用多臺服務(wù)器構(gòu)成集群，存儲更多的數(shù)據(jù)并提供緩存服務(wù)，從而提升緩存的能力。
加了緩存哪些好處？
應(yīng)用程序不再直接訪問數(shù)據(jù)庫，提升訪問效率。因為緩存內(nèi)容在內(nèi)存中，不用每次連接存放磁盤中的數(shù)據(jù)庫，
系統(tǒng)越來越火，于是考慮將應(yīng)用服務(wù)器也作為集群。
2 緩存架構(gòu)
干啥啥不行，緩存第一名。不吹牛，緩存應(yīng)用在計算機(jī)的各個角落。緩存可說是軟件技術(shù)中的的殺手锏，無論是程序代碼使用buffer，還是網(wǎng)絡(luò)架構(gòu)中使用緩存，虛擬機(jī)也會使用大量的緩存。其實最初在CPU中也就開始使用緩存。緩存分為兩種，一種是通讀緩存，一種是旁路緩存
通讀緩存
假設(shè)當(dāng)前應(yīng)用程序獲取數(shù)據(jù)，如果數(shù)據(jù)存在于通讀緩存中就直接返回。如果不存在于通讀緩存，那么就訪問數(shù)據(jù)源，同時將數(shù)據(jù)存放于緩存中。下次訪問就直接從緩存直接獲取。比較常見的為CDN和反向代理
CDN
CDN稱為內(nèi)容分發(fā)網(wǎng)絡(luò)。想象我們京東購物的時候，假設(shè)我們在成都，如果買的東西在成都倉庫有就直接給我們寄送過來，可能半天就到了，用戶體驗也非常好，就不用從北京再寄過來。同樣的道理，用戶就可以近距離獲得自己需要的數(shù)據(jù)，既提高了響應(yīng)速度，又節(jié)約了網(wǎng)絡(luò)帶寬和服務(wù)器資源。
旁路緩存
應(yīng)用程序需要自己從數(shù)據(jù)源讀取數(shù)據(jù)，然后將這個數(shù)據(jù)寫入到旁路緩存中。這樣，下次應(yīng)用程序需要數(shù)據(jù)的
時候，就可以通過旁路緩存直接獲得數(shù)據(jù)了
緩存的好處
因為大部分緩存的數(shù)據(jù)存儲在內(nèi)存中，相比于硬盤或者從網(wǎng)絡(luò)中獲取效率更高，響應(yīng)時間更快，性能更好
通過 CDN 等通讀緩存可以降低服務(wù)器的負(fù)載能力。
因為緩存通常會記錄計算結(jié)果。如果緩存命中直接返回，否則需要進(jìn)行大量的運(yùn)算。所以使用緩存也減少了CPU 的計算小號，加快處理速度
緩存缺點(diǎn)
我們緩存的數(shù)據(jù)來自源數(shù)據(jù)，如果源數(shù)據(jù)被修改了，俺么緩存數(shù)據(jù)很肯能也是被修改過的，成為臟數(shù)據(jù)，所以怎么辦？
過期失效
在每次寫入緩存數(shù)據(jù)的時候標(biāo)記失效時間，讀取數(shù)據(jù)的時候檢查數(shù)據(jù)是否失效，如果失效了就重新從數(shù)據(jù)源獲取數(shù)據(jù)。、
失效通知
應(yīng)用程序在更新數(shù)據(jù)源的時候，通知清除緩存中的數(shù)據(jù)。
是不是數(shù)據(jù)使用緩存都有意義呢？
非也，通常放入緩存中的數(shù)據(jù)都是帶有熱點(diǎn)的數(shù)據(jù)，比如當(dāng)日熱賣商品，或者熱門吃瓜新聞，這樣將數(shù)據(jù)存放在緩存中，會被多次讀取，從而緩存的命中率也會比較高
3 異步架構(gòu)
在前面中，通過緩存實際上很多時候是解決了讀的問題，加快了讀取數(shù)據(jù)的能力。因為緩存通常很難保證數(shù)據(jù)的持久性和一致性，所以我們通常不會將數(shù)據(jù)直接寫入緩存中，而是寫入 RDBMAS 等數(shù)據(jù)中，那如何提升系統(tǒng)的寫操作性能呢？
此時假設(shè)兩個系統(tǒng)分別為A,B，其中A系統(tǒng)依賴B系統(tǒng)，兩者通信采用遠(yuǎn)程調(diào)用的方式，此時如果B系統(tǒng)出故障，很可能引起A系統(tǒng)出故障。
從而不得不單獨(dú)進(jìn)行升級，怎么辦？
使用消息隊列的異步架構(gòu)，也成為事件驅(qū)動模型。
異步相對于同步而言，同步通常是當(dāng)應(yīng)用程序調(diào)用服務(wù)的時候，不得不阻塞等待服務(wù)期完成，此時CPU空閑比較浪費(fèi)，直到返回服務(wù)結(jié)果后才會繼續(xù)執(zhí)行。
舉個例子，小藍(lán)今天想在系統(tǒng)中加一個發(fā)郵件的功能，通過SMTP和遠(yuǎn)程服務(wù)器通信，但是遠(yuǎn)程服務(wù)器有很多郵件需要等待發(fā)送呢，當(dāng)前郵件就可能等待比較長時間才能發(fā)送成功，發(fā)送成功后反饋與應(yīng)用程序。這個過程中，遠(yuǎn)程服務(wù)器發(fā)送郵件的時候，應(yīng)用程序就阻塞，準(zhǔn)確的說是執(zhí)行應(yīng)用程序的線程阻塞。
這樣阻塞帶來什么問題“？
不能釋放占用的系統(tǒng)資源，導(dǎo)致系統(tǒng)資源不足，影響系統(tǒng)性能
無法快速給用戶響應(yīng)結(jié)果
但是在實際情況中，我們發(fā)送郵件，并不需要得到發(fā)送結(jié)果。比如用戶注冊，發(fā)送賬號激活郵件，無論郵件是否發(fā)送成功都會收到"返回郵件已經(jīng)發(fā)送，請查收郵件確認(rèn)激活"，怎樣才能讓應(yīng)用程序不阻塞？
此時就比較清晰了，調(diào)用者將消息發(fā)送給消息隊列直接返回，應(yīng)用程序收到返回以后繼續(xù)執(zhí)行，快讀響應(yīng)用戶釋放資源。有專門的消費(fèi)隊列程序從中消息隊列取出數(shù)據(jù)并進(jìn)行消費(fèi)。如果遠(yuǎn)程服務(wù)出現(xiàn)故障，只會傳遞給消費(fèi)者程序而不會影響到應(yīng)用程序。
消息隊列模型中通常有三個角色，分別為生產(chǎn)者，消息隊列和消費(fèi)者。生產(chǎn)者產(chǎn)生數(shù)據(jù)封裝為消息發(fā)送給消息隊列，專門的消費(fèi)程序從消息隊列中取出數(shù)據(jù)，消費(fèi)數(shù)據(jù)。在我看來，消息隊列主要是緩沖消息，等待消費(fèi)者消費(fèi)。其中消費(fèi)的方式分為兩種
點(diǎn)對點(diǎn)
對生產(chǎn)者多消費(fèi)者的情況。一個消息被一個消費(fèi)者消費(fèi)
上述的發(fā)郵件例子就是典型的點(diǎn)對點(diǎn)模式?；ゲ桓蓴_，其中某個服務(wù)出現(xiàn)問題不會印象到全局
訂閱模式
開發(fā)人員在消息隊列中設(shè)置主題，生產(chǎn)者往相應(yīng)的主題發(fā)送數(shù)據(jù)，消費(fèi)者從對應(yīng)的主題中消費(fèi)數(shù)據(jù)，每個消費(fèi)者按照自己業(yè)務(wù)邏輯分別進(jìn)行計算
這個比較好理解，比如在用戶注冊的時候，我們將注冊信息放入主題用戶中，消費(fèi)者訂閱了這個主題，可能有構(gòu)造短信消息的消費(fèi)者，也有推廣產(chǎn)品的消費(fèi)者，都可以根據(jù)自己業(yè)務(wù)邏輯進(jìn)行數(shù)據(jù)處理。
使用異步模型的優(yōu)點(diǎn)
快速響應(yīng)
不在需要等待。生產(chǎn)者將數(shù)據(jù)發(fā)送消息隊列后，可繼續(xù)往下執(zhí)行，不虛等待耗時的消費(fèi)處理
削峰填谷(需要修改)
互聯(lián)網(wǎng)產(chǎn)品會在不同的場景其并發(fā)請求量不同?；ヂ?lián)網(wǎng)應(yīng)用的訪問壓力隨時都在變化，系統(tǒng)的訪問高峰和低谷的并發(fā)壓力可能也有非常大的差距。如果按照壓力最大的情況部署服務(wù)器集群，那么服務(wù)器在絕大部分時間內(nèi)都處于閑置狀態(tài)。但利用消息隊列，我們可以將需要處理的消息放入消息隊列，而消費(fèi)者可以控制消費(fèi)
速度，因此能夠降低系統(tǒng)訪問高峰時壓力，而在訪問低谷的時候還可以繼續(xù)消費(fèi)消息隊列中
未處理的消息，保持系統(tǒng)的資源利用率
降低耦合
如果調(diào)用是同步，如果調(diào)用是同步的，那么意味著調(diào)用者和被調(diào)用者必然存在依賴，一方面是代碼上的依賴，應(yīng)用程序需要依賴發(fā)送郵件相關(guān)的代碼，如果需要修改發(fā)送郵件的代碼，就必須修改應(yīng)用程序，而且如果要增加新的功能
那么目前主要的消息隊列有哪些，其有缺點(diǎn)是什么？(好好記下這個高頻題目啦)
4 負(fù)載均衡
一臺機(jī)器扛不住了，需要多臺機(jī)器幫忙，既然使用多臺機(jī)器，就希望不要把壓力都給一臺機(jī)器，所以需要一種或者多種策略分散高并發(fā)的計算壓力，從而引入負(fù)載均衡，那么到底是如何分發(fā)到不同的服務(wù)器的呢？
砸錢
最初實現(xiàn)負(fù)載均衡采取的方案很直接，直接上硬件，當(dāng)然也就比較貴，互聯(lián)網(wǎng)的普及，和各位科學(xué)家的無私奉獻(xiàn)，各個企業(yè)開始部署自己的方案，從而出現(xiàn)負(fù)載均衡服務(wù)器
HTTP重定向負(fù)載均衡
也屬于比較直接，當(dāng)HTTP請求叨叨負(fù)載均衡服務(wù)器后，使用一套負(fù)載均衡算法計算到后端服務(wù)器的地址，然后將新的地址給用戶瀏覽器，瀏覽器收到重定向響應(yīng)后發(fā)送請求到新的應(yīng)用服務(wù)器從而實現(xiàn)負(fù)載均衡，如下圖所示
優(yōu)點(diǎn)：
簡單，如果是java開發(fā)工程師，只需要servlet中幾句代碼即可
缺點(diǎn)：
加大請求的工作量。第一次請求給負(fù)載均衡服務(wù)器，第二次請求給應(yīng)用服務(wù)器
因為要先計算到應(yīng)用服務(wù)器的 IP 地址，所以 IP 地址可能暴露在公網(wǎng)，既然暴露在了公網(wǎng)還有什么安全可言
DNS負(fù)載均衡
了解計算機(jī)網(wǎng)絡(luò)的你應(yīng)該很清楚如何獲取 IP 地址，其中比較常見的就是 DNS 解析獲取 IP 地址。用戶通過瀏覽器發(fā)起HTTP請求的時候，DNS 通過對域名進(jìn)行即系得到 IP 地址，用戶委托協(xié)議棧的 IP 地址簡歷 HTTP 連接訪問真正的服務(wù)器。這樣不同的用戶進(jìn)行域名解析將會獲取不同的IP地址從而實現(xiàn)負(fù)載均衡
乍一看，和HTTP重定向的方案不是很相似嗎而且還有 DNS 解析這一步驟，也會解析出 IP 地址，不一樣的暴露？每次都需要解析嗎，當(dāng)然不，通常本機(jī)就會有緩存，在實際的工程項目中通常是怎么樣的呢
通過 DNS 解析獲取負(fù)載均衡集群某臺服務(wù)器的地址
負(fù)載均衡服務(wù)器再一次獲取某臺應(yīng)用服務(wù)器，這樣子就不會將應(yīng)用服務(wù)器的 IP 地址暴露在官網(wǎng)了
反向代理負(fù)載均衡
這里典型的就是Nginx提供的反向代理和負(fù)載均衡功能。用戶的請求直接叨叨反向代理服務(wù)器，服務(wù)器先看本地是緩存過，有直接返回，沒有則發(fā)送給后臺的應(yīng)用服務(wù)器處理。
IP負(fù)載均衡
上面一種方案是基于應(yīng)用層的，IP很明顯是從網(wǎng)絡(luò)層進(jìn)行負(fù)載均衡。TCP./IP協(xié)議棧是需要上下層結(jié)合的方式達(dá)到目標(biāo)，當(dāng)請求到達(dá)網(wǎng)絡(luò)層的黑猴。負(fù)載均衡服務(wù)器對數(shù)據(jù)包中的IP地址進(jìn)行轉(zhuǎn)換，從而發(fā)送給應(yīng)用服務(wù)器
注意，這種方案通常屬于內(nèi)核級別，如果數(shù)據(jù)比較小還好，但是大部分情況是圖片等資源文件，這樣負(fù)載均衡服務(wù)器會出現(xiàn)響應(yīng)或者請求過大所帶來的瓶頸
數(shù)據(jù)鏈路負(fù)載均衡
它可以解決因為數(shù)據(jù)量他打而導(dǎo)致負(fù)載均衡服務(wù)器帶寬不足這個問題。怎么實現(xiàn)的呢。它不修改數(shù)據(jù)包的IP地址，而是更改mac地址。應(yīng)用服務(wù)器和負(fù)載均衡服務(wù)器使用相同的虛擬IP
以上介紹了幾種負(fù)載均衡的方式，但是很重要的負(fù)載均衡算法卻沒有設(shè)計，其中包含了輪詢，隨機(jī)，最少連接，下面分別對此進(jìn)行介紹
5 數(shù)據(jù)存儲
公司存在的價值在于流量，流量需要數(shù)據(jù)，可想而知數(shù)據(jù)的存儲，數(shù)據(jù)的高可用可說是公司的靈魂。那么改善數(shù)據(jù)的存儲都有哪些手段或方法呢
數(shù)據(jù)主從復(fù)制
主從復(fù)制比較好理解，需要使用兩個數(shù)據(jù)庫存儲一樣的數(shù)據(jù)。其原理為當(dāng)應(yīng)用程序A發(fā)送更新命令到主服務(wù)器的時候，數(shù)據(jù)庫會將這條命令同步記錄到Binlog中，然后其他線程會從Binlog中讀取并通過遠(yuǎn)程通訊的方式復(fù)制到另外服務(wù)器。服務(wù)器收到這更新日志后加入到自己Relay Log中，然后SQL執(zhí)行線程從Relay Log中讀取次日志并在本地數(shù)據(jù)庫執(zhí)行一遍，從而實現(xiàn)主從數(shù)據(jù)庫同樣的數(shù)據(jù)。
主從復(fù)制可以方便進(jìn)行讀寫分離，可以使用一主多從的方式保證高可用，如果從數(shù)據(jù)庫A掛了，可以將讀操作遷移到從數(shù)據(jù)庫完成高可用。但是如果主數(shù)據(jù)庫掛了咋搞，那就Mysql的主主復(fù)制?？墒遣还苌厦嬲f的那種方式都不是提升它的存儲能力，這就需要進(jìn)行數(shù)據(jù)庫的分片了
數(shù)據(jù)庫分片
將一張表分成若干片，其中每一片都包含一部分行記錄，然后將每一片存儲在不同的服務(wù)器中，這樣就實現(xiàn)一張表存放在多臺服務(wù)器中，哪都有哪些分片存儲的方案？
最開始使用"硬編碼"的方式，此方式從字面上可以理解為直接在代碼中指定。假定表為用戶表，通過ID的奇偶存放在不同的服務(wù)器上，如下圖
這種方式的缺點(diǎn)很明顯，當(dāng)需要增加服務(wù)器的時候，就需要改動代碼，這就不友好了。比較常見的數(shù)據(jù)庫分片算法是通過余數(shù)Hash算法，根據(jù)主鍵ID和服務(wù)器的數(shù)量取模，根據(jù)余數(shù)確定服務(wù)器。
6 搜索引擎
我們使用谷歌瀏覽器的時候，輸入搜索關(guān)鍵字，就會出現(xiàn)搜索到多少條結(jié)果，用時多少，它是如何做到在如此短的時間完成這么大數(shù)據(jù)量的搜索。
先來想第一個問題，全世界這么多網(wǎng)頁在哪里？
互聯(lián)網(wǎng)的存在讓你和我隔著屏幕都知道你多帥。當(dāng)然，每個網(wǎng)頁中都會存在很多其他網(wǎng)頁的超鏈接，這樣構(gòu)成了龐大的網(wǎng)絡(luò)。對于搜索引擎而言，目標(biāo)為解析這些網(wǎng)頁獲取超鏈接，下載鏈接內(nèi)容(過濾)，具體一些說。
將URL存放于池子中，從池子中取出URL模擬請求，下載對應(yīng)的HTML，并存放于服務(wù)器上，解析HTML內(nèi)容時如果有超鏈接URL，檢測是否已經(jīng)爬取過，如果沒有暫存隊列，后面再依次爬取。架構(gòu)圖如下
將獲取的所有網(wǎng)頁進(jìn)行編號并得到網(wǎng)頁集合。然后通過分詞技術(shù)獲得每一個單詞，組成矩陣如下所示
就這樣按照單詞-文檔的方式組織起來就叫做倒排索引了。
Google通過建立<單詞，地址>這樣的文檔，主要搜索到單詞就能定位到文檔的地址列表，然后根據(jù)列表中文檔的編號就展現(xiàn)文檔信息從而實現(xiàn)快速的檢索。
如果搜索出來結(jié)果很多，Google是如何能更精準(zhǔn)的將我們需要的信息呈現(xiàn)給我們呢。它很明顯有個排序功能，那是如何排序的？
Google使用了一種叫做"PageRank"的算法，通過計算每個網(wǎng)頁的權(quán)重，并按照權(quán)重排序，權(quán)重高的自然就在顯示在前面，那問題來了，為啥權(quán)重高的，排在前面的通常就是用戶所需要的呢？這就得了解下pagerank算法了
在pagerank中，如果網(wǎng)頁A包含網(wǎng)頁B說明A認(rèn)可B，即投一票。如下圖ABCD四個網(wǎng)頁所示，箭頭代表超鏈接的方向，比如A->B代表A網(wǎng)頁包含B的超鏈接
怎么計算的？
ABCD 初始值都為1，然后根據(jù)關(guān)系計算權(quán)重。比如此時B包含了AD兩個網(wǎng)頁，那么權(quán)重1被分為兩個1/2分別給A和D，此時A包含BCD，那么此時A頁面新的權(quán)重為1/2 + 1/3 + 1 = 11/6
pagerank 值越受推薦，代表用戶越想看到?；诿總€網(wǎng)頁的 pagerank 值對倒排索引中的文檔列表排序，靠前者則是用戶想看到的文檔。
這種是因為超鏈接，引入權(quán)值的方式排序。還有其他諸如對于商品售賣次數(shù)排序或者電影點(diǎn)贊或評價分?jǐn)?shù)排序。還有通過關(guān)鍵字查找，希望找到和搜索詞相關(guān)，這個時候可能就會采用詞頻TF進(jìn)行排序，詞頻代表所查詞和文檔的相關(guān)程度
比如我們搜索"Java后端"出現(xiàn)的結(jié)果以"后端"的相關(guān)技術(shù)。
在大部分的應(yīng)用中都會涉及到搜索引擎技術(shù)，技術(shù)龐大且復(fù)雜，希望各位老鐵根據(jù)自身情況搜索相關(guān)所需學(xué)習(xí)，校招面試中不出現(xiàn)盲點(diǎn)即可。
7 微服務(wù)
技術(shù)的引進(jìn)一定是想解決某個痛點(diǎn)。我不希望在一個系統(tǒng)中，一小點(diǎn)改動就影響到全局，希望各個功能模塊拆分清晰，不管是測試還是運(yùn)維都能節(jié)省更多的時間。
那么單體的架構(gòu)出現(xiàn)了哪些問題？
代碼分支管理困難
各個部門分別完成各自的任務(wù)，但是最后需要 merge 在一起成為整個系統(tǒng)，merge過程經(jīng)歷的人都知道，問題是真XX多。所以不再是996
新增功能麻煩
隨著項目的效益越來越好，用戶的需求也更多，招聘的人可能更多，對于新手來說上來是一臉懵逼的，老員工忙的要死，新員工成為了摸魚專家
耗盡連接
用戶的增多，每個應(yīng)用都得和數(shù)據(jù)庫連接，給數(shù)據(jù)庫的連接造成太大的壓力甚至耗盡連接
微服務(wù)
“微"-------微微一笑很傾城，微笑，微小。顧名思義，講一個大的系統(tǒng)，拆分為一個個小的服務(wù)，分別對各個小服務(wù)進(jìn)行管理。這樣說感覺太不專業(yè)了，專業(yè)點(diǎn)
大應(yīng)用拆分為小模塊
小模塊不屬于集群中
通過遠(yuǎn)程調(diào)用的方式依賴各個獨(dú)立的模塊完成業(yè)務(wù)的處理
這些小的模塊就叫做------微服務(wù)，整體也就是所謂的微服務(wù)架構(gòu)。
既然拆分成了小服務(wù)，這么多小服務(wù)怎么協(xié)調(diào)成為一個問題，甚至都不知道怎么掉這個服務(wù)，所以在微服務(wù)的整體架構(gòu)中出現(xiàn)了注冊中心，誰需要調(diào)用使用提供的接口即可。如下圖所示
從上圖我們能知道主要是三個概念
服務(wù)提供者
微服務(wù)的具體提供者，其他微服務(wù)通過接口調(diào)用即可
服務(wù)消費(fèi)者
對應(yīng)于服務(wù)提供者，按照提供者接口編程即可。這么輕松的嘛，當(dāng)然很多細(xì)節(jié)。舉個例子，注明的dubbo服務(wù)框架，服務(wù)接口通過Dubbo框架代理機(jī)制訪問Dubbo客戶端，客戶端通過服務(wù)接口聲明去注冊中心查看有哪些服務(wù)器，并將這服務(wù)器列表給客戶端?？蛻舳巳缓蟾鶕?jù)負(fù)載均衡策略選擇其中一個服務(wù)器，通過遠(yuǎn)程調(diào)用的方式發(fā)送服務(wù)調(diào)用。那么使用微服務(wù)需要注重哪幾點(diǎn)
不要拿工具硬上需求，結(jié)合業(yè)務(wù)也許會更佳
8 高可用
高可用，意味著一臺機(jī)器掛了沒事，其他機(jī)器可以照常工作，用戶體驗一樣倍棒，用戶壓根就不知道，臥槽，你居然升級了系統(tǒng)，我居然一點(diǎn)感受都沒有。那么高可用總有個標(biāo)準(zhǔn)吧，是百分之80就行還是90？
一個系統(tǒng)突然不能訪問的原因很多，
硬件故障
數(shù)據(jù)庫宕機(jī)
磁盤孫歡
bug
光纜斷了
可用性指標(biāo)
通過多少個9來衡量，比如大寶系統(tǒng)可用性為4個9，意味著是99.99%，說明它的服務(wù)保證運(yùn)行時間只有0.01不可用。
高可用涉及到技術(shù)成本和設(shè)備成本，不是說高可用值越高越好，而是根據(jù)具體工具具體場景而定，這里分享一些高可用策略
冗余備份
任何一個服務(wù)都有備份，就反復(fù)我們都會對我們筆記本電腦相關(guān)文件進(jìn)行備份一樣，以防萬一。即使一臺服務(wù)器掛了，可以很快的切換以致于讓用戶不會覺得"這系統(tǒng)怎么這么渣"。
負(fù)載均衡
使用多臺服務(wù)器分擔(dān)一臺服務(wù)器的壓力，滿足高并發(fā)的請求。怎么實現(xiàn)的呢，應(yīng)用程序會有一個心跳檢測/健康檢查機(jī)制，如果發(fā)現(xiàn)不妥切換即可。上面提到的數(shù)據(jù)庫主主復(fù)制也是高可用的方案之一，技術(shù)思想果然是相通的
限流降級
我們的目標(biāo)不是沒有蛀牙，而是希望整個系統(tǒng)不要掛掉。限流是對部分請求進(jìn)行丟棄處理，保證大部分的用戶可以正常的請求完成任務(wù)。
降級：
可以屏蔽部分當(dāng)前看來不是很有用的任務(wù)。比如電商系統(tǒng)做秒殺活動的過程中，確認(rèn)收貨功能給予的壓力挺大，暫時看來并不是核心任務(wù)，而且系統(tǒng)到期也會自動確認(rèn)收貨，所以暫時關(guān)閉，將系統(tǒng)的資源留給準(zhǔn)備下單，放購物車的太太們
異地多活
有時候我在想要是地震，火災(zāi)等自然災(zāi)害發(fā)生的時候，很多系統(tǒng)的數(shù)據(jù)怎么辦啊。想多了撒，大些的系統(tǒng)多會在各個地方部署數(shù)據(jù)中心，采用異地多活的多機(jī)房策略。用戶可以訪問任何數(shù)據(jù)中心，那問題來了，用戶的請求是如何到達(dá)不同的機(jī)房去的？
域名解析
9 安全性
公司中的數(shù)據(jù)財產(chǎn)，其重要程度不言而喻。系統(tǒng)的健壯性和安全性是保證系統(tǒng)持久運(yùn)行的基礎(chǔ)。不要因為數(shù)據(jù)泄露才去關(guān)注安全問題。
也許說到安全問題，首先想到的是“用戶名密碼”泄漏，數(shù)據(jù)庫被脫褲導(dǎo)致數(shù)據(jù)泄露，hack直接拿到用戶的敏感信息，所以我們通常有哪些手段或方法來盡全力的抵抗hack嘞，辦法總比問題多嘛
數(shù)據(jù)加解密
通過對用戶密碼，身份證等敏感數(shù)據(jù)加密是常用方法。加密方法通常分為：單向散列加密，對稱加密和非對稱加密。
所謂單向散列加密，主要體現(xiàn)在單向二字，意味著對明文加密后是不可以解密，你即使是給明文加密的加密者，也無法通過密文知道其明文是什么，即加密單向，不支持解密。說的這么絕對？這么無敵？那只是理論上而已，常用的MD5算法就是大象散列加密，我們完全可以通過彩虹表等方式進(jìn)行破解。怎么破解？說個簡單的道理，我們設(shè)置密碼的時候，通常會使用生日？手機(jī)號？什么love？什么520？，這些組合是有限的，我們就可以建立一個比如生日和密文的映射表，然后通過XX彩虹表就可得到密碼明文
所以，通常的情況，使用單向散列加密的時候需要加一點(diǎn)鹽，這樣一來，hack拿到密文，不知道鹽，無法建立彩虹表，就更難還原明文。
應(yīng)用場景：通常應(yīng)用在用戶密碼加密。其加密和校驗過程如下
我們通過上圖來回顧一下一個網(wǎng)站的注冊登錄模塊中的用戶部分，用戶注冊需要輸入用戶名和密碼，我們一般不會將裸露的將密碼直接存放在數(shù)據(jù)庫，不然被脫褲直接算裸奔。所以，用戶輸入密碼，應(yīng)用服務(wù)器獲得密碼后，調(diào)用單向散列加密算法，將加密的密文存放于數(shù)據(jù)庫，用戶下一次登錄的時候，用戶依然會輸入密碼，只是到了Web服務(wù)器后，Web服務(wù)器會對輸入的密碼再進(jìn)行一次單向散列加密，然后和數(shù)據(jù)庫中取出來的密文進(jìn)行對比，如果相同，則用戶的驗證成功，通常這樣的方式可以保證用戶密碼的安全性，當(dāng)然如果加一點(diǎn)鹽，會增加破解的難度。
對稱加密
對稱加密是通過一個加密算法和密鑰，對一段明文進(jìn)行加密后得到密文，然后使用相同的密鑰和對應(yīng)的解密算法進(jìn)行解密得到明文。
舉個例子，我們不會將銀行卡卡號，有效期等直接存儲在數(shù)據(jù)庫，而是會通過先加密，然后存儲于數(shù)據(jù)庫。使用的時候必須對密文進(jìn)行解密還原出明文。這個時候使用對稱加密算法，存儲的時候加密算法進(jìn)行加密，使用的時候解密算法解密
非對稱加密
非對稱加密是說使用一個加密算法和一個加密秘鑰進(jìn)行加密得到密文，但是在解密出明文的時候，其加解密密鑰和加密密鑰不同，通常加密密鑰叫做公鑰，解密密鑰叫做私鑰。
其實我們常用的 HTTPS 即是非對稱加密的應(yīng)用場景。用戶在客戶端進(jìn)行通訊的時候，對數(shù)據(jù)使用的加密密鑰和加密算法進(jìn)行加密得到密文，到了服務(wù)端以后，使用解密密鑰和算法進(jìn)行解密得到明文。但是非對稱消耗的資源比較多，所以HTTPS不是每次請求響應(yīng)都采用非對稱加密，而是先利用非對稱加密，在客戶單和服務(wù)器之間交換一個對稱加密的密鑰，然后每次的請求響應(yīng)再使用對稱加密。綜上，使用費(fèi)對稱加密保證對稱加密迷藥的安全，使用對稱加密密鑰保證請求響應(yīng)數(shù)據(jù)的安全。
HTTP攻擊與防護(hù)
HTTP明文協(xié)議，咋們通過嗅探工具就可以清晰查看會話內(nèi)容，這也是hack攻擊門檻最低的方式。很常見的也就是SQL注入和XSS攻擊
SQL注入是攻擊者在提交請求參數(shù)的時候，包含了惡意的SQL腳本
server處理計算后向數(shù)據(jù)庫提交的SQL如下
Select id from users where username='Mike';
如果是惡意攻擊，提交的HTTP請求如下
http://www.a.com?username=Mike';drop table users;--
此時最終生成的SQL是
Select id from users where username='Mike';drop table users;--';
查詢完就直接給刪除表了。怎么防護(hù)？比較常用的解決方案是使用PrepareStaement預(yù)編譯，先將SQL交給數(shù)據(jù)庫生成執(zhí)行計劃，后面hack不管提交什么字符串也只能交給這個執(zhí)行計劃執(zhí)行，不會生成新的SQL，也就不會被攻擊啦。
XSS攻擊
跨站點(diǎn)腳本攻擊，攻擊者通過構(gòu)造惡意的瀏覽器腳本文件，使其在其他用戶的瀏覽器運(yùn)行進(jìn)而進(jìn)行攻擊。假設(shè)小A將含有惡意腳本的請求給360服務(wù)器，服務(wù)器將惡意的腳本存儲在本地的數(shù)據(jù)庫，當(dāng)其他正常用戶通過這個服務(wù)器瀏覽信息的時候，服務(wù)器就會讀取數(shù)據(jù)庫中含有惡意腳本的數(shù)據(jù)并呈現(xiàn)給用戶，在用戶正常使用瀏覽器的時候達(dá)到攻擊的目的。
防御：
比較常見的是在入口處對危險的請求比如drop table等進(jìn)行攔截，設(shè)置一個Web應(yīng)用防火墻將危險隔離。
10 大數(shù)據(jù)
其實在上面提到的分布式中就有涉及大數(shù)據(jù)相關(guān)知識。無外乎是數(shù)據(jù)量越來越大，我們?nèi)绾伪M可能使用較低的成本存儲更多的數(shù)據(jù)，更公司企業(yè)帶來更好的利潤。上面說過分布式緩存，負(fù)載均衡等技術(shù)，其共同特點(diǎn)是如何抵抗高并發(fā)的壓力，而這里的大數(shù)據(jù)技術(shù)主要談?wù)摰氖侨绾螡M足大規(guī)模的計算。
通過對數(shù)據(jù)的分析，進(jìn)而發(fā)掘海量數(shù)據(jù)中的價值，這里的數(shù)據(jù)包含數(shù)據(jù)庫數(shù)據(jù)，日志信息，用戶行為數(shù)據(jù)等等。那么這么多不同類型的數(shù)據(jù)，怎么去存儲呢
分布式文件存儲 HDFS 架構(gòu)
如何將數(shù)以萬計的服務(wù)器組成統(tǒng)一的文件存儲系統(tǒng)？其中使用Namenode服務(wù)器作為控制塊，負(fù)責(zé)元數(shù)據(jù)的管理(記錄文件名，訪問權(quán)限，數(shù)據(jù)存儲地址等)，而真正的文件存儲在DataNode中。
Mapreduce
大量的數(shù)據(jù)存儲下來的目的是通過相應(yīng)的算法進(jìn)行數(shù)據(jù)分析，獲得通過深度學(xué)習(xí)/機(jī)器學(xué)習(xí)進(jìn)行預(yù)測，從而獲取有效的價值，這么大的文件，我們不可能將HDFS當(dāng)做普通的文件，從文件中讀取數(shù)據(jù)然后計算，這樣子不知道算到何時何地。
大數(shù)據(jù)處理經(jīng)典的處理框架即MapReduce，分為Map和Reduce兩個階段，其中一個Map過程是將每個服務(wù)器上啟動Map進(jìn)程，計算后輸出一個
下面以WordCount統(tǒng)計所有數(shù)據(jù)中相同的詞頻數(shù)據(jù)為例，詳細(xì)看看Map和Reduce的過程。
在這個例子中，通過對value中的1組成的列表，reduce對這些1進(jìn)行求和操作從而得到每個單詞的詞頻。代碼實現(xiàn)如下
public?class?WordCount?{
????????// Mapper四個參數(shù)：第一個Object表示輸入key的類型；第二個Text表示輸入value的類型；第三個Text表示表示輸出鍵的類型；第四個IntWritable表示輸出值的類型。map這里的輸出是指輸出到reduce
????public?static?class?doMapper?extends?Mapper<Object,?Text,?Text,?IntWritable>?{
????????public?static?final?IntWritable?one?=?new?IntWritable(1);//這里的IntWritable相當(dāng)于Int類型
????????public?static?Text?word?=?new?Text();//Text相當(dāng)于String類型
????????//?map參數(shù)，將處理后的數(shù)據(jù)寫入context并傳給reduce
????????protected?void?map(Object?key,?Text?value,?Context?context)?throws?IOException,?InterruptedException?{
????????????//StringTokenizer是Java工具包中的一個類，用于將字符串進(jìn)行拆分??
????????????StringTokenizer?tokenizer?=?new?StringTokenizer(value.toString(),?"???");
????????????//返回當(dāng)前位置到下一個分隔符之間的字符串??
????????????word.set(tokenizer.nextToken());
????????????//將word存到容器中，記一個數(shù)
????????????context.write(word,?one);
????????}
????}
????//參數(shù)同Map一樣，依次表示是輸入鍵類型，輸入值類型，輸出鍵類型，輸出值類型。這里的輸入是來源于map,所以類型要與map的輸出類型對應(yīng)?。
????public?static?class?doReducer?extends?Reducer<Text,?IntWritable,?Text,?IntWritable>?{
????????private?IntWritable?result?=?new?IntWritable();
????????@Override
????????protected?void?reduce(Text?key,?Iterable?values,?Context?context)
????????????????throws?IOException,?InterruptedException?{
????????????int?sum?=?0;
????????????//for循環(huán)遍歷，將得到的values值累加
????????????for?(IntWritable?value?:?values)?{
????????????????sum?+=?value.get();
????????????}
????????????result.set(sum);
????????????context.write(key,?result);//將結(jié)果保存到context中，最終輸出形式為"key"?+?"result"
????????}
????}
????public?static?void?main(String[]?args)?throws?IOException,?ClassNotFoundException,?InterruptedException?{
????????System.out.println("start");
????????Job?job?=?Job.getInstance();
????????job.setJobName("wordCount");
????????Path?in?=?new?Path("hdfs://***:9000/user/hadoop/input/buyer_favorite1.txt");//設(shè)置這個作業(yè)輸入數(shù)據(jù)的路徑(***部分為自己liunx系統(tǒng)的localhost或者ip地址)
????????Path?out?=?new?Path("hdfs://***:9000/user/hadoop/output/wordCount");????????//設(shè)置這個作業(yè)輸出結(jié)果的路徑
????????FileInputFormat.addInputPath(job,?in);
????????FileOutputFormat.setOutputPath(job,?out);
????????job.setJarByClass(WordCount.class);//?設(shè)置運(yùn)行/處理該作業(yè)的類
????????job.setMapperClass(doMapper.class);//設(shè)置實現(xiàn)了Map步的類
????????job.setReducerClass(doReducer.class);//設(shè)置實現(xiàn)了Reduce步的類
????????job.setOutputKeyClass(Text.class);//設(shè)置輸出結(jié)果key的類型
????????job.setOutputValueClass(IntWritable.class);//設(shè)置輸出結(jié)果value的類型
????????////執(zhí)行作業(yè)
????????System.exit(job.waitForCompletion(true)???0?:?1);
????????System.out.println("end");
????}
}
那么這個map和reduce進(jìn)程是怎么在分布式的集群中啟動的呢？
上圖比較清晰地闡述的整個過程，再描述一波。MR中主要是兩種進(jìn)程角色，分別為 JobTracke r和 TaskTracker 兩種，JobTracker在集群中只有一個，而 TaskTracker 存在多個，當(dāng) ?JobClient 啟動后，往 JobTracker 提交作業(yè)，JobTracker查看文件路徑?jīng)Q定在哪些服務(wù)器啟動 Map 進(jìn)程，然后發(fā)送命令給 TaskTracker，告訴它要準(zhǔn)備執(zhí)行任務(wù)了，TaskTracker收到任務(wù)后就會啟動 TaskRunner 下載任務(wù)對應(yīng)的程序。map計算完成，TaskTracker對map輸出結(jié)果 shuffer 操作然后加載 reduce 函數(shù)進(jìn)行后續(xù)計算，這就是各個模塊協(xié)同工作的簡單過程。
Hive
上述過程還是比較麻煩，我們能不能直接寫SQL，然后引擎幫助我們生成mapreduce代碼，就反復(fù)我們在web開發(fā)的時候，不直接寫SQL語句，直接交給引擎那么方便，有的，它就是HIVE
舉個例子
那么使用MR的計算過程完成這條SQL的處理
Spark
Spark是基于內(nèi)存計算的大數(shù)據(jù)并行計算框架。基于此說說上面hadoop中組件的缺點(diǎn)
磁盤IO開銷大。每次執(zhí)行都需要從磁盤讀取并且計算完成后還需要將將中間結(jié)果存放于磁盤
表達(dá)能力有限。大多數(shù)計算都需要轉(zhuǎn)換為Map和Reduce兩個操作，難以描述復(fù)雜的數(shù)據(jù)處理
spark優(yōu)點(diǎn)
編程模型不限于map和reduce，具有更加靈活的編程模型
spark提供內(nèi)存計算，帶來更高的迭代運(yùn)算效率且封裝了良好的機(jī)器學(xué)習(xí)算法
采用了基于圖DAG的任務(wù)調(diào)度機(jī)制
Flink
Flink是大數(shù)據(jù)處理的新規(guī)，發(fā)展速度之快，這兩年也相繼出現(xiàn)中文資料。作為流式數(shù)據(jù)流執(zhí)行引擎，針對數(shù)據(jù)流的分布式計算提供數(shù)據(jù)分布，數(shù)據(jù)通信以及容錯機(jī)制等功能。同時Flink也提供了機(jī)器學(xué)習(xí)庫，圖計算庫等。
嘮嗑
對于之前從事c/c++開發(fā)的我，很多時候是Linux的開發(fā)。在學(xué)校又沒怎么接觸系統(tǒng)性的項目，更不知道后端技術(shù)的博大進(jìn)深，可能文中涉及的也就一部分，不過希望還在學(xué)校的小伙伴可以知道有這些東西，然后通過強(qiáng)大的搜索引擎，給自己個比較明確的方向，也許會少走點(diǎn)彎路，這周的文章就到這了，goodbye！
你的點(diǎn)贊和在看是我前進(jìn)的動力，Thanks！
完
? ? ? ?
???覺得不錯，點(diǎn)個在看~
