軟件架構設計經常使用方法-軟件架構設計學習第五天(非原創) 發佈成功，點擊查看文章

時間 2019-11-18

原文原文鏈接

文章大綱

1、需考慮問題
2、前端架構
3、應用層架構
4、服務層架構
5、存儲層架構
6、後臺架構
7、數據採集與監控
8、安全架構
9、數據中心機房架構
10、自動化運維
11、參考文章html

1、需考慮問題

1. 研發過程管理困難

（1）依賴管理，每一個模塊對其餘模塊的依賴是管理困難的；
（2）版本管理；
（3）部署管理（搭火車，難以觸達到用戶）；
（4）模塊組織方式（庫工程，源代碼級別，沒有權限）。
（5）構建打包痛苦：可能不能打包（2.x安裝不上），合併代碼搞了好久，編譯打包時間過長。前端

2. 架構設計需考慮狀況

（1）業務分級、核心、非核心業務隔離
（2）多機房部署，流量分流、容災冗餘、峯值應對冗餘
（3）讀庫多源，失敗自動轉移
（4）寫庫主備，短暫有損服務容忍下的快速切換
（5）外部接口，失敗轉移或快速斷路
6.Redis 主備，失敗轉移
7.大表遷移，MongoDB 取代 MySQL 存儲消息記錄
8.改進消息投遞模型算法

2、前端架構

前端指用戶請求到達網站應用服務器以前經歷的環節，一般不包含網站業務邏輯，不處理動態內容。數據庫

1. 瀏覽器優化技術

並非優化瀏覽器，而是經過優化響應頁面，加快瀏覽器頁面的加載和顯示，經常使用的有頁面緩存、合併HTTP減小請求次數、使用頁面壓縮等。後端

2. CDN

內容分發網絡，部署在網絡運營商機房，經過將靜態頁面內容分發到離用戶最近最近的CDN服務器，使用戶能夠經過最短路徑獲取內容。
動靜分離，靜態資源獨立部署
靜態資源，如JS、CSS等文件部署在專門的服務器集羣上，和Web應用動態內容服務分離，並使用專門的（二級）域名。瀏覽器

3. 圖片服務

圖片不是指網站Logo、按鈕圖標等，這些文件屬於上面提到的靜態資源，應該和JS、CSS部署在一塊兒。這裏的圖片指用戶上傳的圖片，如產品圖片、用戶頭像等，圖片服務一樣適用獨立部署的圖片服務器集羣，並使用獨立（二級）域名。緩存

4. 反向代理

部署在網站機房，在應用服務器、靜態資源服務器、圖片服務器以前，提供頁面緩存服務。安全

5. DNS

域名服務，將域名解析成IP地址，利用DNS能夠實現DNS負載均衡，配置CDN也須要修改DNS，使域名解析後指向CDN服務器。性能優化

3、應用層架構

應用層是處理網站主要業務邏輯的地方。服務器

1. 開發框架

網站業務是多變的，網站的大部分軟件工程師都是在加班加點開發網站業務，一個好的開發框架相當重要。一個號的開發框架應該可以分離關注面，使美工、開發工程師能夠各司其事，易於協做。同時還應該內置一些安全策略，防禦Web用攻擊。

2. 頁面渲染

將分別開發維護的動態內容和靜態頁面模板集成起來，組合成最終顯示給用戶的完整頁面。

3. 負載均衡

將多臺應用服務器組成一個集羣，經過負載均衡技術將用戶請求分發到不一樣的服務器上，以應對大量用戶同時訪問時產生的高併發負載壓力。

4. Session管理

爲了實現高可用的應用服務器集羣，應用服務器一般設計爲無狀態，不保存用戶請求上下文信息，可是網站業務一般須要保持用戶會話信息，須要專門的機制管理Session，使集羣內甚至跨集羣的應用服務器能夠共享Session。

5. 動態頁面靜態化

對於訪問量特別大而更新又不很頻繁的動態頁面，能夠將其靜態化，即生成一個靜態頁面，利用靜態頁面的優化手段加速用戶訪問，如反向代理、CDN、瀏覽器緩存等。

6. 業務拆分

將複雜而龐大的業務拆分開來，造成多個規模較小的產品，獨立開發、部署、維護，除了下降系統耦合度，也便於數據庫業務分庫。按業務對關係數據庫進行拆分，技術難度相對較小，而效果又相對較好。

7. 虛擬化服務器

將一臺物理服務器虛擬化成多態虛擬服務器，對於併發訪問較低的業務，更容易用較少的資源構架高可用的應用服務器集羣。

