可擴(kuò)展和彈性伸縮系統(tǒng)設(shè)計(jì)

可擴(kuò)展架構(gòu)基礎(chǔ)

可擴(kuò)展架構(gòu)的背景

軟件系統(tǒng)是可以隨著需求變化或者技術(shù)變化而不斷擴(kuò)展和迭代的，我們常見(jiàn)的各種軟件系統(tǒng)比如操作系統(tǒng)、各種知名開(kāi)源軟件系統(tǒng)都是如此。而在這個(gè)過(guò)程中，我們?nèi)绾瓮ㄟ^(guò)較小的代價(jià)去擴(kuò)展我們的系統(tǒng)，是我們要重點(diǎn)考慮的。

可擴(kuò)展的基本思想：拆分（流程、服務(wù)、功能）

可擴(kuò)展性架構(gòu)的設(shè)計(jì)方法雖然很多，但是最核心的思想就是拆分。將大系統(tǒng)拆分為小系統(tǒng)、小模塊，然后針對(duì)其中的子系統(tǒng)或者模塊來(lái)進(jìn)行擴(kuò)展，這樣可以通過(guò)較小的改動(dòng)去實(shí)現(xiàn)整個(gè)系統(tǒng)的擴(kuò)展能力，可以同時(shí)滿足擴(kuò)展需求和改動(dòng)的風(fēng)險(xiǎn)。

(相關(guān)資料圖)

拆分的方式包括 流程、服務(wù)、功能 三部分，理解這三種思路的關(guān)鍵就在于如何理解“流程”“服務(wù)”“功能”三者的聯(lián)系和區(qū)別。從范圍上來(lái)看，從大到小依次為：流程 > 服務(wù) > 功能。以 TCP/IP 協(xié)議棧為例，來(lái)說(shuō)明“流程”“服務(wù)”“功能”的區(qū)別和聯(lián)系：

流程對(duì)應(yīng) TCP/IP 四層模型，因?yàn)?TCP/IP 網(wǎng)絡(luò)通信流程是：應(yīng)用層 → 傳輸層 → 網(wǎng)絡(luò)層 → 物理 + 數(shù)據(jù)鏈路層，不管最上層的應(yīng)用層是什么，這個(gè)流程都不會(huì)變。服務(wù)對(duì)應(yīng)應(yīng)用層的 HTTP、FTP、SMTP 等服務(wù)，HTTP 提供 Web 服務(wù)，F(xiàn)TP 提供文件服務(wù)，SMTP 提供郵件服務(wù)，以此類推。功能每個(gè)服務(wù)都會(huì)提供相應(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ò)展的時(shí)候，可能只需要修改其中一層就可以進(jìn)行功能擴(kuò)展。一個(gè)典型的分層架構(gòu)系統(tǒng)的擴(kuò)展就是對(duì)數(shù)據(jù)層的擴(kuò)展，比如之前只支持 MySQL，現(xiàn)在需要同時(shí)支持 MySQL 和 Elasticserach，那么只需要 在數(shù)據(jù)層進(jìn)行修改擴(kuò)展即可不太常見(jiàn)的 2 層架構(gòu)（C/S 架構(gòu)、B/S 架構(gòu)）。通過(guò)用戶交互維度來(lái)劃分，和用戶交互的是一層、支持交互的后端系統(tǒng)是一層。常見(jiàn)的是 3 層架構(gòu)（MVC、MVP 架構(gòu)）。一般通過(guò)業(yè)務(wù)功能職責(zé)來(lái)劃分。還有一些 2 層架構(gòu)（C/S 架構(gòu)、B/S 架構(gòu)）。通過(guò)用戶交互維度來(lái)劃分，和用戶交互的是一層、支持交互的后端系統(tǒng)是一層。常見(jiàn)的邏輯分層架構(gòu)。比如操作系統(tǒng)的邏輯分層架構(gòu)、比如一般我們后臺(tái)業(yè)務(wù)系統(tǒng)里面的分層架構(gòu)。面向服務(wù)拆分（SOA、微服務(wù)）。這個(gè)是現(xiàn)在最常見(jiàn)的架構(gòu)設(shè)計(jì)，因?yàn)槎际俏⒎?wù)形態(tài)，那么擴(kuò)展的時(shí)候，只需要針對(duì)每個(gè)獨(dú)立運(yùn)行的微服務(wù)進(jìn)行擴(kuò)展，其他服務(wù)無(wú)感知，這樣修改的粒度很小，擴(kuò)展會(huì)比較容易。面向功能拆分（微內(nèi)核架構(gòu)）。這個(gè)是我最近才了解到的一種架構(gòu)設(shè)計(jì)，針對(duì)這種架構(gòu)，對(duì)某個(gè)功能擴(kuò)展，或者要增加新的功能時(shí)，只需要擴(kuò)展相關(guān)功能即可，無(wú)須修改所有的服務(wù)。

