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

文章大綱

一、需考慮問題
二、前端架構
三、應用層架構
四、服務層架構
五、存儲層架構
六、後臺架構
七、數據採集與監控
八、安全架構
九、數據中心機房架構
十、自動化運維
十一、參考文章

一、需考慮問題

1. 研發過程管理困難

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

2. 架構設計需考慮情況

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

二、前端架構

前端指用戶請求到達網站應用服務器之前經歷的環節，通常不包含網站業務邏輯，不處理動態內容。

1. 瀏覽器優化技術

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

2. CDN

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

3. 圖片服務

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

4. 反向代理

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

5. DNS

域名服務，將域名解析成IP地址，利用DNS可以實現DNS負載均衡，配置CDN也需要修改DNS，使域名解析後指向CDN服務器。

三、應用層架構

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

1. 開發框架

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

2. 頁面渲染

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

3. 負載均衡

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

4. Session管理

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

5. 動態頁面靜態化

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

6. 業務拆分

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

7. 虛擬化服務器

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

四、服務層架構

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

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 個用戶享受促銷，發一個碼出去，需要對這個碼進行處理，這是一種限流。

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

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

五、存儲層架構

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

1. 分佈式文件

網站在線業務需要存儲的文件大部分都是圖片、網頁、視頻等比較小的文件，但是這些文件的數量非常龐大，而且通常都在持續增加，需要伸縮性設計比較好的分佈式文件系統。

2. 關係數據庫

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

3. NoSQL數據庫

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

4. 數據同步

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

六、後臺架構

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

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

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

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

七、數據採集與監控

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

1. 瀏覽器數據採集

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

2. 服務器業務數據採集

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

3. 服務器性能數據採集

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

4. 系統監控

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

5. 系統報警

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

6. 360度監控

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

八、安全架構

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

1. Web攻擊

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

2. 數據保護

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

九、數據中心機房架構

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

1. 機房架構

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

2. 機櫃架構

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

3. 服務器架構

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

十、自動化運維

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 存儲的數據進行壓縮，這樣空間又縮小四分之一或是三分之一，我們數據到後面就會很小。當量小之後，訪問效率就會升高，你數據量彈出很小，丟單率很小，可以提高我們的可用性。