# BuddyPoke 如何使用 Google App Engine 在 Facebook 上擴展 > 原文： [http://highscalability.com/blog/2010/1/22/how-buddypoke-scales-on-facebook-using-google-app-engine.html](http://highscalability.com/blog/2010/1/22/how-buddypoke-scales-on-facebook-using-google-app-engine.html) 您如何擴展一個病毒式 Facebook 應用，該應用激增至令人難以置信的 6500 萬次安裝（法國人口）？ 那是 [BuddyPoke](http://www.buddypoke.com/) 的共同創始人 Dave Westwood 遇到的問題，他在周三的 [Facebook Meetup](http://www.meetup.com/facebookmeetup/calendar/12179578/) 上談到了他的解決方案。 完整演講的幻燈片在此處。 對于那些不太確定 BuddyPoke 是什么的人，它是一個社交網絡應用程序，它使用戶可以通過在線頭像來顯示自己的心情，擁抱，親吻和戳朋友。 在許多方面，BuddyPoke 是典型的現代 Web 應用程序。 它繁榮發展了社交網絡驅動的生態系統。 游戲的機制，病毒循環和創造性的獲利策略都是其日常概念化的一部分。 它將不同的技術融合在一起，而不是以黑暗的科學怪人方式，而是以一種聰明的方式獲得最大的收益。 它的一部分在 Facebook 服務器上運行（免費）。 它的一部分在瀏覽器中的 Flash 上??運行（免費）。 它的一部分在存儲云上運行（成本更高）。 并且部分運行在平臺即服務環境（GAE）上（低成本）。 它還與 PayPal 等其他服務緊密集成。 通過出售可在戳中兌換的虛擬商品，例如[金幣](http://www.humanexperience.nl/wp-content/uploads/2009/06/buddypoke.png)，可以賺取真實的$$$。 用戶還可以將他們的化身制作成玩偶，T 恤和其他由 Zazzle 提供動力的禮物。 這確實是一個了不起的企業，在現代環境下只能說出最愚蠢的感覺。 我只能想象革命時代的農民會怎樣做。 BuddyPoke 甚至可以成為十年前存在的東西嗎？ 我要問的原因是要處理所有這些用戶，BuddyPoke 需要以非常低的成本實現巨大的擴展規模。 如果您必須在數據中心中構建自己的 colo 站點，那么 BuddyPoke 是否可以經濟地運作？ 他會得到資金進行擴建嗎？ BuddyPoke 通過非常巧妙的策略和服務組合來工作。 通過戴夫的講話可以明顯看出，這些都是非常有意識的策略。 Dave 談論了很多有關在功能上轉移到不同位置以最小化成本，選擇技術以最小化成本，同時又保持足夠高的性能以使用戶可以繼續戳的技術。 ## 一般經驗教訓 在獲得 GAE 的具體建議之前，戴夫做了一些有趣的一般觀察： 1. BuddyPoke 的 GAE 成本很低。 我試圖找出實際成本是多少，因為有些人報告的成本高于預期，而我想知道他的經驗表明了什么。 沒有人會回答這些類型的問題，戴夫也不例外。 他確實說過，他為每個客戶支付的費用不到一美分，但是我不確定這些單位。 每年一分錢？ 每次手術？ 沒有意見 ：-） 2. GAE 的持久性即服務模型的吸引力在于它的簡單性。 Dave 說他是 3D 圖形人員，而不是基礎架構人員，因此他不想弄亂系統的那部分。 這是 GAE 的最佳選擇。 3. BuddyPoke 的大部分成本用于內容交付。 BuddyPoke 的主要應用是必須提供 Flash 文件。 這些成本遠遠高于運行實際應用程序的成本。 Dave 正在研究 Rackspace 的文件服務。 GAE 對于訪問內容具有較高的故障率，這在返回化身時是可以接受的，但對于加載初始圖像而言并不是很好。 4. 您不能天真地為 GAE 編碼。 為了獲得性能，您必須選擇最適合 GAE 工作方式的策略。 ## Google App Engine 課程 以下是 BuddyPoke 用于在 Facebook 和 Google App Engine 上擴展的一些策略： 1. 使用瀏覽器的 CPU。 這些 CPU 周期是免費的，而您可以在 GAE 中付費。 對于 BuddyPoke，這意味著：1）在 Flash 客戶端中執行計算 2）等待客戶端中的 Facebook 操作，而不是 GAE。 2. 設置最大值。 而不是允許用戶上傳大量圖標，例如，最多設置六個左右，否則數據存儲和您的成本將爆炸。 3. [Memcache](http://code.google.com/appengine/articles/scaling/memcache.html) 一切都是為了解決數據存儲問題。 4. 將[分片計數器](http://code.google.com/appengine/articles/sharding_counters.html)用于安裝計數之類的統計信息。 否則，爭用問題將使一切陷入困境，并激增您的配額。 5. 發送大量[電子郵件](http://code.google.com/appengine/docs/java/mail/)會占用大量 CPU。 使用任務隊列或 cron 作業對它們進行批處理。 6. 將多個 [appspot](http://code.google.com/appengine/docs/whatisgoogleappengine.html) 應用程序用于不同功能，而不是一個大型應用程序。 例如，錯誤將發送到特定的錯誤應用程序。 這樣可以使日志和其他統計信息按功能分開。 7. 將表分為兩部分：主模型和附加信息模型。 數據存儲看跌期權是您最大的成本，因此您需要盡一切可能使成本最小化。 在主模型中，僅使用鍵控訪問，不使用索引，并且不保留其他字段。 獲得將很快而認沽將變得便宜。 編寫額外的字段會浪費時間和金錢。 因此，用戶模型的“加入日期”字段不屬于主表。 它不經常使用，因此將這種數據放入附加的信息模型中。 將您的索引放在該模型上并對其執行查詢。 因為附加信息模型具有索引，所以它將導致更多的同步寫入，這將花費更多，更慢，并且如果您需要頻繁編寫此模型，則可以備份處理。 8. 為了最大程度地減少數據存儲跳，請使用批處理獲取和放置。 從表面上看，BuddyPoke 看起來很簡單，但是在引擎蓋下卻存在著一些復雜的策略。 在使其規模和性能最大化的同時將成本最小化并不明顯。 誰在做什么，何時，為什么以及如何做讓人費解。 當然，這是越來越多的應用程序將來會發現自己使用的一種方法。 ## 相關文章 1. [談話的 Ustream 視頻](http://www.ustream.tv/recorded/4118948) 2. [在 App Engine](http://code.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html) 上構建可擴展的復雜應用程序，作者 Brett Slatkin 3. [Google App Engine-再看](http://highscalability.com/blog/2009/2/21/google-appengine-a-second-look.html) 4. [Google App Engine](http://www.youtube.com/watch?v=0zz-oSrWfj0) 上的 BuddyPoke 我要補充一點，使用 Guido 的新 AppStats 庫可以使您獲得有關數據存儲性能的真實數字，等等。沒有這種自省，這實際上只是一個猜測游戲。 內省還可以讓您找到那些地方-哎呀！ -您不小心從 for 循環或其他一些容易解決的問題中調用數據庫。 TOS 允許第 6 點嗎？ 好像沒有 http://code.google.com/appengine/terms.html 4.4。 您不得開發多個應用程序來模擬或充當單個應用程序，或以避免產生費用的方式訪問服務。 我也想知道西爾萬，但是我猜是因為他們是分開的服務，所以還可以。 Google 家伙就在那兒，因此一定不能違規。 我會問這點給 Google（freenode chat） 對我來說，TOS 很清楚：不同的服務，但最后只有一個應用程序：禁止使用。 否則，創建多個應用程序太容易了，或者我們可以將它們稱為“服務” :) -圖像的“一項服務” -CSS，js，...的“一項服務” -503、404，...的“一項服務” -發送郵件的“一項服務” -計算...的“一項服務” ... -等，... 并最終低于配額。 我認為 BuddyPoke 可以，因為它是主要的應用程序，顯示“成功”很重要。 不錯的提示，我將其中一些應用到我的應用中。 很快，我還將發布一些有關應用程序可擴展性的新技巧。 但是，GAE 錯誤級別如此之高... >我試圖找出實際成本是多少，因為有些人報告的成本高于預期，并且我想知道他的經驗如何。 沒有人會回答這些類型的問題，戴夫也不例外。 我從來不明白這一點。 我將自由地告訴任何詢問每月運行 reddit 的費用的人。 杰里米，每個月運行 Reddit 多少錢？ 我也對運行 Reddit 花費多少感興趣。 請告訴我，杰里米。 哦...看來杰里米從未回答...