每秒處理1000萬用戶請求，雲上架構如何實現高性能和高可用

內容來源：2017 年 12 月 21 日，駐雲科技資深架構師翟永東在「雲時代企業架構的搭建」進行《雲上架構如何實現高性能和高可用》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2851 | 8分鐘閱讀

嘉賓演講視頻及PPT回顧： suo.im/4sKQd8

摘要

雲上架構須要關注多方面的因素，本次主要講的是高可用和高性能，從這兩方面展開深度的解析如何搭建完善的雲上架構。

雲上架構概述

雲上搭建架構不僅僅須要考慮到性能和可用性，還有安全性、可管理性、彈性等層面都須要注意，實際工做中每個環節都須要顧及到。

傳統架構與雲上架構設計方法對比，傳統的架構設計週期會比較長，通常的企業架構都會考慮從此3到5年的規劃，解決的主要是有無的問題，是從0到1的架構搭建。雲上的架構設計週期相對來講比較短，需求明確且主要是解決或優化已有的問題。

雲上架構的高性能

什麼是性能

性能是很難衡量的，狹義上的性能指的是運行速度的快慢，廣義的性能則涉及更多的內容，如功耗、利用率、性能價格比、速度等。不一樣視角下關注性能的側重點不一樣，用戶視角下關注的是從請求發送到得到響應的整個時間間隔，對用戶來講時間越長性能越差。從架構和開發者視角出發更可能是關注響應延時、系統吞吐量以及併發處理能力，而更重要的是明確瞭解用戶反映問題的根源。

高性能架構設計的基本步驟

搭建高性能架構有4個基本步驟，首先要明確性能的目標，接着分析系統中影響目標實現的全部問題，找到問題後再着手解決這些問題，最後經過性能評估的手段來測試當前性能指標。若是評估結果與性能目標以前存在差別，就說明影響性能的問題尚未被所有找到，這時須要從新開始進行以前的步驟。

整個過程實際上是一個循環，即便某一次性能評估達標，但隨着時間的推移業務的發展仍是會出現新的性能須要。

進一步分析

性能目標指的是制定的符合高性能的指標，好比頁面響應時間小於1秒，併發用戶能夠達到1萬，高峯期每秒處理10000萬用戶請求等。

而後要根據性能目標分析當前業務系統中不一樣層次有哪些影響性能指標的問題，好比網絡層方面的帶寬、延遲，計算層方面的Cpu處理能力、是否採用集羣，以及一些其餘方面的影響因素。因此說系統性能高低由總體的處理能力決定，不禁單一因素決定。

分析出問題後就開始解決問題，這時能夠從兩個方面着手。一方面是最簡便也是大多數人首先會想到的，即提高系統硬件配置，若是硬件資源的升級可以解決問題，那麼就直接採用這種方式，它最大的好處在於不用對現有的代碼邏輯作任何的修改。可是大部分的狀況下每每沒法簡單的經過硬件升級解決全部問題，還須要從架構的層次上入手，下降服務器壓力，採用可擴展架構提升性能。

傳統的測試可使用LoadRunner之類的工具，雲上則可使用阿里雲性能測試服務PTS。PTS與傳統的性能測試最大的不一樣在於LoadRunner須要本身搭建，同時搭建好的測試系統會受限於自己的服務上限，服務器的數量決定了所能模擬的測試壓力。PTS則能夠快速的模擬大量併發請求，由於是雲上因此PTS後端可以經過集羣的方式模擬用戶須要的併發量。

上圖是咱們提出的相對較好的架構方案，前端由負載均衡服務響應用戶請求，在把請求轉發給後端具體的服務器以前會有一個前端緩存，用來提高響應時間以及減輕後端壓力。後端服務器經過集羣方式響應用戶請求，同時應用之間經過異步進行交互。訪問數據庫以前先經過緩存響應請求，在不能命中的時候再去訪問數據庫。

使用緩存時有個問題須要特別注意，即緩存與數據庫的數據不一致。針對這一問題解決方式是不一樣的，要根據不一樣的需求來選擇。好比有一種方式是在寫數據庫的數據同時更新緩存中的數據或者讓緩存失效，這樣用戶在讀取的時候，要麼獲取的是最新數據，要麼得從數據庫中從新讀取數據。

某客戶在阿里雲上的高性能架構

上圖是咱們某個客戶的雲上架構。前端用戶請求經過CDN服務響應，CDN主要用來作服務加速，對於能夠知足的響應直接使用CDN解決，沒法知足的請求轉發給後端SLB。

從圖中能夠看到不一樣的應用使用的服務器數量不一樣，這裏全部的服務都被部署到ECS上，ECS又掛載在SLB後面，另外其中還有OCS數據緩存，用戶請求的數據若是沒法從緩存中獲取到，就從數據庫中讀取。

數據庫的設計一樣也很是複雜，首先它實現了一套讀寫分離，其次有一個DRDS分佈式關係型數據庫，可以掛載多個RDS實例，全部的請求都會發送給DRDS，而DRDS則至關於中間的路由代理，它會根據請求從不一樣的RDS中獲取數據。

使用DRDS有幾點須要注意，第一DRDS必需要和RDS結合使用，DRDS自己不存儲數據，數據的存儲都是在RDS上；第二DRDS後的RDS實例必須是Mysql數據庫；第三DRDS有兩種使用方式，一種是表的拆分一種是表的不拆分，若是不拆分DRDS會將表存在某一個RDS實例。

雲上架構的高可用

高可用的定義

從字面意思上來看高可用其實就是爲了減小停工時間，保持服務高度可用性。系統作高可用首先要具有自動偵測、自動切換、和自動恢復的能力。

自動偵測：經過冗餘偵測發現運行的狀況，將所聚集的訊息記錄下來，以供維護參考。

自動切換：確認對方故障，則正常主機代替故障主機工做。

自動恢復：故障主機修復後，自動切換回修復完成的主機上。

高可用設計的前提

進行高可用設計時通常建議事先對自身架構作層次化和模塊化的改造，按照應用層、基礎設施層進行高可用設計，再按照功能劃分模塊，模塊之間鬆耦合，且要求穩定可靠易於擴展，結構簡單易於維護。

高可用設計方式

高可用設計包含三種方式，分別是主從方式，主機工做，備機處於監控準備；雙機互備，兩臺主機同時運行各自服務工做且相互監測；集羣工做，多臺主機一塊兒工做，各自運行一個或幾個服務。

高可用架構設計原則

- 假定失效設計：假定任何環節都會出問題，而後倒推設計；

- 多可用區設計：盡最大可能避免架構中的單點故障；

- 自動擴展設計：不進行設計調整，就能知足業務量增加；

- 自我修復設計：內建容錯及檢查能力，應用可以在部分組件失效時自我修復繼續工做；

- 鬆耦合設計：耦合度越小，擴展性越好，容錯能力越強

多可用區設計

在SLB實例下綁定不一樣可用區的ECS，從而避免由於單個可用區的故障而致使對外服務的不可用。多可用區的雲數據庫RDS能夠實現同城的數據災備，OSS存儲的數據默認會保存在多個不一樣可用區中。

健康檢查自我修復

若是某臺ECS實例不健康，致使健康中實例數低於最小值，彈性伸縮就會自動建立健康的ECS實例代替不健康的實例。

鬆耦合設計

經過消息解耦將原應用拆分紅獨立的模塊，模塊間的影響小，就不會由於部分失效致使總體不可用。