響應(yīng)時(shí)間 和 可伸縮性 的關(guān)系

可擴(kuò)展性（Scalability）與性能是不能混為一談的，性能 != 可擴(kuò)展。性能是指系統(tǒng)提供一定響應(yīng)時(shí)間的能力；可擴(kuò)展性是指我們可以很容易的通過(guò)擴(kuò)容集群、擴(kuò)容數(shù)據(jù)庫(kù)、擴(kuò)容實(shí)例等簡(jiǎn)單的方式來(lái)提供整體的并發(fā)能力，這樣的話，只要請(qǐng)求訪問(wèn)量增加，我們就可以通過(guò)擴(kuò)展機(jī)器的方式來(lái)適應(yīng)請(qǐng)求量的增加。系統(tǒng)可以是高性能的，但可能是不可擴(kuò)展的。

性能（performance）-> 響應(yīng)時(shí)間： 接口請(qǐng)求的響應(yīng)時(shí)間可伸縮性（Scalability）： 包括橫向擴(kuò)展（Scaling Out）和縱向擴(kuò)展（Scaling Up ）橫向擴(kuò)展（水平擴(kuò)展）： 增加實(shí)例、增加機(jī)器縱向擴(kuò)展（垂直擴(kuò)展）： 增加硬件配置如 CPU 核數(shù)；使用更高性能的 CPU、網(wǎng)卡等；增加內(nèi)存容量；

但是這里需要注意的是響應(yīng)時(shí)間 和 可伸縮性可能不是同步的或者是線性的，也就是說(shuō)當(dāng)請(qǐng)求量增加，并且進(jìn)行各種擴(kuò)容后，雖然抗住了請(qǐng)求量，但是響應(yīng)時(shí)間不見(jiàn)得會(huì)變短，可能會(huì)變長(zhǎng)，因?yàn)檎?qǐng)求量的增加導(dǎo)致底層的各種系統(tǒng)資源消耗較多或者下游的依賴壓力較大從而導(dǎo)致響應(yīng)時(shí)間變長(zhǎng)。

系統(tǒng)資源 和 水平擴(kuò)展的關(guān)系

請(qǐng)求量增加的時(shí)候，要進(jìn)行擴(kuò)容，擴(kuò)容最容易和最常見(jiàn)的方式是水平擴(kuò)展服務(wù)，也就是擴(kuò)容無(wú)狀態(tài)實(shí)例。但是，針對(duì)一些系統(tǒng)資源或者依賴資源，比如數(shù)據(jù)庫(kù)（MySQL）、緩存（Redis）等，這些有狀態(tài)的不能無(wú)限擴(kuò)容，因此就一定考慮他們的性能，他們的性能才是底線，如果 redis 、ES 等扛不住，那么擴(kuò)容再多無(wú)狀態(tài)實(shí)例也是白費(fèi)。這里需要特別注意這些底層依賴資源的性能以及無(wú)狀態(tài)服務(wù)和他們連接的一些連接池、并發(fā)數(shù)等。

可擴(kuò)展和 彈性伸縮的關(guān)系

