可擴(kuò)展和彈性伸縮系統(tǒng)設(shè)計
可擴(kuò)展架構(gòu)基礎(chǔ)
可擴(kuò)展架構(gòu)的背景
軟件系統(tǒng)是可以隨著需求變化或者技術(shù)變化而不斷擴(kuò)展和迭代的，我們常見的各種軟件系統(tǒng)比如操作系統(tǒng)、各種知名開源軟件系統(tǒng)都是如此。而在這個過程中，我們?nèi)绾瓮ㄟ^較小的代價去擴(kuò)展我們的系統(tǒng)，是我們要重點(diǎn)考慮的。
可擴(kuò)展的基本思想：拆分（流程、服務(wù)、功能）
可擴(kuò)展性架構(gòu)的設(shè)計方法雖然很多，但是最核心的思想就是拆分。將大系統(tǒng)拆分為小系統(tǒng)、小模塊，然后針對其中的子系統(tǒng)或者模塊來進(jìn)行擴(kuò)展，這樣可以通過較小的改動去實(shí)現(xiàn)整個系統(tǒng)的擴(kuò)展能力，可以同時滿足擴(kuò)展需求和改動的風(fēng)險。
(相關(guān)資料圖)
拆分的方式包括 流程、服務(wù)、功能 三部分，理解這三種思路的關(guān)鍵就在于如何理解“流程”“服務(wù)”“功能”三者的聯(lián)系和區(qū)別。從范圍上來看，從大到小依次為：流程 > 服務(wù) > 功能。以 TCP/IP 協(xié)議棧為例，來說明“流程”“服務(wù)”“功能”的區(qū)別和聯(lián)系：
流程對應(yīng) TCP/IP 四層模型，因為 TCP/IP 網(wǎng)絡(luò)通信流程是：應(yīng)用層 → 傳輸層 → 網(wǎng)絡(luò)層 → 物理 + 數(shù)據(jù)鏈路層，不管最上層的應(yīng)用層是什么，這個流程都不會變。服務(wù)對應(yīng)應(yīng)用層的 HTTP、FTP、SMTP 等服務(wù)，HTTP 提供 Web 服務(wù)，F(xiàn)TP 提供文件服務(wù)，SMTP 提供郵件服務(wù)，以此類推。功能每個服務(wù)都會提供相應(yīng)的功能。例如，HTTP 服務(wù)提供 GET、POST 功能，F(xiàn)TP 提供上傳下載功能，SMTP 提供郵件發(fā)送和收取功能。
可擴(kuò)展架構(gòu)模式
根據(jù)拆分的思想，典型的可擴(kuò)展系統(tǒng)架構(gòu)有：
面向流程拆分（分層架構(gòu)）。由于系統(tǒng)做了合理的分層，因此擴(kuò)展的時候，可能只需要修改其中一層就可以進(jìn)行功能擴(kuò)展。一個典型的分層架構(gòu)系統(tǒng)的擴(kuò)展就是對數(shù)據(jù)層的擴(kuò)展，比如之前只支持 MySQL，現(xiàn)在需要同時支持 MySQL 和 Elasticserach，那么只需要 在數(shù)據(jù)層進(jìn)行修改擴(kuò)展即可不太常見的 2 層架構(gòu)（C/S 架構(gòu)、B/S 架構(gòu)）。通過用戶交互維度來劃分，和用戶交互的是一層、支持交互的后端系統(tǒng)是一層。常見的是 3 層架構(gòu)（MVC、MVP 架構(gòu)）。一般通過業(yè)務(wù)功能職責(zé)來劃分。還有一些 2 層架構(gòu)（C/S 架構(gòu)、B/S 架構(gòu)）。通過用戶交互維度來劃分，和用戶交互的是一層、支持交互的后端系統(tǒng)是一層。常見的邏輯分層架構(gòu)。比如操作系統(tǒng)的邏輯分層架構(gòu)、比如一般我們后臺業(yè)務(wù)系統(tǒng)里面的分層架構(gòu)。面向服務(wù)拆分（SOA、微服務(wù)）。這個是現(xiàn)在最常見的架構(gòu)設(shè)計，因為都是微服務(wù)形態(tài)，那么擴(kuò)展的時候，只需要針對每個獨(dú)立運(yùn)行的微服務(wù)進(jìn)行擴(kuò)展，其他服務(wù)無感知，這樣修改的粒度很小，擴(kuò)展會比較容易。面向功能拆分（微內(nèi)核架構(gòu)）。這個是我最近才了解到的一種架構(gòu)設(shè)計，針對這種架構(gòu)，對某個功能擴(kuò)展，或者要增加新的功能時，只需要擴(kuò)展相關(guān)功能即可，無須修改所有的服務(wù)。
響應(yīng)時間 和 可伸縮性 的關(guān)系
可擴(kuò)展性（Scalability）與性能是不能混為一談的，性能 != 可擴(kuò)展。性能是指系統(tǒng)提供一定響應(yīng)時間的能力；可擴(kuò)展性是指我們可以很容易的通過擴(kuò)容集群、擴(kuò)容數(shù)據(jù)庫、擴(kuò)容實(shí)例等簡單的方式來提供整體的并發(fā)能力，這樣的話，只要請求訪問量增加，我們就可以通過擴(kuò)展機(jī)器的方式來適應(yīng)請求量的增加。系統(tǒng)可以是高性能的，但可能是不可擴(kuò)展的。
性能（performance）-> 響應(yīng)時間： 接口請求的響應(yīng)時間可伸縮性（Scalability）： 包括橫向擴(kuò)展（Scaling Out）和縱向擴(kuò)展（Scaling Up ）橫向擴(kuò)展（水平擴(kuò)展）： 增加實(shí)例、增加機(jī)器縱向擴(kuò)展（垂直擴(kuò)展）： 增加硬件配置如 CPU 核數(shù)；使用更高性能的 CPU、網(wǎng)卡等；增加內(nèi)存容量；
但是這里需要注意的是響應(yīng)時間 和 可伸縮性可能不是同步的或者是線性的，也就是說當(dāng)請求量增加，并且進(jìn)行各種擴(kuò)容后，雖然抗住了請求量，但是響應(yīng)時間不見得會變短，可能會變長，因為請求量的增加導(dǎo)致底層的各種系統(tǒng)資源消耗較多或者下游的依賴壓力較大從而導(dǎo)致響應(yīng)時間變長。
系統(tǒng)資源 和 水平擴(kuò)展的關(guān)系
請求量增加的時候，要進(jìn)行擴(kuò)容，擴(kuò)容最容易和最常見的方式是水平擴(kuò)展服務(wù)，也就是擴(kuò)容無狀態(tài)實(shí)例。但是，針對一些系統(tǒng)資源或者依賴資源，比如數(shù)據(jù)庫（MySQL）、緩存（Redis）等，這些有狀態(tài)的不能無限擴(kuò)容，因此就一定考慮他們的性能，他們的性能才是底線，如果 redis 、ES 等扛不住，那么擴(kuò)容再多無狀態(tài)實(shí)例也是白費(fèi)。這里需要特別注意這些底層依賴資源的性能以及無狀態(tài)服務(wù)和他們連接的一些連接池、并發(fā)數(shù)等。
可擴(kuò)展和 彈性伸縮的關(guān)系
可擴(kuò)展性是指系統(tǒng)適應(yīng)更大的負(fù)載的能力，只需通過增加資源，使硬件更強(qiáng)大（擴(kuò)展）或增加額外的節(jié)點(diǎn)（擴(kuò)展）。
彈性伸縮是指動態(tài)地適應(yīng)應(yīng)對負(fù)載所需的資源的能力，通常與擴(kuò)展性有關(guān)。因此，當(dāng)負(fù)載增加時，你通過添加更多的資源來擴(kuò)大規(guī)模，而當(dāng)需求減弱時，你就縮減并刪除不需要的資源。 彈性伸縮在云環(huán)境中非常重要，一方面你要按使用量付費(fèi)，不想為你目前不需要的資源付費(fèi)，另一方面要在需要時滿足不斷增長的需求。
可擴(kuò)展架構(gòu)設(shè)計（Scalability）
可擴(kuò)展架構(gòu)設(shè)計的最佳實(shí)踐
一些最佳實(shí)踐可以參考（翻譯） OpenShift 的 Best Practices for Scaling Out 這篇文章，這里在此基礎(chǔ)上做進(jìn)一步的整理和總結(jié)：
微服務(wù)化設(shè)計，盡量讓我們的系統(tǒng)模塊化、組件化，從而實(shí)現(xiàn)高內(nèi)聚，低耦合的思想，提高復(fù)用性，擴(kuò)展性。這樣每個微服務(wù)可以獨(dú)立進(jìn)行擴(kuò)展，而且一個服務(wù)掛掉并不會導(dǎo)致整個服務(wù)不可用；這個也同樣適用于數(shù)據(jù)庫的拆分邏輯。分層設(shè)計，可擴(kuò)展架構(gòu)設(shè)計的基本要求就是我們服務(wù)要先進(jìn)行分層，然后每一層都要能夠單獨(dú)擴(kuò)展，并且需要用到負(fù)載均衡技術(shù)。消息隊列：模塊化的系統(tǒng)通過消息隊列進(jìn)行交互，使模塊之間的依賴解耦。隊列的引入可以緩解流量突峰，也可以流程異步化，提高性能、穩(wěn)定性。 高并發(fā)、大流量下，同步機(jī)制會使得整體響應(yīng)非常慢，因此當(dāng)前一般的高并發(fā)系統(tǒng)都是異步處理的，一般我們可以通過消息隊列實(shí)現(xiàn)異步。分布式服務(wù)：公用模塊服務(wù)化，提供其他系統(tǒng)使用，提高可重用性，擴(kuò)展性。聯(lián)系緊密的服務(wù)盡量部署到同一個集群，避免跨集群訪問帶來的延遲、帶寬增加等應(yīng)用程序應(yīng)該盡量采用無狀態(tài)服務(wù)，而不是采用有狀態(tài)服務(wù)；將需要存儲的狀態(tài)統(tǒng)一用分布式存儲、分布式緩存來存儲。善用分布式緩存；訪問緩存比訪問數(shù)據(jù)庫或者文件系統(tǒng)性能高很多，避免直接操作數(shù)據(jù)庫，可以極大提高性能設(shè)計模式：應(yīng)用面向?qū)ο笏枷?，原則，使用設(shè)計模式，進(jìn)行代碼層面的設(shè)計。網(wǎng)關(guān)入口要使用負(fù)載均衡層，常見的是 Nginx 和 HAProxy，當(dāng)做 7 層代理集群，然后后面再接入應(yīng)用服務(wù)。使用代理層是可擴(kuò)展架構(gòu)的必要前提。不要過度設(shè)計，根據(jù)情況考慮是否最初就設(shè)計為可擴(kuò)展架構(gòu)，不必從一開始就構(gòu)建可伸縮的體系結(jié)構(gòu)，擴(kuò)展的關(guān)鍵是先于用戶發(fā)現(xiàn)瓶頸。不要強(qiáng)迫將自己熟知的技術(shù)運(yùn)用到不恰當(dāng)?shù)念I(lǐng)域來解決特定領(lǐng)域的問題；所用來解決問題的技術(shù)方案應(yīng)該是某個技術(shù)所擅長的領(lǐng)域盡可能的自動化所有事情，好的監(jiān)控統(tǒng)計系統(tǒng)非常重要，可以幫助我們了解系統(tǒng)的運(yùn)行狀態(tài)、回溯問題、分析問題；及時告警，這個不僅僅是針對擴(kuò)展架構(gòu)，所有服務(wù)架構(gòu)都是一樣的。
可擴(kuò)展代碼的一些最佳實(shí)踐
參考（翻譯）Rackspace Writing Code that Scales 的寫出高擴(kuò)展和高性能代碼的工程原則：
首先就要編寫壓力測試計劃。比如支持 10w 個并發(fā)連接、響應(yīng)設(shè)計小于 200ms。這個就是我們的預(yù)期目標(biāo)，我們接下來的設(shè)計、規(guī)劃都要圍繞這個目標(biāo)以及超過目標(biāo)來進(jìn)行善于緩存。包括分布式緩存、本地緩存。少量頻繁訪問的可以本地緩存大部分情況下都能夠使用分布式緩存解決我們的數(shù)據(jù)緩存問題。（Redis）需要外網(wǎng)進(jìn)行網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)，能夠壓縮的盡量壓縮后傳輸?？蛻舳撕头?wù)端之間的數(shù)據(jù)交互，盡可能的壓縮。數(shù)據(jù)壓縮后的傳輸可以大大減少外網(wǎng)傳輸時間，并提高了單位時間的連接處理能力。壓縮的傳輸一定會比未壓縮后傳輸?shù)男矢撸啾染W(wǎng)絡(luò)傳輸?shù)臅r間，CPU 用來壓縮和解壓縮的時間是可以忽略的。關(guān)于磁盤 IO 如果有大量的數(shù)據(jù)需要存儲到磁盤上，然后需要讀寫，那么要進(jìn)行壓縮后存儲，雖然存儲便宜，但是 IO 消耗卻很大，壓縮后可以有效的提高 IO 吞吐量盡可能將隨機(jī) IO 模式替換為順序 IO 模式降低每個連接的開銷。一般而言，每個連接都需要一定的內(nèi)存，比如一個最基本的 TCP 連接可能需要 2k 的內(nèi)存；減少每個連接的開銷可以支持更多的連接處理更多的事情。入口流量設(shè)計準(zhǔn)入控制，需要有限流設(shè)計、隊列設(shè)計。后端服務(wù)雖然可以自動擴(kuò)縮容，但是它們的承受能力可能會有一個極限值，因此在極限值的時候就需要有限流措施，可以允許有一定的隊列任務(wù)堆積，但是不能無限制的增長隊列，當(dāng)請求量超過一定的極限后，這個時候不能繼續(xù)等待，而應(yīng)該快速失敗。如果持續(xù)等待，不加以限流措施，那么很可能會導(dǎo)致讓整個系統(tǒng)變得更慢，從而壓垮整個系統(tǒng)。關(guān)于通信協(xié)議，如果應(yīng)用程序的組件通過外網(wǎng)相互通信，或者在客戶端和服務(wù)器之間進(jìn)行了大量通信，盡可能將文本分析協(xié)議的使用降至最低，也即是減少 xml、json 協(xié)議，而應(yīng)該使用二進(jìn)制協(xié)議如 pb，
彈性伸縮設(shè)計
因為可擴(kuò)展和彈性伸縮是非常緊密的，因此這里也同時看看，要實(shí)現(xiàn)彈性伸縮，需要有哪些設(shè)計。
目前云上的架構(gòu)，基本都有自動彈性伸縮功能，服務(wù)部署到公有云或者私有云上，應(yīng)該是都能根據(jù) CPU 使用率等基本指標(biāo)來自動伸縮的。但是，當(dāng)我們想要自己設(shè)計一個自動伸縮的架構(gòu)，那么該怎么設(shè)計？
無狀態(tài)服務(wù)設(shè)計
要能夠彈性伸縮，服務(wù)一定是要無狀態(tài)的才能比較好的保證，有狀態(tài)服務(wù)的不太好實(shí)現(xiàn)彈性伸縮。
基礎(chǔ)鏡像輕量、快速啟動
實(shí)例啟動的時間很重要，如果不能快速啟動，那么當(dāng)檢測到需要伸縮的時候，如果擴(kuò)容很久才啟動新實(shí)例，那么擴(kuò)容期間是有損的，因此快速啟動是必須的?？焖賳拥囊粋€必要條件就是基礎(chǔ)鏡像要比較輕量，這樣的話，從拉取鏡像到啟動鏡像的過程就會比較快速；這個在容器時代的優(yōu)勢比較明顯，通過 Docker 可以比較好的滿足我們的訴求。
健康檢查
最好要有健康檢查模塊，能夠保證擴(kuò)容后的實(shí)例是可以正常 work 的，要不然擴(kuò)容了也沒用。同時如果服務(wù)異常，那么需要及時摘掉。當(dāng)然，其他基礎(chǔ)模塊也會對服務(wù)做健康檢查，這個設(shè)計就要根據(jù)整體架構(gòu)做取舍，看是否有更合適的健康檢查模塊，如果沒有，那么健康檢查放到哪里更為合適。
如果是在自動伸縮架構(gòu)中的健康檢查，那么需要檢測：
業(yè)務(wù)程序是否部署成功？需要有一個探測接口用來探測業(yè)務(wù)程序是否正常運(yùn)行業(yè)務(wù)服務(wù)是否能夠?qū)ν馓峁┝髁坎僮飨到y(tǒng)級別是否出現(xiàn)了異常
在 k8s 容器平臺下，健康檢查一般會有兩個地方來保證：
K8s 本身的 kubelet 來保障負(fù)載均衡代理層來保障
服務(wù)優(yōu)雅關(guān)閉
當(dāng)我們要自動縮容服務(wù)實(shí)例的時候，一個非常關(guān)鍵的地方就是，實(shí)時運(yùn)行的服務(wù)，如果直接關(guān)閉，勢必會對流量有損，這樣對業(yè)務(wù)服務(wù)、對客戶都有一定的影響。作為一個極致的技術(shù)人，我們必須要能夠保證服務(wù)可以優(yōu)雅關(guān)閉、優(yōu)雅下線。
一般會有如下幾個方式：
通知服務(wù)退出的時候，服務(wù)延遲退出，先摘掉流量，不讓新的請求進(jìn)來，然后預(yù)留時間把當(dāng)前正在處理的任務(wù)繼續(xù)處理完畢之后再退出。 這個就要求業(yè)務(wù)服務(wù)和彈性伸縮架構(gòu)能夠配合聯(lián)動起來，需要設(shè)計這么一個機(jī)制。K8s 就有這樣的機(jī)制，當(dāng)收到 TERMINATED 退出信號之后 Pod 可以不馬上退出，而是可以延遲一定的時間后再退出
自定義指標(biāo)來執(zhí)行彈性伸縮
一般來說，通過 CPU 、內(nèi)存的使用率來進(jìn)行彈性伸縮是最常用的功能，也挺有效果；在此基礎(chǔ)之上，我們還可以自定義一些指標(biāo)，可以更貼合業(yè)務(wù)，比如 QPS，通過這些個指標(biāo)來進(jìn)行彈性伸縮。
比如我們的 K8s 平臺，我們就擴(kuò)展了 QPS 指標(biāo)，還有一些比如流量帶寬之類的，但是 CPU 和 QPS 指標(biāo)是最常用的彈性伸縮指標(biāo)。
縮放比例尺設(shè)計
使用彈性縮放比例時，刪除實(shí)例時，應(yīng)用程序?qū)⒕哂幸欢ǖ目s放比例。應(yīng)用程序必須妥善處理要刪除的實(shí)例。以下是處理 scalein 的一些方法：
最好可以監(jiān)聽關(guān)閉（退出）事件，然后優(yōu)雅關(guān)閉。服務(wù)的客戶/消費(fèi)者應(yīng)支持瞬時故障處理和重試。對于長時間運(yùn)行的任務(wù)，應(yīng)該使用檢查點(diǎn)或“ 管道和過濾器”模式來分解工作。將工作項放在隊列中，以便另一個實(shí)例可以接管工作（如果在處理過程中刪除了一個實(shí)例）。
卸載資源密集型任務(wù)
盡可能將需要大量 CPU 或 I/O 資源的任務(wù)移至后臺作業(yè)，以最大程度地減少處理用戶請求的前端負(fù)載。
確定整個系統(tǒng)的瓶頸
擴(kuò)展并不是解決每個性能問題的靈丹妙藥，要先確定整個系統(tǒng)中哪個環(huán)境是瓶頸，這樣才能更好的擴(kuò)展。
推薦閱讀
推薦閱讀我的其他文章：
《高并發(fā)架構(gòu)和系統(tǒng)設(shè)計經(jīng)驗》
《TCP 長連接層的設(shè)計和 在 IM 項目中實(shí)戰(zhàn)應(yīng)用》
《萬字解讀云原生時代，如何從 0 到 1 構(gòu)建 K8s 容器平臺的 LB（Nginx）負(fù)載均衡體系》
《高可用架構(gòu)和系統(tǒng)設(shè)計經(jīng)驗》
標(biāo)簽：
微服務(wù)架構(gòu)
架構(gòu)設(shè)計
彈性伸縮