4、服務層架構

提供基礎服務，供應用層調用，完成網站業務。

1. 分佈式消息

利用消息隊列機制，實現業務和業務、業務和服務之間的異步消息發送及低耦合的業務關係。

2. 分佈式服務

提供高性能、低耦合、易複用、易管理的分佈式服務，在網站實現面向服務架構（SOA）。

3. 分佈式緩存

經過可伸縮的服務器集羣提供大規模熱點數據的緩存服務，是網站性能優化的重要手段。

4. 分佈式配置

系統運行須要配置許多參數，若是這些參數須要修改，好比分佈式緩存集羣加入新的緩存服務器，須要修改應用程序客戶端的緩存服務器列表配置，並重啓應用程序服務器。分佈式配置在系統運行期提供配置動態推送服務，將配置修改實時推送到應用系統，無需重啓服務器。

5. 業務分離

系統把全部的功能都包含了，好比說登陸、註冊、參數下發、消息、日誌、更新。
其實對於玩家來玩遊戲來講，真正強相關的只有登陸註冊和參數下發，消息和日誌、更新其實並非玩家玩遊戲必須具有或者強相關的。
因此，業務分離的作法就是把核心業務和非核心業務分拆到不一樣的系統中，把兩個系統之間經過接口調用，互相訪問。
這樣作的好處，假設非核心業務系統出現故障，它並不影響核心業務系統，由於它們之間是經過接口調用的，並不共享相同的資源。

6. 服務中心

服務中心相似於DNS，是實現整個內部系統之間服務調用時候的調度功能，服務中心是一個相似於服務的名字系統。
好比說有一個A業務想訪問其餘系統提供的業務。它首先並非直接訪問到另一個系統，而是要到服務中心訪問一下。
好比說我須要X服務，服務中心告訴A：你去訪問Host1+port1的xxx接口。服務中心有一個配置和狀態上報，能夠根據一些狀態、算法、配置，選擇一個最優秀的服務器告訴A業務。
那麼，A業務收到以後就按照這個指示去訪問真正提供業務的機器，好比B系統裏的Host1+ port1這個機器。服務中心的做用跟HTTP-DNS的做用差很少，就是但願在內部某個系統故障的時候能夠快速處理或者切換。
假設B系統某臺機器有問題了，咱們能夠經過自動或者人工的方式在服務中心把這臺機器直接下掉，A業務請求的時候，它就不會再請求到這個有問題的機器上，這一臺機器的故障就不影響A業務。

7. 業務降級

整個系統拆分紅核心業務系統和非核心業務系統，在一些緊急狀況下，好比說非核心業務系統重啓也沒有辦法，甚至說某個數據庫搞掛了，它又影響業務核心系統。
這個時候，接口是能夠訪問的，可是響應時間特別慢，核心系統就有點被拖慢。
那麼，在這種比較極端的狀況下，咱們能夠經過人工的方式下發降級指令，把這個非核心業務系統的功能給停掉，這個停掉並非把程序停掉，而是說把其中的一個接口或者url停掉，核心系統去訪問的時候就獲得一個500或者503錯誤。
咱們作了一個專門的降級系統，降級系統能夠去下發這些降級指令。通常狀況下由降級系統給非核心業務系統下發降級指令，若是到了一些關鍵時刻，其實核心業務系統中有的接口也是能夠進行降級的。
也就是說，咱們降級的時候並非對整個系統或者整個功能進行降級，咱們能夠作到接口或者url這個級別的降級。經過犧牲非核心業務系統的功能，咱們盡最大努力地去保證核心業務系統提供的業務。
這個業界有不少叫法，好比有損服務、可損服務，其實咱們這個也是一個可損服務，功能上的可損，不是流量上的可損。

8. 容災降級

若是分流、限流還沒抗住，系統進一步出現壓力問題，再要作準備作容災降級。

容災降級有機房容災，咱們作多中心機房，網絡容災、內網外網的容災，應用的容災，分組、託底容器，最後保證基礎的服務是正常的。

網絡及 IDC 降級

這是容災降級，這是網絡大概示意圖。咱們的 ISP 進入機房，核心交換機、櫃頂交換機、這是交換級的容災，網絡共享容災。

業務降級

購物車結算頁的降級，當訂單出現過大，延保服務、預定服務若是不行，直接保主流層，就屬於業務層面的降級。

安全與限流
咱們假設系統當超過必定流量後，超過的流量作直接拒絕處理，以便保護後端的服務，這就是限流。