可擴(kuò)展性是指系統(tǒng)適應(yīng)更大的負(fù)載的能力，只需通過(guò)增加資源，使硬件更強(qiáng)大（擴(kuò)展）或增加額外的節(jié)點(diǎn)（擴(kuò)展）。

彈性伸縮是指動(dòng)態(tài)地適應(yīng)應(yīng)對(duì)負(fù)載所需的資源的能力，通常與擴(kuò)展性有關(guān)。因此，當(dāng)負(fù)載增加時(shí)，你通過(guò)添加更多的資源來(lái)擴(kuò)大規(guī)模，而當(dāng)需求減弱時(shí)，你就縮減并刪除不需要的資源。 彈性伸縮在云環(huán)境中非常重要，一方面你要按使用量付費(fèi)，不想為你目前不需要的資源付費(fèi)，另一方面要在需要時(shí)滿足不斷增長(zhǎng)的需求。

可擴(kuò)展架構(gòu)設(shè)計(jì)（Scalability）

可擴(kuò)展架構(gòu)設(shè)計(jì)的最佳實(shí)踐

一些最佳實(shí)踐可以參考（翻譯） OpenShift 的 Best Practices for Scaling Out 這篇文章，這里在此基礎(chǔ)上做進(jìn)一步的整理和總結(jié)：

微服務(wù)化設(shè)計(jì)，盡量讓我們的系統(tǒng)模塊化、組件化，從而實(shí)現(xiàn)高內(nèi)聚，低耦合的思想，提高復(fù)用性，擴(kuò)展性。這樣每個(gè)微服務(wù)可以獨(dú)立進(jìn)行擴(kuò)展，而且一個(gè)服務(wù)掛掉并不會(huì)導(dǎo)致整個(gè)服務(wù)不可用；這個(gè)也同樣適用于數(shù)據(jù)庫(kù)的拆分邏輯。分層設(shè)計(jì)，可擴(kuò)展架構(gòu)設(shè)計(jì)的基本要求就是我們服務(wù)要先進(jìn)行分層，然后每一層都要能夠單獨(dú)擴(kuò)展，并且需要用到負(fù)載均衡技術(shù)。消息隊(duì)列：模塊化的系統(tǒng)通過(guò)消息隊(duì)列進(jìn)行交互，使模塊之間的依賴解耦。隊(duì)列的引入可以緩解流量突峰，也可以流程異步化，提高性能、穩(wěn)定性。 高并發(fā)、大流量下，同步機(jī)制會(huì)使得整體響應(yīng)非常慢，因此當(dāng)前一般的高并發(fā)系統(tǒng)都是異步處理的，一般我們可以通過(guò)消息隊(duì)列實(shí)現(xiàn)異步。分布式服務(wù)：公用模塊服務(wù)化，提供其他系統(tǒng)使用，提高可重用性，擴(kuò)展性。聯(lián)系緊密的服務(wù)盡量部署到同一個(gè)集群，避免跨集群訪問(wèn)帶來(lái)的延遲、帶寬增加等應(yīng)用程序應(yīng)該盡量采用無(wú)狀態(tài)服務(wù)，而不是采用有狀態(tài)服務(wù)；將需要存儲(chǔ)的狀態(tài)統(tǒng)一用分布式存儲(chǔ)、分布式緩存來(lái)存儲(chǔ)。善用分布式緩存；訪問(wèn)緩存比訪問(wèn)數(shù)據(jù)庫(kù)或者文件系統(tǒng)性能高很多，避免直接操作數(shù)據(jù)庫(kù)，可以極大提高性能設(shè)計(jì)模式：應(yīng)用面向?qū)ο笏枷?，原則，使用設(shè)計(jì)模式，進(jìn)行代碼層面的設(shè)計(jì)。網(wǎng)關(guān)入口要使用負(fù)載均衡層，常見(jiàn)的是 Nginx 和 HAProxy，當(dāng)做 7 層代理集群，然后后面再接入應(yīng)用服務(wù)。使用代理層是可擴(kuò)展架構(gòu)的必要前提。不要過(guò)度設(shè)計(jì)，根據(jù)情況考慮是否最初就設(shè)計(jì)為可擴(kuò)展架構(gòu)，不必從一開(kāi)始就構(gòu)建可伸縮的體系結(jié)構(gòu)，擴(kuò)展的關(guān)鍵是先于用戶發(fā)現(xiàn)瓶頸。不要強(qiáng)迫將自己熟知的技術(shù)運(yùn)用到不恰當(dāng)?shù)念I(lǐng)域來(lái)解決特定領(lǐng)域的問(wèn)題；所用來(lái)解決問(wèn)題的技術(shù)方案應(yīng)該是某個(gè)技術(shù)所擅長(zhǎng)的領(lǐng)域盡可能的自動(dòng)化所有事情，好的監(jiān)控統(tǒng)計(jì)系統(tǒng)非常重要，可以幫助我們了解系統(tǒng)的運(yùn)行狀態(tài)、回溯問(wèn)題、分析問(wèn)題；及時(shí)告警，這個(gè)不僅僅是針對(duì)擴(kuò)展架構(gòu)，所有服務(wù)架構(gòu)都是一樣的。

