對Google App Engine的可用性反饋

我們在Google App Engine上構建應用的一些很好的體驗，第一個應用的目標受衆是Google Apps用戶，因此在Google基礎架構上託管時沒有問題。對Google App Engine的可用性反饋

我們非常喜歡它，因此我們希望將它用於另一個應用程序，但是這個下一個項目是針對一個客戶，他並不真正對它所處的技術感興趣，他們只是希望它能夠工作，並且一直工作。

在這種情況下，考慮到我們對技術的適用性和能力方面有所涉及，是否有任何擔憂，這些東西還是比較新的，我們可能沒有像我們已經完成的那樣「控制」傳統託管？

2010-04-21 Ron Chan

你是正確的：你是不是儘可能多的控制與傳統的主機。不過，希望漲幅超過負面。 App Engine具有極高的可擴展性 - 它運行在運行Google本身的相同硬件上。您多久訪問一次http://google.com並且該頁面或搜索結果失敗？

儘管您讓Google運行您的代碼，但代碼仍然是您可以隨心所欲的操作。通過像django-nonrel這樣的新項目，您可以直接在App Engine上創建並運行原生Django應用程序，並且如果它不能滿足您的需求，那麼將該應用程序轉移到承載主機的ISP相當容易Django應用程序（其中有很多）。下面詳細介紹這個項目。

您不必擔心硬件，操作系統，機器映像，數據庫，Web服務器，前端負載平衡器，CDN /邊緣緩存，軟件/軟件包升級，許可費用等。所有這些都與您已經或將要解決特定問題的網絡或其他應用程序相關。無論您是否喜歡，所有這些額外的基礎設施都需要;但通過App Engine，您只需考慮應用/解決方案，而不需要額外的東西。

顯然你失去的另一件事是你的一些執行環境。確保您與您的雲鄰居（資源佔用，安全問題等）良好地協作），您必須在沙盒中執行，這意味着您的應用無法創建本地文件，打開網絡套接字等。不過，App Engine提供了豐富的API和產品功能，因此您至少可以創建有意義的應用：

可擴展的分佈式對象數據存儲區（參見下文）

內存緩存

的URLFetch

圖像服務（調整大小，裁剪等）

用戶的服務/認證任務隊列後臺處理

Django的網站模板

Blob存儲大文件

拒絕服務黑名單

transational任務

數據存儲光標

電子郵件的發送（和/或接收）

發送（和/或接收）的聊天/ IM /即時消息通過XMPP

你也有一個完整的dashboarded管理控制檯，它可以讓你監控你的應用程序的使用情況，喲您的帳單設置和歷史記錄，完整的配額使用情況轉儲，甚至您可以查看或下載的應用程序日誌。

要從@Anurag解決「主瘡點」：

1a上。免費配額相當慷慨......足以推動每月獲得5MM觀看次數的網站。另外，如果您信任Google給他們您的信用卡，他們會提高免費配額水平，即使更高。請看their quota page並參考「自由默認配額」和「計費啓用默認配額」列中的數字......以下是一些示例：a）請求數：默認爲1.3MM，帶計費的43MM啓用（wBE），b）數據存儲API調用：10MM默認值，140MM wBE，c）URL獲取：657K默認值，46MM wBE

1b。請求最多30秒：這對您來說更安全，因爲您的應用現在與其他人一起在操場上。谷歌必須確保所有的雲鄰居能夠很好地相互協作，而不是佔用CPU。然而，App Engine團隊正在努力尋找更長時間的後臺任務......目前還沒有時間表，但是it is on the public roadmap。

1c。在App Engine上編寫聊天服務器不僅是可能的，而且很簡單。這裏有一個使用創建App Engine的XMPP API - 這是非常愚蠢的，只是回顯到他們傳遞給我們的發送者（注意，您必須已經邀請用戶聊天）：

