【進擊的前端】node開發者必知後端知識圖譜（一）

若是你是一個半路入門的前端工程師，只會使用javascript 寫一些頁面, 有一天聽聞了node.js 能夠開發後端，因而興致勃勃的去用node.js搞後端。

可是你只懂得前端的知識點，面對後端的各中高大上的知識點，好比說數據庫，冷備份等，陷入了恐懼和睦餒。

我也是這樣。

這種狀況下，咱們須要學習不僅僅是node, 而是整個後端的海洋。所以我但願這個《寫給node開發者看的後端知識圖譜》能夠幫助到你。

在這個系列裏面，不會介紹任何有關node的知識點，若是你想探討node相關，請移步個人《成爲自信的node.js開發者》系列。

有任何問題和建議，均可以聯繫我，我會虛心改正滴~

後端服務的架構模式

咱們在和後端同窗打交道的過程當中，常常會聽到各類各樣高大上的術語，這就須要咱們對後端的架構有一個大概的瞭解。

後端技術在發展的過程當中，不少網站提出了本身的解決方案，這些解決方案被不一樣的網站反覆使用，從而就造成了大型網站架構模式。

分層

分層是橫向的劃分。大型網站，後端系統分爲 應用層，服務層，數據層。

應用層： 處理具體的業務邏輯

服務層： 提供一些服務化的接口，好比說發券，發紅包

數據層： 好比說數據庫，緩存，文件等。

分層結構的挑戰

分層結構必需要劃分合理

禁止跨層次調用（好比說，應用層直接調用數據層）

禁止逆向調用（好比說，數據層調用服務層）

三層結構能夠部署在同一臺機器上，也能夠部署在不一樣的服務器上。

分割

分割是對縱向的劃分。大型網站有不少功能，好比說，搜索，購物車，推薦。這些小應用能夠分割爲不一樣的模塊，交給不一樣的團隊來維護。

分割能夠把不一樣的業務放在不一樣的機器上，好比說，交易等對性能要求比較高的模塊能夠放在更高性能的機器上，而評論等模塊則能夠視狀況降級。

分佈式

分佈式意味着，把不一樣的後端服務部署在不一樣的服務器上。

分佈式遇到的挑戰

分佈式不一樣的機器之間，經過網絡調用，性能會有影響

服務器越多，宕機的可能性越高

保持數據一致性比較困難

集羣

集羣是，把不一樣的服務器部署相同的設備。不一樣的服務器之間會負載均衡。

由於服務器集羣有更多的服務器提供相同的服務，因此併發性更高，當訪問量飆升時，只須要加機器就能夠了。

當某臺機器發生故障時，只須要負載均衡，或者失效轉移都會把流量打到其餘服務器上，使得用戶仍能夠正常訪問。

緩存

緩存是改善性能的第一手段。在後端的世界中，緩存幾乎無處不在。

緩存主要包括下面：

一、CDN

CDN， 內容分發網絡（content delivery network), 由遍及全國的高性能加速節點構成。當您的用戶向您的某一業務內容發起請求時，請求會被調度至最接近用戶的服務節點.

CDN 出現的緣由

1. 用戶與業務服務器地域間物理距離較遠，傳輸延時較高且不穩定；

2. 請求須要運營商之間進行互聯轉發。

3. 業務服務器網絡帶寬、處理能力有限，當接收到海量用戶請求時，會致使響應速度下降、可用性下降。

CDN 請求的全流程

1. 假設發起一個請求爲http://www.test.com/1.jpg，須要會先向 Local DNS 發起域名解析請求。

2. 當local DNS 解析 www.test.com 時，發現該域名已經配置了CNAME 指向 www.test.com.cdn.dnsv1.com, 解析請求會發送至 騰訊雲，會爲請求分配最佳節點 IP

3. Local DNS 獲取 Tencent DNS 返回的解析 IP

4. 用戶獲取解析 IP

5. 用戶向獲取的 IP 發起對資源 1.jpg 的訪問請求

