2.1 系統(tǒng)架構(gòu)基礎(chǔ)

幾乎所有大規(guī)模系統(tǒng)都是從小規(guī)模開始，在成功路上逐漸發(fā)展壯大。從Ruby on Rails、Django或類似的開發(fā)框架開始架構(gòu)系統(tǒng)是常見且明智的做法，它們可以加速開發(fā)，使系統(tǒng)得以快速啟動并運行。基于一個典型且簡單的軟件架構(gòu)來啟動你的系統(tǒng)開發(fā)，與采用快速開發(fā)框架獲得的效果相似，如圖2-1所示。此架構(gòu)包括客戶端層、應(yīng)用服務(wù)層和數(shù)據(jù)庫層。如果你使用Rails或類似產(chǎn)品，那么可以直接獲得以下便利：內(nèi)置了處理Web應(yīng)用程序的MVC（模型-視圖-控制器）模式和生成SQL查詢的ORM（對象-關(guān)系映射器）。

使用上述架構(gòu)，用戶從移動應(yīng)用程序或Web（網(wǎng)頁）瀏覽器向系統(tǒng)提交請求。互聯(lián)網(wǎng)網(wǎng)絡(luò)的魔力（參見第3章）將請求傳遞給運行在企業(yè)或商業(yè)云數(shù)據(jù)中心的機器上的應(yīng)用服務(wù)。通信使用標(biāo)準(zhǔn)的應(yīng)用層網(wǎng)絡(luò)協(xié)議，通常是HTTP。

圖2-1：簡單的多層分布式系統(tǒng)架構(gòu)

應(yīng)用服務(wù)運行了API的代碼，支持客戶端發(fā)送的HTTP請求。收到請求后，服務(wù)會執(zhí)行與請求的API關(guān)聯(lián)的代碼。在此過程中，可能會讀取數(shù)據(jù)庫的數(shù)據(jù)，或?qū)懭霐?shù)據(jù)庫，或?qū)懭肫渌獠肯到y(tǒng)，具體取決于API的語義。請求完成后，服務(wù)會將結(jié)果發(fā)送回客戶端，結(jié)果在客戶端應(yīng)用程序或瀏覽器中顯示。

許多系統(tǒng)在概念上看起來與上述描述一致。應(yīng)用服務(wù)代碼利用服務(wù)器執(zhí)行環(huán)境，同時處理來自多個用戶的多個請求。應(yīng)用服務(wù)器技術(shù)有無數(shù)種——例如，Java EE和Java的Spring框架，Python的Flask（https://oreil.ly/8FYu5）——它們在上述場景中被廣泛使用。

這種方法通常會產(chǎn)生所說的單體架構(gòu)^[1]。隨著應(yīng)用程序的特性變得更加豐富，單體應(yīng)用程序的復(fù)雜性往往會增加。所有API處理程序都內(nèi)置在同一個服務(wù)器代碼中，最終會讓快速修改和測試變得困難。由于所有API實現(xiàn)都在同一個應(yīng)用服務(wù)中運行，執(zhí)行足跡可能變得極其繁雜。

盡管如此，如果請求的負(fù)載壓力保持較低的水平，則此應(yīng)用程序架構(gòu)足夠了，服務(wù)足以處理請求并保持低延遲。如果請求負(fù)載持續(xù)增長，則意味著延遲增加，因為服務(wù)沒有足夠的CPU和內(nèi)存來同時處理大量的并發(fā)請求，請求將需要等待更長的時間。在這種情況下，單臺服務(wù)器已經(jīng)超載，成了性能瓶頸。

對于上述案例，第一個擴展策略通常是“擴展”應(yīng)用服務(wù)的硬件。假設(shè)你的應(yīng)用程序運行在AWS上，你可以將服務(wù)器從帶有四個CPU（虛擬）和16 GB內(nèi)存的普通t3.xlarge實例升級到t3.2xlarge實例，為應(yīng)用程序提供翻倍的CPU和可用內(nèi)存^[2]。

擴展很簡單，它使現(xiàn)實世界的許多應(yīng)用程序在支持更大的工作負(fù)載方面取得了長足的進步。顯然，擴展硬件要花更多的錢，但也物有所值，擴展后的系統(tǒng)滿足了你的實際需求。

然而，不可避免的是，對于許多應(yīng)用程序，無論你擁有多少CPU和多少內(nèi)存，負(fù)載都將增長到超出單個服務(wù)器節(jié)點所能服務(wù)的范圍。這時你需要一個新的策略，即第1章提及的，橫向擴展或水平擴展^[3]。