可擴(kuò)展代碼的一些最佳實(shí)踐

參考（翻譯）Rackspace Writing Code that Scales 的寫(xiě)出高擴(kuò)展和高性能代碼的工程原則：

首先就要編寫(xiě)壓力測(cè)試計(jì)劃。比如支持 10w 個(gè)并發(fā)連接、響應(yīng)設(shè)計(jì)小于 200ms。這個(gè)就是我們的預(yù)期目標(biāo)，我們接下來(lái)的設(shè)計(jì)、規(guī)劃都要圍繞這個(gè)目標(biāo)以及超過(guò)目標(biāo)來(lái)進(jìn)行善于緩存。包括分布式緩存、本地緩存。少量頻繁訪問(wèn)的可以本地緩存大部分情況下都能夠使用分布式緩存解決我們的數(shù)據(jù)緩存問(wèn)題。（Redis）需要外網(wǎng)進(jìn)行網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)，能夠壓縮的盡量壓縮后傳輸?？蛻舳撕头?wù)端之間的數(shù)據(jù)交互，盡可能的壓縮。數(shù)據(jù)壓縮后的傳輸可以大大減少外網(wǎng)傳輸時(shí)間，并提高了單位時(shí)間的連接處理能力。壓縮的傳輸一定會(huì)比未壓縮后傳輸?shù)男矢?，相比網(wǎng)絡(luò)傳輸?shù)臅r(shí)間，CPU 用來(lái)壓縮和解壓縮的時(shí)間是可以忽略的。關(guān)于磁盤 IO 如果有大量的數(shù)據(jù)需要存儲(chǔ)到磁盤上，然后需要讀寫(xiě)，那么要進(jìn)行壓縮后存儲(chǔ)，雖然存儲(chǔ)便宜，但是 IO 消耗卻很大，壓縮后可以有效的提高 IO 吞吐量盡可能將隨機(jī) IO 模式替換為順序 IO 模式降低每個(gè)連接的開(kāi)銷。一般而言，每個(gè)連接都需要一定的內(nèi)存，比如一個(gè)最基本的 TCP 連接可能需要 2k 的內(nèi)存；減少每個(gè)連接的開(kāi)銷可以支持更多的連接處理更多的事情。入口流量設(shè)計(jì)準(zhǔn)入控制，需要有限流設(shè)計(jì)、隊(duì)列設(shè)計(jì)。后端服務(wù)雖然可以自動(dòng)擴(kuò)縮容，但是它們的承受能力可能會(huì)有一個(gè)極限值，因此在極限值的時(shí)候就需要有限流措施，可以允許有一定的隊(duì)列任務(wù)堆積，但是不能無(wú)限制的增長(zhǎng)隊(duì)列，當(dāng)請(qǐng)求量超過(guò)一定的極限后，這個(gè)時(shí)候不能繼續(xù)等待，而應(yīng)該快速失敗。如果持續(xù)等待，不加以限流措施，那么很可能會(huì)導(dǎo)致讓整個(gè)系統(tǒng)變得更慢，從而壓垮整個(gè)系統(tǒng)。關(guān)于通信協(xié)議，如果應(yīng)用程序的組件通過(guò)外網(wǎng)相互通信，或者在客戶端和服務(wù)器之間進(jìn)行了大量通信，盡可能將文本分析協(xié)議的使用降至最低，也即是減少 xml、json 協(xié)議，而應(yīng)該使用二進(jìn)制協(xié)議如 pb，