6. 若該 IP 對應的節點緩存有 1.jpg，則會將數據直接返回給用戶（10），此時請求結束。若該節點未緩存 1.jpg，則節點會向業務源站發起對 1.jpg 的請求（六、七、8），獲取資源後，結合用戶自定義配置的緩存策略，將資源緩存至節點（9），並返回給用戶（10），此時請求結束。

二、 反向代理

反向代理部署在服務器以前，若是發現有緩存的靜態資源，則直接返回靜態資源，無需訪問服務器。

三、分佈式緩存

如今大型網站中，緩存每每很是巨大，一個機器承受不住，因此除了本地緩存，還有分佈式緩存，將緩存存放在一個專門的集羣中，應用程序經過網絡訪問緩存數據。

異步

做爲一個前端，咱們確定對異步不陌生。異步是典型的生產消費模式，二者不直接調用，而是經過消息來交流。

異步帶來不少好處：

提升系統可用性

消費方出現了堆積，不影響生產方的邏輯。

好比說，以前，咱們的用戶支付和發券是寫在一塊兒的，不少時候，用戶支付成功了，可是發券由於商家配置的券有問題，致使發券失敗，從而返回給用戶支付失敗。後來改爲，【發券邏輯】去訂閱【支付成功】的消息，【發券邏輯】失敗，不會影響用戶支付成功。
複製代碼

加快了網站的響應速度。

生產方處理完邏輯，只須要發出消息，就直接返回響應。
複製代碼

削平峯值

網站有高負載的時候，也有低谷的時候。使用消息隊列，將忽然增長的訪問請求數據放入消息隊列中，等待消費者服務器依次處理，壓力就會小不少。
複製代碼

後端服務的核心要素

高性能

性能是很重要的一個方面，從前端到後端，每個環節上均可以有優化。

對於前端方面，性能優化能夠瀏覽個人博客《前端性能探究》。

對於後端方面，可使用本地緩存或者分佈式緩存，能夠組建集羣，可使用多線程，能夠改善內存管理，能夠對數據庫增長索引、緩存等等。

上述方法，不用着急，下文會深刻講到。

可用性

咱們追求服務高可用性，說白了就是後端服務不宕機。

保持運行環境的高可用，主要方法是，把咱們的應用部署在多個服務器上，數據庫備份在多個服務器上。當某一個機器宕機了，只須要把請求切換到其餘服務器上便可。

上述有一點要求，應用服務器上不能存儲會話信息。

對於開發環境的高可用，須要引入自動化發佈，自動化測試，灰度發佈等手段，減小把bug引入到線上的可能性

伸縮性

所謂的伸縮性，就是往集羣裏面新增長一臺機器是否方便。

對於應用服務器集羣，只要服務器上不保存數據，全部的服務器都是對等的。

對於緩存服務器集羣，新加入的機器會讓緩存路由失效，從而致使緩存失效，大量的請求打到數據庫上，從而致使網站崩潰。因此要改善路由算法。

對於關係型數據庫，雖然能夠數據複製，主從熱備，可是很難作到大規模集羣的可伸縮，所以關係數據庫經過路由分區等手段。

對於NoSql數據庫，天生就是爲伸縮性而生，則支持度比較好。

拓展性

所謂的拓展性，就是，可以快速新增一個新的業務線，而不會對現有的業務有很深的耦合，其餘的業務線不會進行牽連或改動。

主要手段有兩點： 事件驅動架構和分佈式服務

事件驅動架構，主要是經過消息隊列來實現的，將消息產生和消息處理解耦開。好比說，咱們新增一個618臨時營銷活動，當用戶下單成功後，給用戶發放某種卡片。咱們不是改動用戶下單的代碼，而是監聽用戶下單的消息隊列。

分佈式服務，是經過將業務代碼和可複用的服務抽離開來。好比說，公司裏面有A,B,C三個業務線，都須要對用戶發放店鋪券，就能夠提供java的服務化接口，咱們node 的業務經過 dubbo 來調用。

安全性

安全性保護網站不受惡意攻擊。

小結

恭喜你，看到了這裏。上面的性能， 高可用， 伸縮性， 拓展性， 安全性 是對接下來內容的提綱挈領。若是你有任何的疑問，請放心大膽的跳過去，我會在後面的文章細細介紹。