Web 的限流根據 PIN 來限流，這是根據 IP 加 PIN 風控數據限流，這一塊根據業務邏輯，一個單一天能下多少單，根據這個邏輯去限流。渠道能夠按 App、PC、微信等分開，分流和限流這麼作。

下面講秒殺系統是怎麼來的。秒殺系統是限流和分流的典型。
秒殺，假設預定是 1500 萬，在那一分鐘以內，這麼多用戶過來搶手機，也就是單個商品，就把流量直接導到秒殺系統。

秒殺系統從 Ngnix 進來就有各類的限制，到咱們會識別用戶供應商或者商販去刷的數據，這塊調用是從正常訪問的單品頁分出來，不影響主流程。

經過 IP、PIN、每一步怎麼來、用戶以提交記錄，一秒鐘提交多少次，一分鐘提交多少次等一堆的規則作判斷來限流。到最後再驗證有沒有預定、經常使用地址服務等，都經過後再調到接單系統。

整個秒殺系統就是一個典型的沙漏的系統，當流量跑到後面，實際上只剩很小的一部分，只有真實的寫流量到接單。

接單提交服務單獨出來兩臺機器給它用，後面的存儲獲得保護，兩臺機器最多也就幾十萬，也能承載住，這就是分流跟限流。

促銷與價格

促銷裏面也有一個限購，好比前 30 個用戶享受促銷，發一個碼出去，須要對這個碼進行處理，這是一種限流。

促銷分流中須要把價格服務單拎出來，分出去，單品頁搜索，手機微信，購物車的架構從這裏出來，最實時的價格。這樣產生分流，這一塊有一個存儲分流，還有更多其它的就沒有一一列舉，這只是一個示意圖。

這就是咱們整個的分流跟限流。根據前面的渠道，調用量、作多少程度，相對於影響力，作分流和限流。

5、存儲層架構

提供數據、文件的持久化存儲訪問與管理服務。

1. 分佈式文件

網站在線業務須要存儲的文件大部分都是圖片、網頁、視頻等比較小的文件，可是這些文件的數量很是龐大，並且一般都在持續增長，須要伸縮性設計比較好的分佈式文件系統。

2. 關係數據庫

大部分萬丈的主要業務是基於關係數據庫開發的，可是關係數據庫對集羣伸縮性的支持表較差。經過在應用程序的數據訪問層增長數據庫訪問的路由功能，根據業務配置將數據庫訪問路由到不一樣的物理數據庫上，可實現關係數據庫的分佈式訪問。

3. NoSQL數據庫

目前各類NoSQL數據庫層出不窮，在內存管理、數據模型、集羣分佈式管理等方面各有優點，不過從社區活動性角度看，HBase無疑是目前最好的。

4. 數據同步

在支持全球範圍內數據共享的分佈式數據庫技術成熟以前，擁有多個數據中心的網站必須在多個數據中心之間進行數據同步，以保證每一個數據中心都擁有完整的數據。在實踐中，爲了減輕數據庫壓力，將數據庫的事物日誌（或者NoSQL的寫操做Log）同步到其餘數據中心，根據Log進行數據重演，實現數據同步。

6、後臺架構

網站應用中，除了要處理用戶的實時訪問請求外，還有一些後臺非實時數據分析要處理。

搜索引擎
即便是網站內部的搜索引擎，也須要進行數據增量更新及全量更新、構建索引等。這些操做經過後臺系統定時執行。

數據倉庫
根據離線數據，提供數據分析與數據挖掘服務。

推薦系統
社交網站及購物網站經過挖掘人與人之間的關係，人和商品之間的關係，發展潛在的人際關係和購物興趣，爲用戶提供個性化推薦服務。

7、數據採集與監控

監控網站訪問狀況與系統運行狀況，爲網站運營決策和運維管理提供支持保障。

1. 瀏覽器數據採集

經過在網站頁面中嵌入JS腳本採集用戶瀏覽器環境與操做記錄，分析用戶行爲。

2. 服務器業務數據採集

服務器業務數據包括兩種，一種是採集在服務器端記錄的用戶請求操做日誌；一種是採集應用程序運行期業務數據，好比待處理消息數目等。

3. 服務器性能數據採集

採集服務器性能數據，如系統負載、內存使用率、網卡流量等。

4. 系統監控

將前述採集的數據以圖表的方式展現，以便運營和運維人員監控網站運行情況，作到這一步僅僅是系統監視。更先進的作法是根據採集的數據進行自動化運維，自動處理系統異常情況，是吸納自動化控制。

5. 系統報警