彈性伸縮設(shè)計(jì)

因?yàn)榭蓴U(kuò)展和彈性伸縮是非常緊密的，因此這里也同時(shí)看看，要實(shí)現(xiàn)彈性伸縮，需要有哪些設(shè)計(jì)。

目前云上的架構(gòu)，基本都有自動(dòng)彈性伸縮功能，服務(wù)部署到公有云或者私有云上，應(yīng)該是都能根據(jù) CPU 使用率等基本指標(biāo)來(lái)自動(dòng)伸縮的。但是，當(dāng)我們想要自己設(shè)計(jì)一個(gè)自動(dòng)伸縮的架構(gòu)，那么該怎么設(shè)計(jì)？

無(wú)狀態(tài)服務(wù)設(shè)計(jì)

要能夠彈性伸縮，服務(wù)一定是要無(wú)狀態(tài)的才能比較好的保證，有狀態(tài)服務(wù)的不太好實(shí)現(xiàn)彈性伸縮。

基礎(chǔ)鏡像輕量、快速啟動(dòng)

實(shí)例啟動(dòng)的時(shí)間很重要，如果不能快速啟動(dòng)，那么當(dāng)檢測(cè)到需要伸縮的時(shí)候，如果擴(kuò)容很久才啟動(dòng)新實(shí)例，那么擴(kuò)容期間是有損的，因此快速啟動(dòng)是必須的?？焖賳?dòng)的一個(gè)必要條件就是基礎(chǔ)鏡像要比較輕量，這樣的話，從拉取鏡像到啟動(dòng)鏡像的過(guò)程就會(huì)比較快速；這個(gè)在容器時(shí)代的優(yōu)勢(shì)比較明顯，通過(guò) Docker 可以比較好的滿足我們的訴求。

健康檢查

最好要有健康檢查模塊，能夠保證擴(kuò)容后的實(shí)例是可以正常 work 的，要不然擴(kuò)容了也沒(méi)用。同時(shí)如果服務(wù)異常，那么需要及時(shí)摘掉。當(dāng)然，其他基礎(chǔ)模塊也會(huì)對(duì)服務(wù)做健康檢查，這個(gè)設(shè)計(jì)就要根據(jù)整體架構(gòu)做取舍，看是否有更合適的健康檢查模塊，如果沒(méi)有，那么健康檢查放到哪里更為合適。

如果是在自動(dòng)伸縮架構(gòu)中的健康檢查，那么需要檢測(cè)：

業(yè)務(wù)程序是否部署成功？需要有一個(gè)探測(cè)接口用來(lái)探測(cè)業(yè)務(wù)程序是否正常運(yùn)行業(yè)務(wù)服務(wù)是否能夠?qū)ν馓峁┝髁坎僮飨到y(tǒng)級(jí)別是否出現(xiàn)了異常

在 k8s 容器平臺(tái)下，健康檢查一般會(huì)有兩個(gè)地方來(lái)保證：

K8s 本身的 kubelet 來(lái)保障負(fù)載均衡代理層來(lái)保障

服務(wù)優(yōu)雅關(guān)閉

當(dāng)我們要自動(dòng)縮容服務(wù)實(shí)例的時(shí)候，一個(gè)非常關(guān)鍵的地方就是，實(shí)時(shí)運(yùn)行的服務(wù)，如果直接關(guān)閉，勢(shì)必會(huì)對(duì)流量有損，這樣對(duì)業(yè)務(wù)服務(wù)、對(duì)客戶都有一定的影響。作為一個(gè)極致的技術(shù)人，我們必須要能夠保證服務(wù)可以優(yōu)雅關(guān)閉、優(yōu)雅下線。

