試着探索高併發下的系統架構面貌

前言

之前端入行編碼，可是對後端架構也很是感興趣。一直以來都以爲那些作到在洪水流量面前保持系統提供高可靠，高性能的服務的小哥哥們都很厲害。總想着去學習一番，所以大半年來不斷學習後端相關的知識，試圖去理解高併發架構的面貌。

固然，本文僅僅是試着探索而已，並無相關實踐的經歷，也只能從理論的角度去推演，從現有可參考的資料中去堆砌一個在我看來合理的架構方案。限於做者水平有限，所以不免行文不免有誤，亦或是對整個系統的理解上理想化了，歡迎各位指出不足。同時，本文不會詳實的闡述提到的每一個細節，由於自己本身對細節的把控也不到位，另外也是但願你們可以在本文的基礎上本身去詳細瞭解這些技術。

核心技術點

在做者看來，本文偏向於考慮如何作到高併發和高可用，所以一些性能優化的點則可能不做爲重點言及，一是由於性能優化點過於繁多，會形成篇幅過長，另外也是由於具體的細節做者也未經實踐不敢在這裏細究。所以，列出如下這些在做者看來最爲重要的核心技術點。

1. 智能DNS解析調度

2. 負載均衡

3. 消息服務

4. CDN配合對象存儲服務

5. Redis緩存

6. 分庫分表

經過橫向疊加機器解決併發突增問題，這是的架構設計的一項最基本要求。

技術詳解

智能DNS解析調度

在全部用戶的都是經過同一域名www.qq.com獲取服務的狀況下，想要將流量分散到多個負載均衡節點，必需要依賴DNS的解析。

DNS解析最簡單的能夠經過添加多條A記錄將域名映射到多個IP地址來達到分流的目的。看到許多資料，每每只提到這個層面，而後拋出了問題：調度算法簡單，每每是動態輪詢，而部署的機器之間可能會存在性能差別或者當下健康情況不一樣,簡單的輪詢並不能知足實際需求。
所以，通過一番搜索，發現了dnspod這樣的第三方DNS解析服務提供設置權重，這樣一來就能夠針對機器的情況不一樣進行不一樣的權重配比。經過配比權重，基本上，就能夠完成DNS解析的負載均衡了。

可是做者一直好奇，這些第三方的DNS解析廠商如何工做，所以在查閱資料以後，將原理總結以下：
在DNS解析中，咱們購買域名後，能夠設置對應域名的權威DNS解析服務器。以訪問www.qq.com.爲例，DNS解析首先會遞歸查找對應域名的IP地址。一直查找到根域.,根域讓咱們去問com.的權威服務器, 以後去問qq.com.的權威服務器，再問www.qq.com.的權威服務器，這時候咱們終於找到了www.qq.com.的權威服務器ns-edu1.qq.com.與ns-edu2.qq.com.，權威服務器通過一系列算法最後給了咱們請求域名的IP地址。

購買域名後，域名每每被默認的設置爲平臺默認的DNS解析服務器上，咱們也能夠對其進行更改，好比設置到dnspod，並本身在dnspod進行配置。對於一些大廠，也能夠經過自行架設DNS解析服務器並編寫自定義的規則進行處理來達到高度定製化的管控。常見的管控以下:

• 經過識別用戶是電信網仍是聯通網，將對應的網絡內部署的服務器地址返回，以免用戶請求的跨網，跨網會帶來必定的網絡傳輸性能的降低

• 識別用戶歸屬地，分配到最近的服務器以減小網絡傳輸的距離

最後須要注意的是DNS解析的更改的實時性存在很大的限制，由於各地ISP服務商刷新域名DNS的時間不一致，因此致使解析在全球生效通常須要0-72小時。

負載均衡

這裏的負載均衡只特指負載均衡的節點。DNS解析後的IP地址即對應負載均衡的IP地址，請求到達負載均衡節點後，將由負載均衡節點對請求進行轉發到相應的http應用處理服務器。負載均衡節點能夠設置相應轉發的策略，例如最簡單經過將用戶的ip來hash到不一樣的http應用服務器來分散壓力，這樣的好處是能夠保證每次請求都打到同一臺機器上。另外負載均衡節點也會監聽應用服務器，而且及時隔離掉異常狀態的服務器，在服務器恢復健康後，再次接入。

