設定您的應用程式：如何選擇最佳的伺服器配置？

簡介

科技與網路已成為我們日常生活、學術和職業生涯的核心。這就是為什麼同時存在如此龐大數量的網站和應用程式並不足為奇。如果您是一家企業，您會希望擁有一個相關聯的網路平台。應用程式能讓您輕鬆地向目標客戶推廣並提供您的服務。

無論您建立網路應用程式的原因為何，您都需要決定如何建置它。在選擇最佳伺服器設定時，有許多選項可供您選擇。您選擇的伺服器架構將決定您如何運行和管理環境中的一切。這就是為什麼必須在深思熟慮後做出決定。

如何選擇合適的伺服器設定

那麼，您要如何決定哪種架構最「適合」您的應用程式？為此，您需要先思考您的網路應用程式有哪些需求。必須包含某些特定功能，才能使其在您的特定使用場景中高效運作。例如，也許您正在努力打造一個易於擴充的應用程式。或者，也許您需要您的應用程式在瀏覽器和行動裝置上都能順暢運行。同時，您的預算也可能是您最關心的問題。

無論您的需求是什麼，您都應該知道您可以為您的應用程式建立自訂解決方案。在本教學中，我們將探討許多人常用於其網路應用程式的各種伺服器類型。我們將討論各種使用場景以及何時最適合使用某種設定。為了幫助您決定它是否適合您，我們還將為您提供每種伺服器架構的一些優缺點。

1. 所有東西都在單一伺服器上

顧名思義，您將整個環境載入到單一伺服器上。該環境將包括您的網頁伺服器、應用程式伺服器以及資料庫伺服器。例如，它適用於Linux, Apache, MySQL、以及PHP (LAMP) 軟體堆疊設定。您可以參考我們的教學，了解如何在 Ubuntu 伺服器上安裝 LAMP 軟體堆疊以及如何在 CentOS 上安裝 LAMP 軟體堆疊.

何時使用：

如果您時間緊迫，這種配置最適合。它設定簡單且快速。這就是為什麼它適用於簡單的網路應用程式。

優點：

• 簡單且易於理解和實作。
• 完整設定所需的時間很少。

缺點：

• 不允許水平擴充。
• 在元件隔離方面提供的支援極少。
• 由於應用程式和資料庫位於單一伺服器上，它們基本上是在競爭相同的資源。
• 因此，您可能會遇到效能不佳的問題。

2. 獨立的資料庫伺服器

使用單一伺服器的主要問題是競爭有限的資源。此設定旨在解決該問題。在這裡，資料庫管理系統（或稱 DBMS）與應用程式伺服器分開。資料庫伺服器位於私有網路中，並擁有自己的資源。這能帶來更好的效能和更高的安全性。

何時使用：

同樣地，如果您想快速部署，這非常容易設定。如果您擔心資料庫和應用程式競爭相同資源，這是理想的解決方案。

優點：

• 應用程式和資料庫各自擁有獨立、專用的系統資源，包括 CPU、記憶體、I/O 等。
• 應用程式層或資料庫層都具有更大的擴充潛力。
• 您可以根據需要新增和移除資源。
• 如果您將資料庫從公開網際網路中移除，您還可以提升安全性。

缺點：

• 比單一伺服器設定稍微複雜一些。
• 兩台伺服器之間的低頻寬或高延遲網路連線可能會導致效能問題。

3. 反向代理或負載平衡器

這就是負載平衡器 便派上用場。負載平衡器通常用於伺服器環境中，以提高效能和可靠性。它們透過「平衡負載」來實現這一點；即在一組伺服器之間分配工作負載。

何時使用：

當您需要進行 水平擴充。水平擴充基本上是指向環境中添加更多伺服器。您還可以使用應用層反向代理，透過一個網域和連接埠同時為多個應用程式提供服務。 HAProxy, Nginx、以及 Varnish 都是允許反向代理負載平衡的軟體範例。

優點：

• 如果線路中的某台伺服器故障，其他伺服器會透過平衡工作負載來補償其功能。
• 允許您進行水平擴充，以增加或減少環境的容量。
• 它還限制了用戶端連線，從而提供了防範 DDOS 攻擊的保護。

缺點：

• 如果系統資源不足，負載平衡器可能會限制應用程式的效能。
• 需要進行適當的設定以確保良好的效能。
• 比單一伺服器或獨立伺服器設定要複雜得多。
• 您需要考慮諸如 SSL 終端以及需要黏性工作階段（sticky sessions）的應用程式等因素。
• 使用負載平衡器最令人擔憂的一點是它是單一故障點。這意味著如果負載平衡器無法運作，您的整個服務都將中斷。

