<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??碼云GVP開源項目 12k star Uniapp+ElementUI 功能強大 支持多語言、二開方便! 廣告
                # Feedblendr 架構-使用 EC2 進行擴展 > 原文: [http://highscalability.com/blog/2007/10/30/feedblendr-architecture-using-ec2-to-scale.html](http://highscalability.com/blog/2007/10/30/feedblendr-architecture-using-ec2-to-scale.html) 一個男人做了一個夢。 他的夢想是將一堆 RSS / Atom / RDF 提要混合到一個提要中。 這個人是 [Feedville](http://feedville.com/) 的 Beau Lebens,并且像大多數夢想家一樣,他的硬幣有些短缺。 因此,他在廉價的托管服務提供商的家中避難,而 Beau 實現了他的夢想,創建了 [FEEDblendr](http://feedblendr.com/) 。 但是 FEEDblendr 消耗了太多 CPU 來創建混合供稿,以至于廉價的托管服務提供商命令 Beau 來尋找另一個家。 博去哪兒了? 他最終在亞馬遜 EC2 的虛擬機室內找到了一個新家。 這是關于 Beau 最終如何能夠在負擔得起的 CPU 周期的搖籃中安全地創建自己的供稿的故事。 網站:http://feedblendr.com/ ## 該平臺 * EC2(Fedora Core 6 Lite 發行版)* S3* 阿帕奇* 的 PHP* 的 MySQL* DynDNS (for round robin DNS) ## 統計資料 * Beau 是具有一些系統管理員技能的開發人員,而不是 Web 服務器管理員,因此創建 FEEDblendr 涉及很多學習。* FEEDblendr 使用 2 個 EC2 實例。 兩個實例都使用相同的 Amazon 實例(AMI)。* 已經創建了 10,000 多個混合,其中包含 45,000 多個源 feed。* 每天大約創建 30 個混合。 實際上,這兩個實例上的處理器被釘得很高(大部分時間的平均負載為 10 到 20)。 ## 架構 * 輪詢 DNS 用于在實例之間進行負載平衡。 -手動更新 DNS,因為在更新 DNS 之前驗證實例可以正常工作。 -實例現在看起來比以前更穩定,但是您仍然必須假設它們隨時都可能丟失,并且兩次重啟之間不會保留任何數據。* 由于 EC2 沒有像樣的持久性存儲系統,因此數據庫仍托管在外部服務上。* AMI 保持最小。 這是一個干凈的實例,帶有一些自動部署代碼,可從 S3 加載應用程序。 這意味著您不必為每個軟件版本創建新實例。* 部署過程為: -軟件是在筆記本電腦上開發的,并存儲在 Subversion 中。 -Makefile 用于獲取修訂,修復權限等,打包并推送到 S3。 -AMI 啟動時,它將運行腳本以從 S3 獲取軟件包。 -打開包裝包,并執行其中的特定腳本以繼續安裝過程。 -Apache,PHP 等的配置文件已更新。 -固定了服務器特定的權限,符號鏈接等。 -Apache 重新啟動,并使用該計算機的 IP 發送電子郵件。 然后使用新的 IP 地址手動更新 DNS。* 提要獨立于每個實例進行智能緩存。 這是為了盡可能減少對飼料的昂貴輪詢。 嘗試將 S3 作為兩個實例的通用提要緩存,但是速度太慢。 也許可以將提要寫入每個實例,以便將它們緩存在每臺計算機上? ## 學過的知識 * 低預算的啟動可以使用 EC2 和 S3 有效地引導。* 對于精打細算的人,免費的 ZoneEdit 服務可能與每年 50 美元的 DynDNS 服務(效果很好)一樣好。* 循環負載平衡緩慢且不可靠。 即使 DNS 的 TTL 較短,某些系統仍會長時間使用尋址的 IP,因此新計算機無法實現負載平衡。* RSS 實施存在許多問題,無法有效地合并摘要。 因為沒有可靠的交叉實現方式來判斷提要何時真正更改,所以不必要地花費大量 CPU 讀取和混合提要。* 考慮到實例可以隨時消失,這確實是一個很大的觀念轉變。 您必須更改您的架構和設計以適應這一事實。 但是,一旦將此模型內部化,就可以解決大多數問題。* EC2 較差的負載平衡和持久性功能使開發和部署變得異常困難。* 使用 AMI 的能力來傳遞參數,以選擇要從 S3 加載的配置。 這樣,您就可以測試不同的配置,而無需移動/刪除當前活動的配置。* 創建一個自動化測試系統以在實例啟動時對其進行驗證。 如果測試通過,則自動更新 DNS。 這使得創建新實例變得容易,并且使慢速人員脫離了循環。* 始終從 S3 加載軟件。 您想要發生的最后一件事是實例加載,由于某種原因無法聯系您的 SVN 服務器,因此無法正確加載。 將其放在 S3 中實際上消除了這種情況的發生,因為它在同一網絡上。 ## 相關文章 * [什么是“新聞河”風格的聚合器?](http://www.reallysimplesyndication.com/riverOfNews)* [使用亞馬遜服務以 100 美元的價格構建無限可擴展的基礎架構](http://highscalability.com/build-infinitely-scalable-infrastructure-100-using-amazon-services) 我可能會缺少一些東西,但我看不出這是“使用 EC2 進行擴展”的有趣示例。 在 Beau 使用 EC2 的方式使用 EC2 和從正常提供商設置兩個租用服務器之間似乎沒有什么區別。 實際上,獲得租用服務器可能會更好,因為成本可能更低(EC2 實例的成本為每月 72 美元/月+帶寬),并且數據庫將位于同一網絡上。 Beau 似乎沒有做任何利用 EC2 的事情,例如根據需求動態創建和丟棄實例。 我在這里想念什么嗎? 這是使用 EC2 進行擴展的有趣用法嗎? >我可能缺少一些東西,但是我看不出這是“使用 EC2 進行縮放”的有趣示例。 我承認在發現有趣的事情上有些變態,但從博人的立場(這是很多人的觀點)來看,這部戲令人激動。 故事始于沖突:如何實現這個想法? 第一種選擇是傳統的廉價主機選擇。 長期以來,故事的結局已經到了。 具有高端 CPU,RAM 和持久存儲的專用服務器仍然不便宜。 因此,如果您不賺錢,那將是故事的結局。 通過添加越來越多的專用服務器進行擴展是不可能的。 希望新的網格模型將使很多人繼續寫自己的故事。 他創建系統的學習曲線是最有趣的。 弄清楚如何進行設置,負載均衡,軟件加載,測試,常規的螺母和螺栓開發工作。 這樣一來,他就可以在需要的時候立即獲得更多的 CPU。 他已經可以進行基礎工作,因此能夠快速添加該功能。 但是現在它運行良好。 計劃中的扳手是數據庫,它指出了 EC2 的致命缺陷,即數據庫。 如果該部分工作得更好,則該計劃看起來會更成功,但事實并非如此,這也很有趣。 @Todd,感謝您的撰寫,并進行了一些快速更正/澄清: -“ Beau 是具有某些 sysadmin 技能的開發人員,而不是 Web 服務器管理員,因此在創建 FEEDblendr 時需要進行很多學習。” -需要明確的是,學習曲線主要是在處理 EC2 及其工作原理,而不是 FeedBlendr,它的核心是相對簡單的。 -“重新啟動之間不會保留任何數據”,這并非完全正確。 重新引導將保留數據,但是真正的“崩潰”或實例的終止將丟棄所有內容。 -“由于 EC2 沒有像樣的持久性存儲系統,數據庫仍托管在外部服務上”-此處的情況更多是我不想處理(或付費)設置某些東西來滿足 他們沒有持久性存儲。 它是由其他人完成的,并且可以完成,這似乎對我所做的事情來說太過分了。 -“ EC2 較差的負載平衡和持久性功能使開發和部署比原本要難得多”-很明顯,EC2 沒有**內在**固有的負載平衡,因此,這取決于您(開發人員/管理員) 自己提供某種方式。 有很多不同的方法可以使用,但是我選擇動態 DNS 是因為我很熟悉它。 @Greg 在回答您的問題時-我想這里的重點是,即使 FeedBlendr **當前不是**的擴展子代,這也很重要。 正如 Todd 所說的,這是關于學習曲線以及達到**可擴展**的程度的嘗試和磨難。 沒有什么阻止我(除了預算!)立即啟動另外 5 個實例并將它們添加到 DNS 中,然后我突然擴展了規模。 從那里,我可以終止一些實例并進行縮減。 這就是要達到我什至擁有該選項的地步,尤其是在 EC2 上是如何實現的。 干杯, 英俊 漂亮的文章和鼓舞人心的故事。 很高興讀到這個小家伙正在構建具有擴展能力的東西。 但是,如果我能提供一點反饋意見,則每臺機器上獨立緩存數據將不會隨著應用程序的開發而擴展。 那會引起問題。 如何將 EC2 實例作為專用緩存運行? 它不是持久性的,如果失敗了,那么您將不得不重建現金。 但是假設它是一種簡單的存儲機制,則應該保持一致。 我認為他們有很多慷慨的儲物津貼。 無論哪種方式,幾分鐘之內能夠打開另外 3 個實例的想法絕對是不錯的,尤其是當您遇到“斜杠” /“ dugg” /之類的東西時。 如果實例可以檢測到自己的高負載并自動啟動新實例,那就特別好。 好故事- [http://www.callum-macdonald.com/“](<a rel=) title =” Callum“ target =” _ blank“ > Callum。 > > >需要明確的是,學習曲線主要是在處理 EC2 及其工作方式,而不是 FeedBlendr,它的核心是相對簡單的。 我的帽子對你好! 很少有人會保持自己的觀點。 謝謝(你的)信息。 順便說一句,我已將其標記為@ [http://www.searchallinone.com/Other/Blogging_Locally_with_Outside-in_Founders_and_Only_the_Blog_Knows_Brooklyn__Brian_Lehrer_Live/](http://www.searchallinone.com/Other/Blogging_Locally_with_Outside-in_Founders_and_Only_the_Blog_Knows_Brooklyn__Brian_Lehrer_Live/)
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看