經過負載均衡節點接入多臺應用服務器，當遇到促銷等場景時，動態增長應用服務器便可知足需求。

此外，咱們還須要確保負載均衡節點的高可用性。經過VRRP(Virtual Router Redundancy Protocol, 虛擬路由冗餘協議)保證負載均衡節點的高可用性。原理以下：
負載均衡節點每每由2臺機器經過VIP(virtual IP，負載均衡向客戶端提供服務的 IP 地址)技術向用戶提供服務，兩臺機器同時只有一臺機器保持在active的狀態，兩臺機器之間經過Keepalived技術互相監聽對方的狀態，若是active的機器宕機，則另外一臺機器自動切換到active的狀態，經過冗餘來保證負載均衡節點的高可用性。

消息服務

項目簡單的時候，咱們每每會把全部的代碼耦合在一塊兒，同步執行。諸如購買一件商品，執行下單，減庫存，支付等等操做同步運行完成以後再將請求返回，形成單個請求駐留時間過長，堆積大量的請求，形成應用服務器的不可用。

經過消息服務，咱們能夠將這些服務解耦，而且經過將同步邏輯異步化，減小請求的駐留，從而減輕併發壓力。用戶操做產生消息，再經過創建另外的消費者進行消費。

咱們還能夠根據狀況，設置消費者的策略，好比，經過拉取消息而非推送消息，來保證不管前端併發多大的流量，均可以在消息服務這裏熨平，消費者根據本身的能力拉取，不至於超負荷形成服務不可用。

CDN配合對象存儲服務

CDN這個技術基本上寫代碼的人都知道，說優化的時候你們都能提到，但是過往也一直沒有真正的設置過CDN的使用，此次專門去騰訊雲上查看了下配置，並瞭解了下策略。

首先，用戶準備一個域名用來做爲CDN的分發域名，這裏好比說qian-img.tenpay.com。設置qian-img.tenpay.com的別名CNAME爲CDN廠商給咱們提供的域名好比說tenpay.com.CDN.dnsv1.com，以後還須要設置源站(ip/域名)即你靜態文件實際存放的機器地址。這樣對qian-img.tenpay.com的請求都會打到對應的CDN域名上,CDN域名也會解析到最近的CDN節點上，而且遞歸查找資源，相似於DNS解析。當沒有找到資源的時候，纔會去用戶設置的源站IP上去獲取資源。這樣對本身的靜態資源源站的性能要求會大大減小，系統性能也會大大提升。

而源站的資源管理上也推薦使用對象存儲服務，相比與使用本身搭建服務器的文件系統。對象存儲服務，也能夠存儲任意形式的非結構化的數據，而且高可用、高穩定、強安全。

Redis緩存

Redis是基於內存的鍵值對數據庫，IO性能遠遠高於基於文件系統的數據庫。對一個接口的請求的多個請求過程當中，每每數據並無產生變化，若是每次都去數據庫中去查詢，則會形成數據庫壓力過大，同時接口性能降低，經過將數據緩存在Redis這樣的內存鍵值對數據庫中能夠大大提升系統的性能。

分庫分表

經常使用的數據庫諸如MySQL都是基於文件系統，而文件系統是基於磁盤，整個系統中，磁盤的IO能夠說是最慢的一個地方。所以數據庫每每是系統的性能瓶頸，分庫分表，是最經常使用的策略。

單個數據庫存在併發鏈接數上線單位是百，所以面對海量的請求，是無能爲力的。所以須要經過分庫來將壓力分擔到不一樣的數據庫機器上，以承載高併發的請求。分庫的策略能夠簡單的根據用戶UID的尾號進行水平拆分，同時分庫後，單個數據庫的記錄數也減小了，讀寫性能也獲得提升。

寫在最後

大半年前，在公司聽後端童鞋講解後端架構的時候，不少東西都是一臉懵逼，大半年裏不斷認知學習，認識上終於有很多進步。學無止境，須要去學習的還有不少~行將畢業，7月入職，但願在將來工做中可以在Web這一塊有更加深刻的認識。