4. HTTP 加速器或快取反向代理

這是一種可以用來提高向應用程式使用者傳遞內容速度的設定。它採用了各種技術來縮短這個時間。其中最重要的一種是快取來自應用程式伺服器的回應。當使用者第一次請求內容時，加速器會將內容儲存在其記憶體中。因此，當未來有任何類似的請求進來時，它會快速提供內容，而無需與應用程式伺服器進行互動。Nginx、Varnish 以及 Squid 都能夠進行 HTTP 加速.

何時使用：

顯而易見，這種設定最適合使用者非常頻繁請求的檔案和內容。它也非常適合內容豐富的動態網頁應用程式。

優點：

• 快取和壓縮顯著提高了應用程式和請求處理的速度。
• 降低 CPU 的負載也能提高網站效能。
• 您也可以將其用作反向代理負載平衡器。

缺點：

• 您必須對其進行良好的調優才能發揮其最佳效能。
• 如果快取命中率低，您可能會遇到效能不佳的情況。

5. 主從式資料庫複製

主從式資料庫複製設定通常對於讀取次數多於寫入次數的系統非常有用。例如，內容管理系統可以很好地利用這種架構。您需要一個主節點和一個或多個複製節點來進行複製。它將讀取操作分配到所有節點。更新操作僅傳送到主節點。

何時使用：

正如我們所提到的，基於複製的資料庫設定有助於提高系統的讀取效能。您可以將其用於像 CMS 這樣的應用程式。

優點：

• 它透過將讀取操作分散到各個複本中，從而提高了資料庫的讀取效能。
• 如果您僅將主節點用於更新，您還可以提高寫入效能。

缺點：

• 任何嘗試存取資料庫的應用程式都必須能夠決定將更新和讀取請求傳送到哪個節點。
• 如果主複本故障，更新將會停止。您必須解決該問題才能讓更新繼續。
• 沒有容錯移轉機制來應對潛在的主節點故障。

組合使用伺服器設定

幸運的是，您也可以結合各種技術來達到所需的結果。這意味著您可以在單一環境中對應用程式伺服器與快取伺服器進行負載平衡，並複製資料庫。這樣做可以讓您充分利用這兩種伺服器的功能。然而，這並不會讓設定變得更複雜或更麻煩。

範例：

我們將透過一個範例來試著理解這樣的環境：

在這樣的環境中，負載平衡器會將靜態請求傳送到快取伺服器。靜態內容 包括 CSS、圖片和 Javascript 等。它會將任何其他類型的內容請求導向到應用程式伺服器。

假設使用者正在向該環境請求一些靜態內容。以下是會發生的情況：

• 負載平衡器首先會判斷該內容是快取命中（cache-hit）還是快取未命中（cache-miss）。快取命中的內容存在於快取中，而快取未命中的內容則不存在。它是透過向快取後端進行檢查來做到這一點的。
• 如果是快取命中，負載平衡器會將內容傳送給使用者。
• 如果是快取未命中，快取伺服器會將請求轉發給應用程式的後端。
• 應用程式後端（app-backend）會從資料庫中尋找並傳送該內容。
• 快取後端（cache-backend）從負載平衡器接收內容。它也會在將此內容傳回給負載平衡器之前對其進行快取。
• 後者隨後將回應轉發給使用者。

另一方面，如果使用者請求動態內容，將會發生以下情況：

• 請求將從使用者端傳送到負載平衡器。
• 此請求會傳送到應用程式後端。
• 應用程式後端會定位所請求的內容並將其傳回給負載平衡器。
• 使用者接收該內容。

這種組合環境的主要好處之一是它更可靠。不僅如此，它還具有更優越的效能。然而，仍然存在兩個單一故障點：負載平衡器和主資料庫伺服器。

結論

您可以在您的環境中單獨使用每種伺服器設定。另一方面，您也可以將其中幾種結合在一起，以建立個人化的解決方案。沒有「正確」的答案。這完全取決於您希望從該架構中獲得什麼功能。

具備關於每種伺服器設定如何運作的基礎知識，將有助於您為自己的應用程式做出決定。最好的做法是從小規模且簡單的設定開始。隨著您累積經驗，您可以持續增加設定的複雜度。

祝您運算愉快！