若是採集來的數據超過預設的正常狀況的閥值，好比系統負載太高，就經過郵件、短信、語音電話等方式發出警報信號，等待工程師干預。

6. 360度監控

總體方案從上到下分爲五層：業務層、應用服務層、接口調用層、基礎組件層、基礎設施層。
（1）業務層：就是咱們業務上的打點，根據這些打點進行機型統計或者分析；
（2）應用服務層：簡單來講就是咱們url的一個訪問狀況；
（3）接口調用層：就是咱們本身系統對外部依賴的那些接口的訪問狀況，好比A系統調用B系統的一個接口，在A系統裏統計或者監控調用B系統接口的狀況，包括時延、錯誤次數之類；
（4）基礎組件層：其實就是咱們使用的一些組件，包括MySQL等；
（5）基礎設施層：就是最底層的，包括操做系統、網絡、磁盤、IO這些設備。
整個監控是分層的，在咱們出現問題的時候，定位問題須要的關鍵信息所有包括在這裏面的。

8、安全架構

保護網站免遭攻擊及敏感信息泄露。

1. Web攻擊

以HTTP請求的方式發起的攻擊，危害最大的就是XSS和SQL注入攻擊。可是隻要措施得當，這兩種攻擊都是比較容易防範的。

2. 數據保護

敏感信息加密傳輸與存儲，保護網站和用戶資產。

9、數據中心機房架構

大型網站須要的服務器規模數以十萬計，機房物理架構也須要關注。

1. 機房架構

對於一個擁有十萬臺服務器的大型網站，每臺服務器耗電（包括服務器自己耗電及空調耗電）每一年大約須要人民幣2000元，那麼網站每一年機房電費就須要兩億人民幣。數據中心能耗問題日趨嚴重，Google、Facebook選擇數據中心地理位置的時候趨向選擇散熱良好，供電充裕的地方。

2. 機櫃架構

包括機櫃大小，網線佈局、指示燈規格、不間斷電源、電壓規格（是48V直流電仍是220V民用交流電）等一系列問題。

3. 服務器架構

大型網站因爲服務器採購規模龐大，大都採用定製服務器的方式代替購買服務器整機。根據網站應用需求，定製硬盤、內存、甚至CPU，同時去除沒必要要的外設接口（顯示器輸出接口，鼠標、鍵盤輸入接口），並使空間結構利於散熱。

10、自動化運維

1. 自動化運維工做內容

（1）硬件和網絡的自動管理
（2）雲化、虛擬機的自動管理
（3）操做系統和軟件的自動化安裝、配置
（4）常規任務（健康檢查、安全加固和檢查、備份、清理、數據管理、彈性伸縮等）
（5）手工任務（容災切換、應急操做、應用部署和起停……）
（6）監控
（7）問題診斷
（8）可視化

2. 全鏈路全流量線上壓測

壓測分爲線上壓測、線下壓測，主力作線上壓測。

爲何咱們會採用線上壓測？早年咱們只作線下壓測，環境跟線上不同，路由器和機器 CPU，物理機，每個不相同或者架設的路由超過 3 層，丟包，各類數據不同，壓測出來的數據常常會差別。

線上壓測分開是怎麼樣作的？須要將讀業務跟寫業務區分開。讀業務，咱們正常能夠看到讀價格讀庫存、讀購物車場景的分開，讀跟寫，看到購物車上的分佈，就能知道是讀仍是寫。

演練縮減服務器

從壓測上，在集羣中將服務器縮減，由於咱們支撐的量，最高量達到 1 分鐘達到 1 億左右，日常最少有幾十萬、幾百萬的量。集羣確定是比較大的，最少也是幾十臺的機器，咱們會把集羣機器逐臺往下縮減，真正看到線上量能扛到什麼狀況。

作到這兒，你們會有疑問？風險挺大。對，風險的確挺大，好比一個集羣的 30 臺機器一個一個往下縮，好比縮到 5 臺，若是扛不住，全部的機器就崩潰，就會面臨很大風險。因此梳理完每一個架構以後，每一年咱們冒着風險，找到這個點，往上一點的量進行縮減，縮到必定程度再強行縮。

複製流量

主要經過 TCPCopy 複製端口流量，多層翻倍放大流量。以下圖就直接將每層流量翻倍總體就是 1,000 倍，工具實現簡單，能夠實現多條線組合進行流量複製。經過這種方式發起超負荷的請求，檢驗服務可以承載的容量。

模擬流量

