在 Amazon AWS 上擴展至 1100 萬以上用戶的入門指南 · HighScalability 中文示例

# 在 Amazon AWS 上擴展至 1100 萬以上用戶的入門指南 > 原文： [http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html](http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html) ![](https://img.kancloud.cn/95/37/95374ce621fa85f69d9a7a79df6398f0_225x114.png) 您如何將系統從一個用戶擴展到超過 1100 萬用戶？ [Joel Williams](https://www.linkedin.com/in/joel-williams-70257b7) ，亞馬遜網絡服務解決方案架構師，就該主題發表了精彩的演講： [AWS re：Invent 2015 擴展到您的前 1000 萬用戶](https://www.youtube.com/watch?v=vg5onp8TU6Q&list=PLhr1KZpdzukdRxs_pGJm-qSy5LayL6W_Y)。如果您是 AWS 的高級用戶，那么本演講不適合您，但是如果您是 AWS 的新手，云的新手或的入門者，那么這是上手的好方法不斷涌現的新功能 Amazon 不斷涌現。正如您可能期望的那樣，由于這是 Amazon 的一次講話，因此 Amazon 服務始終是解決任何問題的中心。他們的平臺表現令人印象深刻且具有啟發性。通過將各個部分組合在一起，很明顯，亞馬遜在確定用戶需求并確保他們擁有該領域的產品方面做得非常出色。一些有趣的外賣： * 從 SQL 開始，僅在必要時移至 NoSQL。 * 一致的主題是將組件分離出來。這使這些組件可以獨立擴展和失敗。它適用于拆分層并創建微服務。 * 僅投資于使您的企業與眾不同的任務，不要重蹈覆轍。 * 可伸縮性和冗余不是兩個獨立的概念，您通常可以同時進行。 * 沒有提及費用。這將是演講的一個很好的補充，因為這是對 AWS 解決方案的主要批評之一。 ## 基礎知識 * AWS 在全球 12 個地區中。 * 區域是世界上亞馬遜具有多個可用區的物理位置。中有 [地區：北美；南美洲; 歐洲; 中東; 非洲; 亞太地區。](https://aws.amazon.com/about-aws/global-infrastructure/) * 可用區（AZ）通常是單個數據中心，盡管它們可以由多個數據中心構成。 * 每個可用區都足夠獨立，因此它們具有獨立的電源和 Internet 連接。 * 可用區之間的唯一連接是低延遲網絡。例如，可用區可以相隔 5 或 15 英里。網絡足夠快，您的應用程序就可以像所有可用區都在同一個數據中心中一樣工作。 * 每個區域至少有兩個可用區。共有 32 個可用區。 * 使用可用區可以為您的應用程序創建高可用性架構。 * 2016 年將至少有 9 個可用區和 4 個地區。 * AWS 在全球擁有 53 個邊緣位置。 * 邊緣位置由 Amazon 的內容分發網絡（CDN）CloudFront 和 Amazon 的托管 DNS 服務器 Route53 使用。 * 邊緣位置使用戶無論身在何處都可以以極低的延遲訪問內容。 * 構建基塊服務 * AWS 創建了許多服務，這些服務在內部使用多個可用區來實現高可用性和容錯能力。 [是其中](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) [提供哪些服務的列表](http://docs.aws.amazon.com/general/latest/gr/rande.html) ，其中可用。 * 您可以付費在應用程序中使用這些服務，而不必擔心使它們自己高度可用。 * 可用區內存在的一些服務：CloudFront，Route 53，S3，DynamoDB，彈性負載平衡，EFS，Lambda，SQS，SNS，SES，SWF。 * 即使服務位于單個 AZ 中，也可以使用服務創建高可用的體系結構。 ## 1 個用戶 * 在這種情況下，您是唯一的用戶，并且您要運行一個網站。 * 您的架構將類似于： * 在單個實例上運行，可能是 [t2.micro](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html) 類型。實例類型包括 CPU，內存，存儲和網絡容量的各種組合，使您可以靈活地為應用程序選擇適當的資源組合。 * 一個實例將運行整個 [Web 堆棧]( http://whatis.techtarget.com/definition/Web-stack) ，例如：Web 應用程序，數據庫，管理等。 * 將 Amazon [路由 53](https://aws.amazon.com/route53/) 用作 DNS。 * 將單個 [彈性 IP](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) 地址附加到實例。 * 運作良好，持續了一段時間。 ## 垂直縮放 * 您需要一個更大的盒子。最簡單的擴展方法是選擇更大的實例類型。例如，也許 [c4.8xlarge](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/c4-instances.html) 或 [m3.2xlarge](https://aws.amazon.com/ec2/instance-types/) 。 * 這種方法稱為 [垂直縮放](https://en.wikipedia.org/wiki/Scalability) 。 * 只需停止實例并選擇一種新的實例類型，您就可以以更高的功率運行。 * 有多種不同的硬件配置可供選擇。您可以擁有一個帶有 244 GB RAM 的系統（即將推出 2TB RAM 類型）。或一個 40 核。有高 I / O 實例，高 CPU 實例，高存儲實例。 * 某些 Amazon 服務隨附 [預置 IOPS](http://serverfault.com/questions/580568/amazon-how-do-i-know-if-i-need-provisioned-iops) 選項，以確保性能。這個想法是，您也許可以為服務使用較小的實例類型，并利用 DynamoDB 之類的 Amazon 服務來提供可擴展的服務，因此您不必這樣做。 * 垂直擴展存在一個大問題：沒有故障轉移，也沒有冗余。如果實例出現問題，則您的網站將死亡。你所有的雞蛋都放在一個籃子里。 * 最終，單個實例只能變得如此之大。您需要做其他事情。 ## 用戶> 10 * 將單個主機分離為多個主機 * 該網站的主機。 * 數據庫的一臺主機。運行所需的任何數據庫，但是您需要進行數據庫管理。 * 使用單獨的主機可以使網站和數據庫彼此獨立地擴展。例如，也許您的數據庫將需要比網站更大的計算機。 * 或者，也可以使用數據庫服務代替運行自己的數據庫。 * 您是數據庫管理員嗎？您真的要擔心備份嗎？高可用性？補丁？操作系統？ * 使用服務的一大優勢在于，您只需單擊即可設置多個可用區數據庫。您無需擔心復制或任何此類事情。您的數據庫將高度可用且可靠。 * 您可能會想像到亞馬遜有幾項完全托??管的數據庫服務可以賣給您： * [Amazon RDS](https://aws.amazon.com/rds/) （關系數據庫服務）。有很多選項：Microsoft SQL Server，Oracle，MySQL，PostgreSQL，MariaDB，Amazon Aurora。 * [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 。 NoSQL 管理的數據庫。 * [Amazon Redshift](https://aws.amazon.com/redshift/) 。 PB 級數據倉庫系統。 * 更多 [Amazon Aurora](https://aws.amazon.com/rds/aurora/) ： * 自動存儲擴展到 64TB。您不再需要為數據配置存儲。 * 最多 15 個讀只讀副本 * 連續（增量）備份到 S3。 * 跨 3 個 AZ 進行 6 向復制。這可以幫助您處理故障。 * MySQL 兼容。 * 從 SQL 數據庫而不是 NoSQL 數據庫開始。 * 建議從 SQL 數據庫開始。 * 該技術已建立。 * 有很多現有的代碼，社區，支持小組，書籍和工具。 * 您不會破壞前 1000 萬用戶的 SQL 數據庫。差遠了。（除非您的數據很大）。 * 清晰的模式可擴展。 * 您何時需要從 NoSQL 數據庫開始？ * 如果您需要在第一年存儲 5 TB 的>數據，或者您的數據處理工作量非常大。 * 您的應用程序具有超低延遲要求。 * 您需要非常高的吞吐量。您需要真正調整在讀取和寫入中都得到的 IO。 * 您沒有任何關系數據。 ## 用戶> 100 * 將單獨的主機用于 Web 層。 * 將數據庫存儲在 Amazon RDS 上。它照顧一切。 * 這就是您要做的。 ## 用戶> 1000 * 按照架構，您的應用程序存在可用性問題。如果您的 Web 服務主機出現故障，則您的網站將關閉。 * 因此，您在另一個可用區中需要另一個 Web 實例。可以，因為 AZ 之間的等待時間只有幾位毫秒，幾乎就像它們彼此相鄰一樣。 * 您還需要一個從屬數據庫到在另一個 AZ 中運行的 RDS 。如果主服務器有問題，您的應用程序將自動切換到從屬服務器。故障轉移無需對應用程序進行任何更改，因為您的應用程序始終使用相同的端點。 * 彈性負載均衡器（ELB）已添加到配置中，以在兩個可用區中的兩個 Web 主機實例之間負載均衡用戶。 * 彈性負載平衡器（ELB）： * ELB 是高度可用的托管負載均衡器。 ELB 存在于所有可用區中。它是您的應用程序的單個 DNS 終結點。只需將其放在 Route 53 中，它將在您的 Web 主機實例之間實現負載平衡。 * ELB 具有運行狀況檢查，以確保流量不會流向發生故障的主機。 * 無需任何操作即可縮放。如果看到額外的流量，它將在水平和垂直方向上擴展到幕后。您不必管理它。隨著應用程序規模的擴展，ELB 也隨之擴展。 ## 用戶> 10,000s-100,000s * 先前的配置在 ELB 后面有 2 個實例，實際上，您可以在 ELB 后面有 1000 個實例。這是 [水平縮放](https://en.wikipedia.org/wiki/Scalability) 。 * 您需要向數據庫和 RDS 添加更多只讀副本。這將減輕寫主機的負擔。 * 通過將通過將一些流量轉移到其他地方來減輕 Web 層服務器的負載，從而考慮性能和效率。將 Web 應用程序中的靜態內容移動到 Amazon S3 和 Amazon CloudFront。 CloudFront 是 Amazon 的 CDN，可將您的數據存儲在全球 53 個邊緣位置。 * Amazon S3 是對象庫。 * 它與 EBS 不同，它不是連接到 EC2 實例的存儲，而是對象存儲，而不是塊存儲。 * 這是存儲靜態內容（如 javascript，css，圖像，視頻）的好地方。此類內容無需位于 EC2 實例上。 * 高度耐用，可靠性 11 9。 * 無限擴展，可根據需要拋出盡可能多的數據。客戶在 S3 中存儲多個 PB 的數據。 * 支持最大 5TB 的對象。 * 支持加密。您可以使用 Amazon 的加密，您的加密或加密服務。 * Amazon CloudFront 緩存了您的內容。 * 它在邊緣位置緩存內容，以為用戶提供盡可能低的延遲訪問。 * 如果沒有 CDN，您的用戶將遇到對您的內容的更高延遲訪問。您的服務器在提供內容以及處理 Web 請求時也將承受更高的負載。 * 一位客戶需要以 60 Gbps 的速度提供內容。網絡層甚至都不知道這是怎么回事，CloudFront 處理了所有事情。 * 您還可以通過將會話狀態移出 Web 層來減輕負載。 * 將會話狀態存儲在 [ElastiCache](https://aws.amazon.com/elasticache/) 或 DynamoDB 中。 * 這種方法還可以設置系統以支持將來的自動縮放。 * 您還可以通過將數據從數據庫緩存到 ElastiCache 中來減輕負載。 * 您的數據庫不需要處理所有數據獲取。緩存可以處理很多工作，而數據庫則可以處理更重要的流量。 * Amazon DynamoDB-托管的 NoSQL 數據庫 * 您可以配置所需的吞吐量。您可以提高要支付的讀寫性能。 * 支持快速，可預測的性能。 * 完全分布式且具有容錯能力。它存在于多個可用區中。 * 這是一個鍵值存儲。支持 JSON。 * 支持最大 400KB 的文檔。 * Amazon Elasticache-托管的 Memcached 或 Redis * 管理內存緩存集群并不能為您帶來更多收益，因此讓 Amazon 為您做到這一點。那就是球場。 * 將自動為您縮放群集。這是一種自我修復的基礎架構，如果節點發生故障，則會自動啟動新節點。 * 您還可以通過將動態內容轉移到 CloudFront 來減輕負載。 * 許多人都知道 CloudFront 可以處理靜態內容（例如文件），但也可以處理一些動態內容。談話中沒有進一步討論該主題，但這里的 [鏈接](https://aws.amazon.com/cloudfront/dynamic-content/) 。 ## [自動縮放](https://aws.amazon.com/autoscaling/) * 如果您提供足夠的容量來始終處理高峰流量，例如黑色星期五，那是在浪費錢。將計算能力與需求匹配起來會更好。這就是 Auto Scaling 的工作，即自動調整計算群集的大小。 * 您可以定義池的最小和最大大小。作為用戶，您可以確定集群中最少的實例數和最多的實例數。 * [CloudWatch](https://aws.amazon.com/cloudwatch/) 是一項管理服務，已嵌入到所有應用程序中。 * CloudWatch 事件驅動擴展。 * 您要擴展 CPU 使用率嗎？您要擴展延遲嗎？在網絡流量上？ * 您也可以將自己的自定義指標推送到 CloudWatch。如果要按特定的應用程序擴展，可以將該指標推送到 CloudWatch，然后告訴 Auto Scaling 您要按該指標擴展。 ## 用戶> 500,000+ * 從先前配置中添加的是 [自動縮放組](http://docs.aws.amazon.com/gettingstarted/latest/wah/getting-started-create-as.html) 已添加到 Web 層。自動縮放組包括兩個 AZ，但可以擴展到 3 個 AZ，最多可以位于同一區域。實例可以在多個可用區中彈出，不僅是為了實現可伸縮性，還在于可用性。 * 該示例在每個可用區中都有 3 個 Web 層實例，但可能是數千個實例。您可以說您要最少 10 個實例，最多 1000 個實例。 * ElastiCache 用于卸載數據庫中的流行讀取。 * DynamoDB 用于卸載會話數據。 * 您需要添加監視，指標和日志記錄。 * 主機級別指標。查看自動擴展組中的單個 CPU 實例，找出問題所在。 * 聚合級別指標。查看 Elastic Load Balancer 上的指標，以了解整個實例集的性能。 * 日志分析。查看應用程序使用 [CloudWatch](https://aws.amazon.com/about-aws/whats-new/2014/07/10/introducing-amazon-cloudwatch-logs/) 日志告訴您什么。 [CloudTrail](https://aws.amazon.com/cloudtrail/) 可幫助您分析和管理日志。 * 外部站點性能。了解您的客戶看到的最終用戶。使用新遺物或 Pingdom 之類的服務。 * 您需要知道客戶在說什么。他們的延遲不好嗎？他們轉到您的網頁時會收到錯誤消息嗎？ * 盡可能從配置中壓縮性能。 Auto Scaling 可以提供幫助。您不希望 CPU 使用率達到 20％的系統。 ## 自動化 * 基礎架構越來越大，可以擴展到數千個實例。我們已經閱讀過副本，可以水平縮放，但是我們需要一些自動化來幫助管理所有內容，我們不想管理每個實例。 * 自動化工具具有層次結構。 * 自己做：Amazon EC2，AWS CloudFormation。 * 更高級別的服務：AWS Elastic Beanstalk，AWS OpsWorks * [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) ：自動管理應用程序的基礎架構。這很方便，但沒有太多控制權。 * [AWS OpsWorks](https://aws.amazon.com/opsworks/) ：一個在其中分層構建應用程序的環境，您可以使用 Chef 食譜來管理應用程序的層。 * 還使您能夠進行持續集成和部署。 * [AWS CloudFormation](https://aws.amazon.com/cloudformation/) ：使用時間最長。 * 提供了最大的靈活性，因為它提供了堆棧的模板化視圖。它可以用于構建整個堆棧或僅堆棧的組件。 * 如果要更新堆棧，請更新 Cloud Formation 模板，它將僅更新應用程序的這一部分。 * 有很多控制權，但不太方便。 * [AWS CodeDeploy](https://aws.amazon.com/codedeploy/) ：將代碼部署到一組 EC2 實例。 * 可以部署到一個或數千個實例。 * 代碼部署可以指向自動擴展配置，因此代碼可以部署到一組實例。 * 也可以與 Chef 和 Puppet 結合使用。 ## 解耦基礎架構 * 使用 [SOA](https://en.wikipedia.org/wiki/Service-oriented_architecture) / [微服務](http://techblog.netflix.com/2015/02/a-microscope-on-microservices.html) 。從您的層中取出組件并將它們分開。創建單獨的服務，就像將 Web 層與數據庫層分開一樣。 * 然后可以獨立擴展各個服務。這為擴展和高可用性提供了很大的靈活性。 * SOA 是 Amazon 構建的架構的關鍵組成部分。 * 松耦合使您自由。 * 您可以分別縮放組件和使組件失敗。 * 如果工作程序節點無法從 SQS 提取工作，這有關系嗎？不，只是開始另一個。事情將會失敗，讓我們建立一個處理失敗的架構。 * 將所有內容設計為黑匣子。 * 解耦交互。 * 支持具有內置冗余和可伸縮性的服務，而不是自己構建。 ## 不要重新發明輪子 * 僅投資于使您的業務與眾不同的任務。 * 亞馬遜擁有許多固有的容錯服務，因為它們跨越多個可用區。例如：排隊，電子郵件，代碼轉換，搜索，數據庫，監視，指標，日志記錄，計算。您不必自己構建這些。 * [SQS](https://aws.amazon.com/sqs/) ：排隊服務。 * 提供的第一個 Amazon 服務。 * 它跨越多個可用區，因此具有容錯能力。 * 它具有可擴展性，安全性和簡單性。 * 排隊可以通過幫助您在基礎結構的不同組件之間傳遞消息來幫助您的基礎結構。 * 以 Photo CMS 為例。收集照片并對其進行處理的系統應該是兩個不同的系統。他們應該能夠獨立擴展。它們應該松耦合。攝取照片并將其放入隊列中，工作人員可以將照片從隊列中拉出并對其進行處理。 * [AWS Lambda](https://aws.amazon.com/lambda/) ：您可以在不配置或管理服務器的情況下運行代碼。 * 出色的工具，可讓您解耦應用程序。 * 在 Photo CMS 示例中，Lambda 可以響應 S3 事件，因此，當添加 S3 文件時，將自動觸發要處理的 Lambda 函數。 * 我們已經取消了 EC2。它可以為您進行擴展，并且無需管理任何操作系統。 ## 用戶> 1,000,000+ * 要達到一百萬個以上的用戶，則需要滿足以上所有條件： * 多可用區 * 層之間的彈性負載平衡。不僅在 Web 層上，而且在應用程序層，數據層和您擁有的任何其他層上。 * 自動縮放 * 面向服務的體系結構 * 使用 S3 和 CloudFront 巧妙地服務內容 * 將緩存放在數據庫前面 * 將狀態移出 Web 層。 * 使用 [Amazon SES](https://aws.amazon.com/ses/) 發送電子郵件。 * 使用 CloudWatch 進行監視。 ## 用戶> 10,000,000+ * 隨著規模的擴大，我們會遇到數據層的問題。與 [寫入主機](https://en.wikipedia.org/wiki/Multi-master_replication) 爭用時，您的數據庫可能會遇到問題。。 * 您如何解決？ * 聯盟 * 分片 * 將某些功能移至其他類型的數據庫（NoSQL，圖形等） * 聯合身份驗證-基于功能分為多個 DB * 例如，創建一個論壇數據庫，一個用戶數據庫，一個產品數據庫。您以前可能將它們放在單個數據庫中，現在將它們分發出去。 * 不同的數據庫可以彼此獨立地擴展。 * 缺點：您無法進行跨數據庫查詢；這會延遲進入下一個分片策略。 * 分片-在多個主機之間拆分一個數據集 * 在應用層更加復雜，但是對可伸縮性沒有實際限制。 * 例如，在用戶數據庫中，用戶的?可能會發送到一個分片，最后三分之一發送到另一個分片，另一個分片發送到另外三分之一。 * 將某些功能移至其他類型的數據庫 * 開始考慮 NoSQL 數據庫。 * 如果您的數據不需要排行榜，例如排行榜，快速獲取點擊流/日志數據，臨時數據，熱點表，元數據/查找表，則可以考慮將其移至 NoSQL 數據庫。 * 這意味著它們可以彼此獨立縮放。 ## 用戶> 1100 萬 * 縮放是一個迭代過程。隨著您變得更大，總會有更多您可以做。 * 微調您的應用程序。 * 更多 SOA 的功能/特性。 * 從多可用區轉到多區域。 * 開始構建自定義解決方案，以解決您以前從未有人做過的特定問題。如果您需要為十億客戶提供服務，則可能需要定制解決方案。 * 深入分析整個堆棧。 ## 審核中 * 使用多可用區基礎結構來提高可靠性。 * 利用自擴展服務，例如 ELB，S3，SQS，SNS，DynamoDB 等。 * 在每個級別構建冗余。可伸縮性和冗余不是兩個獨立的概念，您通常可以同時進行。 * 從傳統的關系 SQL 數據庫開始。 * 在基礎結構內部和外部緩存數據。 * 在基礎架構中使用自動化工具。 * 確保您具有良好的指標/監視/日志記錄。確保您正在查找客戶對應用程序的體驗。 * 將層劃分為單獨的服務（SOA），以便它們可以彼此獨立地擴展和失敗。 * 準備使用自動縮放功能。 * 除非絕對必要，否則不要重新發明輪子，而是使用托管服務而不是自己編寫代碼。 * 如果可行，請轉移到 NoSQL。 ## 延伸閱讀 * [在 HackerNews](https://news.ycombinator.com/item?id=10885727) 上/ [在 Reddit](https://www.reddit.com/r/sysadmin/comments/40hon7/a_beginners_guide_to_scaling_to_11_million_users/) 上 * [http://aws.amazon.com/documentation](http://aws.amazon.com/documentation/) * [http://aws.amazon.com/architecture](http://aws.amazon.com/architecture/) * [http://aws.amazon.com/start-ups](http://aws.amazon.com/start-ups) * [http://aws.amazon.com/free](http://aws.amazon.com/free) * 從 2007 年開始： [Amazon Architecture](http://highscalability.com/blog/2007/9/18/amazon-architecture.html) 不錯的文章。請更正用于啟動的鏈接。（對 http：//aws.amazon.comstart-ups 的開放應該是 http://aws.amazon.com/start-ups/）即使對于可伸縮性專業人員來說，這也是一篇出色的，易于上手的文章。做得好此設置每月將耗費瘋狂的$。 AWS 是一種將 VC 美元間接注入亞馬遜銀行賬戶的好方法。如果人們實際上對 TCO / ROI 持認真態度，那么人們就必須停止對價格過高的 VM 的炒作，而回到裸機解決方案。這是非常依賴于應用程序的，但是對于每個級別的用戶，可以期望每秒鐘的事務/請求范圍是多少？ @帕特里克是的，但是沒有。正是在這個主題上，我們進行了荒謬的成本分析。實際上，在我們系統運營的每個領域中，AWS 都能為我們節省大量資金。某些 AWS 服務的成本僅為內部成本的 1/3。每當您看到整個世界都朝著某種趨勢發展時，尤其是當該“世界”主要由聰明人和百萬富翁（他們真的很喜歡保留/賺錢）組成時，您應該假設其可能不僅僅是“炒作”或 “時尚”。五年前的數字有所不同，但是自那時以來，AWS 已將價格降低了一半或更多。除非您的計算器壞了，否則我將很難得出任何其他結論。我的經驗主要是在 AWS ..上，但是 Google 的云的價格相當，并且我認為其他 IaS 和 PaS 提供商的價格差異可以忽略不計。所以，我的建議是：仔細看..然后跳上馬車或開始計劃退休 AWS CloudFormation 的問題一直是大型 JSON 腳本的笨拙-沒有一致的添加注釋的方式，笨拙的模塊化故事以及沒有向后引用。通過使用 yaml 編寫模板，然后使用 [YAML Stratus](https://github.com/kikinteractive/yaml-stratus) 轉換為所需的 JSON，我們一直在解決此問題。 Yaml 支持注釋，向后引用，并且 yaml stratus 添加 yaml 擴展以包括其他具有覆蓋的 yaml 腳本以及編譯時參數化。 @盧克·查弗斯是的，但是你錯了。 AWS 總是比裸機中的裸機貴，大約是 10 到 100 倍。部署這樣的復雜設置（更糟糕的是，大多數應用程序永遠都不需要）時，情況更糟。 Modern 的速度非常快，基本的中型服務器每天可以支持數百萬個請求，而將高可用性加倍則很便宜。即使在云中，除非您確實需要，最好還是堅持使用基本 VM 而不是所有托管服務。從您的評論來看，好像是您的計算器壞了，或者您只是在為 AWS 工作。我有點不同意 RDS 觀點。如果您甚至具有基本的 db-administraton 技能，請不要使用 RDS。AmazonsRDS 對數據庫使用 EBS 驅動器的速度非常非常慢。一種更好的方法是將實例存儲 SSD 驅動器用于您不需要的臨時存儲物需要持久化（tempdb，事務日志（如果您知道自己在做什么以及如何在沒有日志的情況下還原數據庫）等）。除了我的這個小小的評論-很棒的帖子，謝謝你好我已經將 RDS 用于我的應用程序之一，該應用程序處理數百萬個實時社交媒體數據。通過所有優化，我們可以在中等亞馬遜實例中使用 mysql mysql 來處理 1 或 2 周的數據。隨著數據量的增長，RDS 是我們關系數據庫設計的幫助。事實是，與普通解決方案相比，這是非常昂貴的，但是當您必須處理潛在的大量數據時，則值得花費。哈哈@ colo。當然，如果您喜歡停機和昂貴的帶寬費用，請選擇合適的顏色！嘿@Alex：這個[1]說 Amazon RDS 是否支持 SSD？ [1] http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html 真正使我擔心的是在 AWS 上進行擴展，這就是為什么喜歡 Cloudways 的原因，因為他們可以按比例縮放服務器規模。非常不錯的文章，但我會緩和一個事實，那就是我們應該從 SQL DB 開始，然后將可能的方式切換到 No-SQL。從 SQL 轉換為 No-SQL 可能會非常痛苦（模型轉換，業務代碼重寫，數據遷移等），而且風險很大，您永遠也不會做。因此，我建議您采取以下措施：如果您懷疑您的應用程序將支持超過 10 萬個用戶（并且您的業務肯定是與 No-SQL 兼容的），請直接使用 No-SQL 數據庫。您將能夠輕松進行分片，使用 No-SQL 進行開發并不昂貴，并且您的應用程序可以自然擴展，而無需重新定義體系結構。讓·馬克關于裸機顏色的問題是，您需要考慮所有“成本”。大多數決定采用裸機的人都嚴重低估了所需的時間和精力，其中最少的是硬件（但是，假設您使用的是專業質量的服務器硬件，而不是垃圾郵件，那么硬件仍然比您想象的要昂貴得多）。您當地的回收場）。特別是，您將需要一個實施團隊來進行初始部署，然后*至少*由一名工作人員負責，只負責服務器的維護和維護以及最重要的虛擬化基礎架構，每年的費用為 15 萬美元以上僅針對一個人-假設您可以和一個人一起停下來。然后是數據中心不同區域的機架之間的光纖互連成本（數據中心通常具有電源和網絡區域-機架位于不同的 UPS 和路由器上，但??是如果您想在兩個前哨站之間實現 10 GB 的快速互連，您必須為此支付$$）。當然，硬件本身的成本-用于互連數據庫服務器和計算服務器的 10 吉比特交換機，所需的 10 吉比特卡，以及專業質量好的服務器和企業級 SSD 的價格并不便宜。我已經為自己的業務工作了一個交叉點，這種交叉點在內部而不是通過亞馬遜來進行比較便宜，盡管該交叉點的用戶數遠遠少于 1000 萬，但肯定比我們現在花費的更多在 AWS 服務上。關于 NoSQL，最好將其用于大量非結構化數據，例如日志數據（例如 ElasticSearch），但是現代 SQL 數據庫的 ACID 保證在許多方面都非常重要。與將 SQL 數據庫簡單地優化和擴展到所需的位置相比，嘗試將它們橫向入侵 NoSQL 數據庫通常會花費更多的時間。 Twitter 使用 MySQL 處理 1.5 億活躍用戶。已為您的時間表授予 Redis 緩存和一些自定義復制代碼，但仍然：MySQL。這是一個很棒的帖子！我認為在某些時候提高網站效率可能比服務器規模更有效。例如，有人說通過使用微緩存和 nginx，他們每天可以在微型 VPS 服務器上處理數百萬的網頁瀏覽。但是話又說回來，我從來沒有承受過太大的服務器負載，所以我知道什么。非常有用的信息，請不斷更新我們，..... 謝謝。我是這個領域的初學者。由于 AWS 昂貴，因此我使用 Linode VPS 進行托管。這將非常有助于我在上下文中使用。但是，如果您有關于該/其他廉價服務的經驗，請與我們分享，因為 Linode 沒有 AWS 提供的一些自動化服務。人們沒有解決一些問題，亞馬遜可能會更昂貴，但是每當懷疑/涉及欺詐時，他們的確會聽取買賣雙方的意見，而 ebay 不會這樣做。超級清晰，寫得很好。謝謝