一般會(huì)有如下幾個(gè)方式：

通知服務(wù)退出的時(shí)候，服務(wù)延遲退出，先摘掉流量，不讓新的請(qǐng)求進(jìn)來(lái)，然后預(yù)留時(shí)間把當(dāng)前正在處理的任務(wù)繼續(xù)處理完畢之后再退出。 這個(gè)就要求業(yè)務(wù)服務(wù)和彈性伸縮架構(gòu)能夠配合聯(lián)動(dòng)起來(lái)，需要設(shè)計(jì)這么一個(gè)機(jī)制。K8s 就有這樣的機(jī)制，當(dāng)收到 TERMINATED 退出信號(hào)之后 Pod 可以不馬上退出，而是可以延遲一定的時(shí)間后再退出

自定義指標(biāo)來(lái)執(zhí)行彈性伸縮

一般來(lái)說(shuō)，通過(guò) CPU 、內(nèi)存的使用率來(lái)進(jìn)行彈性伸縮是最常用的功能，也挺有效果；在此基礎(chǔ)之上，我們還可以自定義一些指標(biāo)，可以更貼合業(yè)務(wù)，比如 QPS，通過(guò)這些個(gè)指標(biāo)來(lái)進(jìn)行彈性伸縮。

比如我們的 K8s 平臺(tái)，我們就擴(kuò)展了 QPS 指標(biāo)，還有一些比如流量帶寬之類的，但是 CPU 和 QPS 指標(biāo)是最常用的彈性伸縮指標(biāo)。

縮放比例尺設(shè)計(jì)

使用彈性縮放比例時(shí)，刪除實(shí)例時(shí)，應(yīng)用程序?qū)⒕哂幸欢ǖ目s放比例。應(yīng)用程序必須妥善處理要?jiǎng)h除的實(shí)例。以下是處理 scalein 的一些方法：

最好可以監(jiān)聽(tīng)關(guān)閉（退出）事件，然后優(yōu)雅關(guān)閉。服務(wù)的客戶/消費(fèi)者應(yīng)支持瞬時(shí)故障處理和重試。對(duì)于長(zhǎng)時(shí)間運(yùn)行的任務(wù)，應(yīng)該使用檢查點(diǎn)或“ 管道和過(guò)濾器”模式來(lái)分解工作。將工作項(xiàng)放在隊(duì)列中，以便另一個(gè)實(shí)例可以接管工作（如果在處理過(guò)程中刪除了一個(gè)實(shí)例）。

卸載資源密集型任務(wù)

盡可能將需要大量 CPU 或 I/O 資源的任務(wù)移至后臺(tái)作業(yè)，以最大程度地減少處理用戶請(qǐng)求的前端負(fù)載。

確定整個(gè)系統(tǒng)的瓶頸

擴(kuò)展并不是解決每個(gè)性能問(wèn)題的靈丹妙藥，要先確定整個(gè)系統(tǒng)中哪個(gè)環(huán)境是瓶頸，這樣才能更好的擴(kuò)展。

推薦閱讀

推薦閱讀我的其他文章：

《高并發(fā)架構(gòu)和系統(tǒng)設(shè)計(jì)經(jīng)驗(yàn)》

《TCP 長(zhǎng)連接層的設(shè)計(jì)和 在 IM 項(xiàng)目中實(shí)戰(zhàn)應(yīng)用》

《萬(wàn)字解讀云原生時(shí)代，如何從 0 到 1 構(gòu)建 K8s 容器平臺(tái)的 LB（Nginx）負(fù)載均衡體系》

《高可用架構(gòu)和系統(tǒng)設(shè)計(jì)經(jīng)驗(yàn)》

標(biāo)簽： 微服務(wù)架構(gòu) 架構(gòu)設(shè)計(jì) 彈性伸縮