目錄
1 軟體架構初識
1.1概述
1.2基本概念
2 軟體架構演進過程
2.1單體架構初步設計
2.2Web服務與資料庫分開
2.3本地緩存和分布式緩存
2.4反向代理與負載均衡設計
2.5資料庫讀寫分離設計
2.6資料庫按業務進行分庫
2.7大表拆分為小表
2.8LVS或F5讓多個Nginx負載均衡
2.9DNS輪詢實作機房的負載均衡
2.10大應用拆分成小應用
2.11抽離微服務實作工程複用
2.12容器化技術設計及應用
2.13雲平台服務部署
1 軟體架構初識
1.1概述
為了更好了解網際網路軟體架構，我們現在介紹一下，一百萬到千萬級并發情況下服務端的架構的演進過程，同時列舉出每個演進階段會遇到的相關技術，讓大家對架構的演進有一個整體的認知。
1.2基本概念
在介紹架構之前，為了避免初學者對架構設計中的一些概念不了解，下面對幾個最基礎的概念進行介紹。
- 分布式
系統中的多個子產品在不同伺服器上部署，即可稱為分布式系統，如Tomcat和資料庫分别部署在不同的伺服器上，或兩個相同功能的Tomcat分别部署在不同伺服器上。
- 高可用
系統中部分節點失效時，其他節點能夠接替它繼續提供服務，則可認為系統具有高可用性。保證系統的高可用性，可從如下幾個9說起，如圖所示：
為了提高可用性，我們要麼提高系統的無故障時間，要麼減少系統的故障恢複時間，這就需要我們知道故障的原因。這個原因通常分為兩大部分：
- 無計劃的系統故障
- 系統級故障：包括主機、作業系統、中間件、資料庫、網絡、電源以及外圍裝置。
- 自然災害、人為破壞，以及供電問題等。
- 有計劃的日常任務：
- 運維相關：資料庫維護、應用維護、中間件維護、作業系統維護、網絡維護。
- 更新相關：資料庫、應用、中間件、作業系統、網絡，包括硬體更新。
我們再對這些故障做個歸類：
- 網絡問題：網絡連結出現問題，網絡帶寬出現擁塞等
- 性能問題：慢 SQL、Java Full GC、硬碟 IO 過大、CPU 飙高、記憶體不足等
- 安全問題：被網絡攻擊，如 DDoS 等。
- 運維問題：系統總是在被更新和修改，架構也在不斷地被調整，監控問題等
- 管理問題：沒有梳理關鍵服務及服務的依賴關系，運作資訊沒有和控制系統同步等
- 硬體問題：硬碟損壞、網卡出問題、交換機出問題、機房掉電、挖掘機問題等
總之，我們要正确認識故障，故障不可避免。尤其是在大型分布式系統中，出現故障是一種常态。有時出現故障根本就不知道出現在了什麼地方。是以我們要對故障原因先有一個認識，與此同時我們要基于故障有應對的政策，也就是我們所說的“彈力設計”，就類似三國中的趙雲猛将，在搏殺中能進能退。
- 叢集
一個特定領域的軟體部署在多台伺服器上并作為一個整體提供一類服務，這個整體稱為叢集。在常見的叢集中，用戶端往往能夠連接配接任意一個節點獲得服務，并且當叢集中一個節點掉線時，其他節點往往能夠自動的接替它繼續提供服務，這時候說明叢集具有高可用性。
- 負載均衡
請求發送到系統時，通過某些方式把請求均勻分發到多個節點上，使系統中每個節點能夠均勻的處理請求負載，則可認為系統是負載均衡的。
- 正向代理和反向代理
系統内部要通路外部網絡時，統一通過一個代理伺服器把請求轉發出去，在外部網絡看來就是代理伺服器發起的通路，此時代理伺服器實作的是正向代理；當外部請求進入系統時，代理伺服器把該請求轉發到系統中的某台伺服器上，對外部請求來說，與之互動的隻有代理伺服器，此時代理伺服器實作的是反向代理。簡單來說，正向代理是代理伺服器代替系統内部來通路外部網絡的過程，反向代理是外部請求通路系統時通過代理伺服器轉發到内部伺服器的過程。如圖所示：
2 軟體架構演進過程
2.1單體架構初步設計
在網際網路應用初期，網際網路使用者數相對都較少，可以把web伺服器(例如Tomcat)和資料庫部署在同一台伺服器上。浏覽器往www.taobao.com發起請求時，首先經過DNS伺服器（域名系統）把域名轉換為實際IP位址10.102.4.1，浏覽器轉而通路該IP對應的Tomcat。如圖所示：
在單體架構下，随着使用者數的增長，Tomcat和資料庫之間競争資源，單機性能不足以支撐業務。
2.2Web服務與資料庫分開
Web伺服器(Tomcat)和資料庫分别獨占伺服器資源，顯著提高兩者各自性能。
本次演進過程中，随着使用者數的增長，并發讀寫資料庫成為瓶頸。
2.3本地緩存和分布式緩存
在Tomcat同伺服器上或同JVM中增加本地緩存，并在外部增加分布式緩存，緩存熱門商品資訊或熱門商品的html頁面等。通過緩存能把絕大多數請求在讀寫資料庫前攔截掉，大大降低資料庫壓力。如圖所示：
其中涉及的技術包括：基于memcached作為本地緩存，使用Redis作為分布式緩存，還會涉及緩存一緻性、緩存穿透/擊穿、緩存雪崩、熱點資料集中失效等問題。
緩存雖然抗住了大部分的通路請求，但随着使用者數的增長，并發壓力主要落在單機的Tomcat上，響應逐漸變慢。
2.4反向代理與負載均衡設計
在多台伺服器上分别部署Tomcat，使用反向代理軟體（Nginx）把請求均勻分發到每個Tomcat中。此處假設Tomcat最多支援100個并發，Nginx最多支援50000個并發，那麼理論上Nginx把請求分發到500個Tomcat上，就能抗住50000個并發。其中涉及的技術包括：Nginx、HAProxy，如圖所示：
反向代理使應用伺服器可支援的并發量大大增加，但并發量的增長也意味着更多請求穿透到資料庫，單機的資料庫最終成為瓶頸。
2.5資料庫讀寫分離設計
把資料庫劃分為讀庫和寫庫，讀庫可以有多個，通過同步機制把寫庫的資料同步到讀庫，對于需要查詢最新寫入資料場景，可通過在緩存中多寫一份，通過緩存獲得最新資料。如圖所示：
其中涉及的技術包括：Mycat，它是資料庫中間件，可通過它來組織資料庫的分離讀寫和分庫分表，用戶端通過它來通路下層資料庫，還會涉及資料同步，資料一緻性的問題。
業務逐漸變多，不同業務之間的通路量差距較大，不同業務直接競争資料庫，互相影響性能。
2.6資料庫按業務進行分庫
把不同業務的資料儲存到不同的資料庫中，使業務之間的資源競争降低，對于通路量大的業務，可以部署更多的伺服器來支撐。
這樣同時導緻跨業務的表無法直接做關聯分析，需要通過其他途徑來解決，但這不是本文讨論的重點，有興趣的可以自行搜尋解決方案。對于這種方案，随着使用者數的增長，單機的寫庫會逐漸會達到性能瓶頸。
2.7大表拆分為小表
比如針對評論資料，可按照商品ID進行hash，路由到對應的表中存儲；針對支付記錄，可按照小時建立表，每個小時表繼續拆分為小表，使用使用者ID或記錄編号來路由資料。隻要實時操作的表資料量足夠小，請求能夠足夠均勻的分發到多台伺服器上的小表，那資料庫就能通過水準擴充的方式來提高性能。其中前面提到的Mycat也支援在大表拆分為小表情況下的通路控制。
這種做法顯著的增加了資料庫運維的難度，對DBA的要求較高。資料庫設計到這種結構時，已經可以稱為分布式資料庫，但是這隻是一個邏輯的資料庫整體，資料庫裡不同的組成部分是由不同的元件單獨來實作的，如分庫分表的管理和請求分發，由Mycat實作，SQL的解析由單機的資料庫實作，讀寫分離可能由網關和消息隊列來實作，查詢結果的彙總可能由資料庫接口層來實作等等，這種架構其實是MPP（大規模并行處理）架構的一類實作。
資料庫和Tomcat都能夠水準擴充，可支撐的并發大幅提高，随着使用者數的增長，最終單機的Nginx會成為瓶頸。
2.8LVS或F5讓多個Nginx負載均衡
由于瓶頸在Nginx，是以無法通過兩層的Nginx來實作多個Nginx的負載均衡。此時采用LVS和F5作為網絡負載均衡解決方案，如圖所示：
其中LVS是軟體，運作在作業系統核心态，可對TCP請求或更高層級的網絡協定進行轉發，是以支援的協定更豐富，并且性能也遠高于Nginx，可假設單機的LVS可支援幾十萬個并發的請求轉發；F5是一種負載均衡硬體，與LVS提供的能力類似，性能比LVS更高，但價格昂貴。由于LVS是單機版的軟體，若LVS所在伺服器當機則會導緻整個後端系統都無法通路，是以需要有備用節點。可使用keepalived軟體模拟出虛拟IP，然後把虛拟IP綁定到多台LVS伺服器上，浏覽器通路虛拟IP時，會被路由器重定向到真實的LVS伺服器，當主LVS伺服器當機時，keepalived軟體會自動更新路由器中的路由表，把虛拟IP重定向到另外一台正常的LVS伺服器，進而達到LVS伺服器高可用的效果。
此種方案中，由于LVS也是單機的，随着并發數增長到幾十萬時，LVS伺服器最終會達到瓶頸，此時使用者數達到千萬甚至上億級别，使用者分布在不同的地區，與伺服器機房距離不同，導緻了通路的延遲會明顯不同。
2.9DNS輪詢實作機房的負載均衡
在DNS伺服器中可配置一個域名對應多個IP位址，每個IP位址對應到不同的機房裡的虛拟IP。當使用者通路www.taobao.com時，DNS伺服器會使用輪詢政策或其他政策，來選擇某個IP供使用者通路。此方式能實作機房間的負載均衡，至此，系統可做到機房級别的水準擴充，千萬級到億級的并發量都可通過增加機房來解決，系統入口處的請求并發量不再是問題。
随着資料的豐富程度和業務的發展，檢索、分析等需求越來越豐富，單單依靠資料庫無法解決如此豐富的需求
2.10大應用拆分成小應用
按照業務闆塊來劃分應用代碼，使單個應用的職責更清晰，互相之間可以做到獨立更新疊代。這時候應用之間可能會涉及到一些公共配置，可以通過分布式配置中心Zookeeper來解決。
不同應用之間存在共用的子產品，由應用單獨管理會導緻相同代碼存在多份，導緻公共功能更新時全部應用代碼都要跟着更新。
2.11抽離微服務實作工程複用
如使用者管理、訂單、支付、鑒權等功能在多個應用中都存在，那麼可以把這些功能的代碼單獨抽取出來形成一個單獨的服務來管理，這樣的服務就是所謂的微服務，應用和服務之間通過HTTP、TCP或RPC請求等多種方式來通路公共服務，每個單獨的服務都可以由單獨的團隊來管理。此外，可以通過Dubbo、SpringCloud等架構實作服務治理、限流、熔斷、降級等功能，提高服務的穩定性和可用性。如圖所示：
個人了解，微服務架構更多是指把系統裡的公共服務抽取出來單獨運維管理的思想
2.12容器化技術設計及應用
目前最流行的容器化技術是Docker，最流行的容器管理服務是Kubernetes(K8S)，應用/服務可以打包為Docker鏡像，通過K8S來動态分發和部署鏡像。Docker鏡像可了解為一個能運作你的應用/服務的最小的作業系統，裡面放着應用/服務的運作代碼，運作環境根據實際的需要設定好。把整個“作業系統”打包為一個鏡像後，就可以分發到需要部署相關服務的機器上，直接啟動Docker鏡像就可以把服務起起來，使服務的部署和運維變得簡單。
在大促的之前，可以在現有的機器叢集上劃分出伺服器來啟動Docker鏡像，增強服務的性能，大促過後就可以關閉鏡像，對機器上的其他服務不造成影響（在3.14節之前，服務運作在新增機器上需要修改系統配置來适配服務，這會導緻機器上其他服務需要的運作環境被破壞）。
2.13雲平台服務部署
系統可部署到公有雲上，利用公有雲的海量機器資源，解決動态硬體資源的問題，在大促的時間段裡，在雲平台中臨時申請更多的資源，結合Docker和K8S來快速部署服務，在大促結束後釋放資源，真正做到按需付費，資源使用率大大提高，同時大大降低了運維成本。
所謂的雲平台，就是把海量機器資源，通過統一的資源管理，抽象為一個資源整體，在之上可按需動态申請硬體資源（如CPU、記憶體、網絡等），并且之上提供通用的作業系統，提供常用的技術元件（如Hadoop技術棧，MPP資料庫等）供使用者使用，甚至提供開發好的應用，使用者不需要關系應用内部使用了什麼技術，就能夠解決需求（如音視訊轉碼服務、郵件服務、個人部落格等）。