擴展 Web 應用程序的架構問題

擴展 Web 應用程序的架構問題

標籤（空格分隔）： Architecture Scaling Web Applications

---

該文原文是 Architecture Issues Scaling Web Applications

我將在這篇博客中揭露出當咱們擴展和性能調優大型 Web 應用程序時遇到的架構問題。

讓咱們經過定義幾個術語來創造共同的理解和詞彙開始。稍後當擴展 Web 應用程序時，我將經過不一樣的問題拋出，像：

• 架構瓶頸
• 擴展數據庫
• CPU 限制應用
• IO 限制應用

肯定一個 Web 應用程序的最佳線程池將在下一篇博客討論。

性能

術語 Web 應用程序性能是指的幾件事情。大多數開發人員關心的主要是響應時間和可伸縮性。

• 響應時間

  是指 web 應用程序處理請求和返回響應所花費的時間。應用程序應該在可接受的時間範圍內響應請求（響應時間）。若是應用程序超過了可接受的時間範圍，它是被認爲性能不行或是降級的。

• 可擴展性

  Web 應用程序若是能被添加更多硬件，是被認爲有可擴展性，應用程序能夠比之前線性的處理更多請求。有兩種方式增長硬件：

  • Scaling Up（垂直擴展）：在單個系統裏面增長 CPU 數量或是換更快的 CPU
  • Scaling Out（水平擴展）：增長系統數

垂直擴展 VS 水平擴展

水平擴展是被認爲更重要的，當商品硬件自己相對於特殊配置的硬件（超級電腦）便宜的時候。可是增長單個系統一個應用程序的所能處理的請求數也是重要的。一個應用程序被認爲性能優良，若是它僅僅經過增長資源就能在不降級響應時間的前提下處理更多的請求。

響應時間 VS 可擴展性

響應時間和可擴展性不是總在一塊兒的。好比應用程序或許有可接受的響應時間，但可能沒法處理超過必定數量的請求，或是應用程序能夠處理增長的請求數，可是響應時間很是長。咱們必須在可擴展性和響應時間之間的取得平衡來獲取更好的應用程序性能

容量規劃

容量規範是一個計算出所須要的硬件來處理生產預期的負荷的實踐。一般它涉及計算出更少系統的狀況下應用程序的性能和基於每一個系統突出性能。最後，滿載/性能測試驗證它。

易擴展的架構

若是在一個多層架構中每層都是可擴展的，那麼應用程序是可擴展的（水平擴展）。例如：像下圖顯示的，經過在應用層和數據庫層添加系統，咱們應該有線性擴展能力。

擴展負載均衡器

負載均衡器能夠被水平擴展經過把 DNS 指向多個 IP 地址和使用 DNS 輪詢 IP 地址。其餘選項是前面另外一個負載均衡器分發負載下一級負載平衡器。

添加多個負載平衡器是罕見的，由於單個系統運行 nginx 或 HAProxy 能夠處理超過 20K 的併發鏈接，相比於每一個系統只有 Web 應用程序處理幾千個併發鏈接。所以單個負債均衡系統能夠處理多個 Web 應用程序系統。

擴展數據庫

擴展數據庫是須要面對的常見問題之一。添加業務邏輯（存儲過程、函數）在數據庫層帶來額外的開銷和複雜性

關係型數據庫

關係型數據庫能夠經過主-從模式擴展，在主服務器上可讀寫，在從服務器上只讀。主從模式提供有限的讀擴展，開發人員必須將數據庫分紅多個數據庫。

NoSQL

CAP 定理 顯示了是不可能同時得到一致性，可用性和分區容錯的。NoSql 數據庫一般是在一致性方面妥協來得到高可用性和分區。

拆分數據庫

數據庫能夠被垂直（分區）和水平（分片）拆分：

• 垂直拆分（分區） - 基於領域概念，數據庫能夠被拆分紅多個鬆耦合的子數據庫。好比：客戶數據庫，產品數據庫等。另一個拆分數據庫的方式是移動實體的幾列到一個數據庫，另一些列到另一個數據庫。好比：客戶數據庫，客戶聯繫方式數據庫，客戶訂單數據庫等。
• 水平拆分（分片） - 數據庫能夠被水平拆分進多個數據庫中基於一些離散的屬性。好比：美國客戶數據庫，歐洲客戶數據庫。

使用分區或分片從單個數據庫到多個數據庫過渡是一項頗有挑戰的任務。

架構瓶頸

因爲兩個問題會造成擴展瓶頸：

• 中央化組件：在應用架構中的一個添加了請求上限數的組件不能被水平擴展，整個架構和請求管道能夠被處理。
• 高延遲組件：在請求管道中的慢組件將下降應用程序的響應時間限制。一般的解決方案是使得高延遲的組件進入後臺任務或在隊列中異步執行它們。

CPU 限制應用

若是一個應用程序的吞吐量被它的 CPU 限制了，那就認爲這個應用是 CPU 限制的。經過提高 CPU 的速度，應用響應時間能夠被下降。

幾個場景中的應用多是 CPU 限制：

• 執行計算和處理數據可是沒有執行 I/O 操做的應用程序（金融 或交易應用程序）。
• 重度使用緩存而且沒有執行 I/O 操做的應用程序
• 異步（非阻塞）的應用程序，不須要等待額外的資源（被動模式應用。NodeJS 應用）

在以上的場景中，應用程序已經在有效的工做，但在一些狀況下應用程序寫得很糟糕的或者低效的代碼執行沒必要要的繁重計算或是循環在每次請求時每每表現出較高的CPU使用率。經過分析應用程序很容易找出不足並修復它們。

這些問題能夠被修復：

• 緩存預先計算的值
• 在單獨的後臺任務中執行計算

不一樣方式的緩存，緩存怎樣能夠下降負載以及提高性能和 web 應用程序的可伸縮性在這篇博客中 Caching To Scale Web Applications。

I/O 限制應用

若是一個應用的吞吐量被它的 I/O 或是網絡操做和提高 CPU 速度不能下降應用程序的響應時間，那該應用就被認爲是 I/O 限制的。大部分應用是 I/O 限制的，因爲 CRUD 操做，在大部分應用性能調優或擴展 I/O 限制應用程序是項很是難的工做，因爲它依賴於下游其餘系統。

幾個場景中的應用多是 I/O 限制：

• 依賴於數據庫和執行 CRUD 操做的應用程序
• 消費下游的 Web 服務來執行其操做的應用程序