# Peecho Architecture-鞋帶上的可擴展性 > 原文： [http://highscalability.com/blog/2011/8/1/peecho-architecture-scalability-on-a-shoestring.html](http://highscalability.com/blog/2011/8/1/peecho-architecture-scalability-on-a-shoestring.html) *這是 [Marcel Panse](http://www.linkedin.com/in/marcelpanse "Marcel Panse") 和 [Sander Nagtegaal](http://www.linkedin.com/in/centrical "Sander Nagtegaal") 來自 [Peecho](http://www.peecho.com) 的來賓帖子。* 盡管對體系結構的描述很有趣，但是幾乎沒有解決過初創企業面臨的問題。 我們想改變它，所以這是我們的建筑故事。 ## 初創公司介紹  阿姆斯特丹的[公司 Peecho](http://www.peecho.com) 提供打印即服務。 我們可嵌入的*打印按鈕*使您可以直接在自己的網站上以專業打印產品的形式出售數字內容，例如相簿，雜志或畫布。 也有一個 API。 Printcloud 是為打印按鈕供電的系統。 它僅存在于云中，在需要時會增長，并在可能時變得更小。 該系統可以接收打印訂單，神奇地將棘手的數據轉換為可打印的文件，并將訂單發送到最接近預期收件人的生產設施。 為了保護環境，Peecho 的理念是促進全球訂購，但僅針對本地生產。 ## 昂貴的東西無法擴展 我們是一家初創企業，因此在開始之前我們考慮過的最重要的事情就是*資金*-或缺少資金。 盡管我們需要一些強大的火力，但完整的操作系統每月花費不超過幾百美元。 資金問題一直貫穿到我們的技術堆棧中。 我們可以在此處插入一些有關面向對象，代碼編譯或 MVC 架構的好東西-但最后，我們只需要一個無需花錢的廣泛的開發工具包。 因此，我們開發人員社區的計算機科學背景使我們注意到了 Java 平臺。 使用云計算是無用的，因為按需擴展可以消除昂貴的產能過剩。 我們的候選清單包含 [Google App Engine](http://code.google.com/appengine/ "GAE") 和 [Amazon Web Services](http://aws.amazon.com "AWS") 。 這些大分子擁有比我們更多的資源和可擴展性經驗。 這就是為什么我們發誓要盡可能多地使用他們的云服務，而不是自己構建東西。 但是，我們需要排隊和關系數據存儲-退出 Google。 因此，我們選擇使用 SimpleDB，S3，SQS，EC2，RDS，IAM，Route 53 和 Cloudfront 在 Amazon Web Services 之上構建。 它便宜且通常可靠。 可以肯定的是，我們的整個系統在兩個 AWS 可用區中同時運行，以確保最大的正常運行時間。 如果我們下去，一半的世界將與我們同在。 ## 如果你慢一點，你就無法成長 但是，技術不是萬能的。 小公司的可擴展性很大程度上是通過靈活性獲得的。 快點 我們嘗試使代碼保持簡單，因此重構很容易。 結果，我們只能負擔所需的最低限度的費用，而無需考慮過多的未來需求。 我們可以稍后解決。 如果您真的想快一點，那么短迭代很重要。 平均而言，我們大約每周一次將新軟件發布到生產環境中。 為了跟上這一步，我們每月組織一次晚餐。 屆時將展示演示，每個人都為新內容歡呼和鼓掌。 有許多負擔得起的幫助可幫助您快速入門。 例如，我們根據 [Scrum](http://en.wikipedia.org/wiki/Scrum_(development) "Scrum") 和[測試驅動開發](http://en.wikipedia.org/wiki/Test-driven_development "TDD")進行開發。 我們使用 [Jira](http://www.atlassian.com/software/jira/ "Jira") 和 [Greenhopper](http://www.atlassian.com/software/greenhopper/ "Greenhopper") 進行需求管理，使用 [Bamboo](http://www.atlassian.com/software/bamboo/ "Bamboo") 進行持續集成， [Sonar](http://www.sonarsource.org/ "Sonar") 進行代碼質量監控，并使用 [Mercurial](http://mercurial.selenic.com/ "Mercurial") ]進行分布式版本控制。 順便說一下，Atlassian 產品的數量眾多，部分是由其*廉價的啟動許可證*來解釋的-但無論如何它都是好東西。 ## 當然可以，但是架構是什么樣的？ 打印按鈕及其簽出作為單獨的應用程序存在于我們平臺的頂部。 關注點的分離是為了最大程度地減少交互點，從而實現高內聚和低耦合。 該應用程序在 EC2 自動擴展組上運行，頂部帶有負載均衡器。 它將訂單數據存儲在 SimpleDB 中，SimpleDB 是一個可能遭受打擊的 AWS No-SQL 數據存儲。 靜態所有內容都通過 Cloudfront CDN 運行，以避免服務器受到攻擊。  確認付款后，打印按鈕結帳會將每個訂單提交給 REST API。 我們的高級用戶可以從他們的應用訪問相同的 API，因此我們只需要維護一個接口即可。 它負載均衡到可以自動擴展的多個節點。 使用關系數據庫服務 RDS，訂單數據保存在兩個可用性區域中。  現在，這就是魔術發生的地方。 訂單接收機將票證寫入處理隊列。 每當有足夠的票證可用時，新的處理機就會喚醒，獲取票證并開始處理糟糕的數據。 我們使用通過競標未使用的 EC2 容量租用的大型[現貨實例](http://aws.amazon.com/ec2/spot-instances/ "spot instances")。 完成這些大炮之后，他們將結果存儲在 S3 中，然后自殺。  因此，使用隊列指標，隨著隊列中項目數的變化，我們可以上下調整處理能力的數量。 這樣可以節省資金，并為我們為意外中斷做好準備。 在您自己執行此操作之前，請記住，每個組件或模塊應僅負責特定的功能。 組件或對象不應了解其他組件或對象的內部詳細信息。 隨后，必須通過將生產票證添加到正確的打印設施隊列來將訂單路由到正確的生產設施。 通過使用我們的 Adobe AIR Printclient 桌面應用程序或直接集成，該工具可以從隊列中檢索其作業，并從 S3 文件存儲中檢索產品文件。 由于不涉及服務器，因此該系統實際上是防彈的。  作為回報，該設施可以通過將消息發布到中央訂單狀態隊列中來更新 Printcloud 中的作業狀態。 異步地，我們讀取該隊列以更新客戶的訂單。 如果一切順利，產品將很快發貨。 一段時間后，產品文件將從 S3 中刪除，以節省存儲成本-所有人從此過上幸福的生活。 ## 做數學 讓我們快速了解我們的每月 AWS 賬單。 您應該了解幾件事。 * 亞馬遜為 SimpleDB 和其他服務提供免費套餐。 * 我們使用歐洲地區集群，該集群比美國集群貴。 * EC2 實例被保留[一年](http://aws.amazon.com/ec2/reserved-instances/ "reserved EC2 instances")，因此更便宜。 * 競價型實例通常是討價還價的，我們假設連續的工作負載為 50％。 * 就像并發 EC2 節點的數量一樣，所需的帶寬在很大程度上取決于傳入的訂單數量。 | 任務 | 服務 | 成本估算 | | --- | --- | --- | | 打印按鈕 | 多可用區 EC2 小實例 | $ 96 | | 訂單量 | Multi-AZ EC2 small instances | $ 96 | | 處理中 | EC2 大現貨實例 | $ 84 | | 數據庫 | 多可用區 RDS | $ 160 | | 其余的部分 | Cloudfront，S3，SimpleDB，SQS 等 | $ 50 | 一個完全彈性的重型系統每月的總收入為 *486 美元*，該系統具有至少 5 臺服務器，2 臺數據庫服務器，No-SQL 數據存儲和外部平面文件存儲的功能。 我們認為還不錯。 ## 我們希望您有便宜的應用 Peecho 證明可以在小范圍內創建可擴展的體系結構。 我們希望這些信息對您有用，也將幫助您創建出色的應用程序。 當然，最好帶有打印按鈕。 感謝您分享信息。 很好地利用 AWS 平臺。 一個問題-您如何解決在共享熨斗上獲取信用卡號所涉及的 PCI 問題？ 還是該平臺當前足夠小以至于這還不是認證問題？ 注意：從服務提供商的角度，而不是從最終商家的角度，我對 PCI 更為熟悉，因此這很可能根本不適用于您的情況，這也很有趣：) 非常酷的寫作。 謝謝。 您是否使用任何其他工具進行管理/縮放（例如，正確縮放或縮放或類似操作），或者一切都在亞馬遜上運行了準系統？ @Richard：對于這種設置，我猜他們使用的是支付服務提供商，負責支付的整個過程。 例如。 您將一個 transactionid 推給支付提供商，一旦客戶確認交易，支付提供商就會觸發回調并將該交易標記為成功（例如 Paypal 交易：） @Todd：您已經為 Auto-Scaling 組預先配置了現成的 AMI，還是使用諸如 Chef / Puppet / CFengine 之類的配置管理？ 理查德，我不認識他們，但我從事電子商務，所以我可以回應。 如果您足夠小，則可以使用隱藏的聚會進行貨幣交易，例如 Paypal，銀行或類似的提供者。 在這種情況下，信用卡號僅由該公司查看和保存，并且您僅收到服務器對服務器的消息，通知付款結果。 他們在文章中說“確認付款后”，所以我想是這樣。 我從未嘗試過該網站。 我猜他們沒有存儲任何卡信息，它們可能只是重定向到支付網關 URL，就像貝寶那樣。 這不是 BOA，而是 Peecho（如果他們只知道捷克語的意思，請使用不同的拼寫） 來自：http://www.pcicomplianceguide.org 問：PCI 適用于誰？ 答：PCI 適用于接受，傳輸或存儲任何持卡人數據的所有組織或商家，無論交易規模或交易數量如何。 換句話說，如果該組織的任何客戶曾經使用信用卡或借記卡直接向商家付款，則適用 PCI DSS 要求。 您是否發現小型實例的網絡帶寬足以滿足 Web 需求？ “傳輸”是大問題。 但是我剛剛找到了一個相對較新的文檔（去年年底），在該文檔中，亞馬遜的 AWS 環境獲得了 PCI 一級服務提供商使用的認證。 那真的很酷。 嗯...現在，這篇文章甚至更發人深省。 @Todd: You you got preconfigured ready-to-go AMI's for your Auto-Scaling groups or do you use some kind of configuration management like Chef/Puppet/CFengine?