from google.appengine.api import xmpp 
from google.appengine.ext import webapp 
from google.appengine.ext.webapp.util import run_wsgi_app 

class XMPPHandler(webapp.RequestHandler): 
    def post(self): 
     msg = xmpp.Message(self.request.POST) 
     msg.reply("I got your msg: '%s'" % msg.body) 

application = webapp.WSGIApplication([ 
    ('/_ah/xmpp/message/chat/', XMPPHandler), 
], debug=True) 

def main(): 
    run_wsgi_app(application) 

if __name__ == '__main__': 
    main()

1D。 the public roadmap是未來「[支持]瀏覽器推（彗星）通信」，所以這也來了。

2a。「不是SQL」是Google App Engine最大的優勢之一！關係數據庫不會擴展，必須在某個時刻分割以防止RDBMS崩潰。它是是真實的，但它是稍微更難以移植，因爲它不是傳統的！基於Google Bigtable，您可以將App Engine數據存儲視爲可擴展的分佈式對象數據庫。 App Engine的讓你query the datastore using a Query object模型，或者如果你堅持，他們還提供了一個SQL-like GqlQuery interface。

2b。如django-nonrel這樣的新前衛項目，如果您創建了一個Django應用並使用它的ORM，那麼您可以使用一個純Django應用並直接在App Engine上運行它。同樣，您可以將其從App Engine中移出並直接轉移到承載Django應用程序的更傳統的ISP供應商。查詢保持完全一樣，並且您不必關心它是否執行SQL。

3a。長期運行的流程已經在上面的1b中討論過了。谷歌是意識到這種需要並正在處理它。

3b。 TaskQueue API支持10萬個電話，但是這被撞到1MM wBE ......這是每天的基礎。

3c。 Google強烈鼓勵將任務分解爲多個子任務。低延遲應用程序被認爲不會「佔用系統」，並且比那些速度慢並且從雲鄰居消耗更多資源的應用程序得到更好的處理。

來源

2010-04-22 01:34:37 wescpy

謝謝你，雖然我已經瞭解技術限制/偏好/要求，我很滿意他們。我最關心的問題是https://groups.google.com/group/google-appengine/browse_thread/thread/a7640a2743922dcf。儘管Google在解釋問題方面可能比大多數人都擅長，但就像你所說的那樣，這很可能不會發生。但是如果這樣的事情再次發生，在停機時間裏，沒有人會打電話給你，只能坐下來等着。你對此有何看法？ – 2010-04-22 07:28:03

你有一個好點，我們在雲計算的時代還處於早期。然而，我認爲他們的後驗是相當全面的，並且團隊正在努力確保這些東西很少（如果有的話）在未來發生。當發生宕機時，您不需要打電話給某人，因爲某人*必須*已被分頁......這樣的系統不會在沒有Google不知情的情況下發生。如果您確實需要聯繫Google，則可以在此創建新的製作問題：http://code.google.com/p/googleappengine/issues/entry – wescpy 2010-04-22 09:02:06

是的，你不會像傳統託管那樣控制太多。 GAE的主要瘡點是

配額等，最多30秒爲一個請求，因此彗星/反向AJAX等出窗口或非常困難的。嘗試在Google應用引擎上撰寫聊天服務器。沒有Sql數據庫，所以很難移植到其他服務器，如果需要的話，以及谷歌數據庫的某些時候有限制，例如，嘗試對排序的列以外的列進行比較的查詢排序。
長時間運行的過程中，有一個任務api，但如果您想要長時間運行後臺處理，則不能滿足要求，否則您將不得不在子任務中打開任務，因此事情變得複雜，甚至有配額每秒可以運行多少任務。

如果您的應用程序可以建模爲請求 - 響應註冊表，並且只需很少的後臺處理，GAE就很好。

看到這個太 Feedback on using Google App Engine?

來源

2010-04-21 13:17:11

對Google App Engine的可用性反饋

回答

相關問題