咱們作了一個成立了一個壓力小組，線上壓力測試小組，咱們作線上壓測。用很是簡單的底層工具去作壓測。底層發起的量特別快並且特別多，集羣，咱們只作了壓測平臺，把這些工具集成起來作模擬流量壓測。

在數據模擬上，咱們是本身事先會準備一批數據。好比說幾萬個用戶，幾萬個 SKU。商家各類庫存模式，促銷模式，在模擬平臺咱們會準備好。

流量泄洪

咱們把訂單在這個結構，接住堵在這個地方不往下放，日後拽都是密集的一些服務。從這一塊把量堵住，堵幾十萬，忽然有一天打開，看到一個峯值，看每一分鐘處理量，日後能承受多大量，是否是可以承受發起的量，

實施方法

你們可能在朋友圈看到照片，各個服務的核心人員，集中在一個會議室，進行壓測。一步一步往上加量，嚴密監控線上響應狀況、訂單量狀況、各個服務器，以及各個緩存、數據庫等機器的實際負載狀況。出現任何風吹草動就中止發起壓力，並進行記錄和排查問題。

而後壓測訂單提交，往主集羣寫數據。跟購物車不一樣，這種壓測會直接在生成集羣上進行壓測，並會寫入數據。所以須要將寫入數據進行隔離操做，並將垃圾數據進行數據刪除，不能進入生產環境。

根據業務和技術維度篩選一批商品、一批用戶，主要覆蓋存儲分佈、用戶每一個等級以及業務分支。促銷組幫忙創建能覆蓋全部環節的促銷數據。將這些用戶的提交訂單後清空購物車的功能禁用，保證能不停的重複下單。另外這些用戶的訂單提交流程中的郵件、短信提醒等相關功能禁用，產生的訂單進行隔離，不往生產系統下發，並在測試完成後進行刪除。

線上壓測時，組織各個相關組核心人員嚴密監控各項數據。出現問題當即中止壓測。先進行恢復，同時進行數據記錄和問題排查，如分鐘級沒法恢復則直接切亦莊備用集羣。

每一個服務分別進行一輪壓測，記錄每一個服務和購物車、訂單提交壓測得出的數據。根據線上實際用戶調用比例進行換算，得出一個相對精準的總體集羣承載數據。

訂單生產後系統，主要用憋單，快速釋放流量進行壓測。造成對整個後續系統的，持續性高流量衝擊，得出總體系統的處理訂單能力。

經過壓測，就知道目前京東系統，壓測完能承受多大量，面臨咱們目標差距有多少？壓測完以後，咱們就要運維優化。

在打壓時候，咱們按照交易系統的流量分佈來模擬流量，好比正常訪問購物車與結算頁是 16 ：4 的流量，下圖的在打壓時候咱們也嚴格按照這個流量來執行，確保壓力接近大促時候的真實訪問場景。

3. 根據壓力錶現進行調優

調優一：多級緩存

緩存從前面比較多，CDN、Nginx、Java 都會有緩存。

緩存是逐級往下作，是一個漏斗狀，最開始作緩存，到緩存的持續性在很短的時間內，一分鐘或者一秒鐘或者毫秒，這樣給用戶的感知是看不到緩存的，若是你要承載這麼大量，必須逐級作緩存，前面作一些靜態緩存掉，後面會作一些基礎數據緩存，最後大數據，一層一層往上能擋住整個這一塊，

調優二：善用異步

這是購物車大概的結構。這裏有一個異步雙寫，咱們會寫丟這個數據，寫丟不要緊，咱們購物車是總體的，加一個商品，寫不過來，下次過來又會全覆蓋。這樣購物車就有一個多機房多活的可用性。

調優三：超熱數據的緩存

購物車裏面作熱數據緩存，這種數據的緩存，好比促銷服務直接影響到價格，緩存效率必須是在秒級毫秒級，在一秒鐘怎麼篩選十億商品裏面最熱的商品？

咱們利用 Queue 的原理，不斷往裏塞 SKU，隊列的長只有 50。傳進來以後，這裏有的位置往前移，咱們很快知道在一秒鐘知道，排在前面確定是訪問次數最多的，每個階段應用存儲訪問最多的數據，若是是秒殺商品，500 萬的請求有十萬到二十萬，它確定大部分的請求在這塊就出去了，不會穿透進來，這是咱們本身作的熱數據緩存。

調優四：數據壓縮

對 Redis 存儲的數據進行壓縮，這樣空間又縮小四分之一或是三分之一，咱們數據到後面就會很小。當量小以後，訪問效率就會升高，你數據量彈出很小，丟單率很小，能夠提升咱們的可用性。