Amazon-Ec2
帶有 Node.js 和數據庫的 Amazon EC2 上的低延遲 RESTful 伺服器架構
對於具有大量大規模部署實踐經驗的 DBA 來說，這是一個問題。
- 我們正在嘗試建構一個延遲非常低的應用程序。（我們真的想創造最好的使用者體驗，在這種情況下延遲很重要。）
- 該應用程序基本上是一個查詢數據庫 (OrientDB) 的 RESTful Node.js 伺服器。靜態內容/文件託管在其他地方。對象主要在客戶端轉換為 UI。
- 我們計劃使用 Amazon EC2 來託管 Web 伺服器和數據庫。
- 高可用性也很重要。
- 目前，成本不是主要的決定因素。
你會推薦什麼架構？
這裡有2個選項，也許還有更多：
- 將 Web 伺服器（在本例中為 Node.js）放在與數據庫相同的 EC2 實例上。我們將有多個這樣的實例來實現可用性和負載平衡。過去，我用它來減少大容量的延遲，但這些系統不必大幅擴展。也是在安置組之前。
- 或者，在與 REST Web 伺服器不同的實例上擁有數據庫。
背景
數據庫大小約為 50 GB，我們需要更好的解決方案。預計流量將在 8 個月內達到該數量的 10 倍（500 GB 數據庫）。
它大約是 20% 的寫入和 80% 的讀取。現在每秒大約有 1000 個查詢，而且這個速度還在增加。
“將網路伺服器（在本例中為 Node.js）放在與數據庫相同的 EC2 實例上”
永遠不要把你的應用伺服器和數據庫伺服器放在一台機器上。由於您使用的是 EC2，因此亞馬遜上有一些名為“Architecting on AWS”的白皮書，其中有一個部分稱為可擴展性。你所有的應用伺服器都應該是無狀態的。這意味著它不應該是任何機器上儲存的數據，因此您可以根據您的自動擴展組輕鬆啟動虛擬機（從您的 AMI），或者在流量下降時擺脫它。
數據庫伺服器通常有自己的可擴展方式，如主從或副本集。因此，它們不應該在您的應用伺服器（自動擴展或 ELB）的同一組中。
現在是網路延遲，實際上最近我在 AWS VPC 上測試內部網路速度檢查，並沒有那麼糟糕。根據您的 EC2 類型，網路具有低中型和高級網路類型，但在內部網路方面，它的速度非常快。它將在 DNS 解析時間、HTTP 請求時間、HTTP 響應時間等範圍內。您應該更擔心 EC2 機器上的查詢時間，方法是選擇 SSD 卷（可能是配置您的 EBS 卷）並可能對您的 EBS 捲進行 RAID 以加快速度讀/寫。當涉及到架構中的數據庫時，瓶頸通常是 I/O，而不是網路延遲（除非您正在使用所有頻寬，因此您需要更多的輔助伺服器，以便您的應用伺服器可以直接從中讀取）。
有問題可以私信我，祝你好運