Используйте интерфейс REST для внутренних запросов Google AppEngine

Question

Я начал писать REST API для моего приложения Google AppEngine.Я прочитал хорошую статью по архитектуре REST-приложений, в которой предлагалось инкапсулировать свои службы данных за API REST.Учитывая, что я хотел бы быть готовым перейти к архитектуре, такой как Amazon Web Services, если прототип набирает обороты, этот уровень инкапсуляции имеет смысл.

Идея состоит в том, что запрос поступает для веб-страницы и приложения.Сервер принимает HTTP-запрос.Затем сервер приложений сам отправляет HTTP-запрос REST на сервер базы данных вместо того, чтобы проходить напрямую через объекты хранилища данных.В случае Google AppEngine это фактически тот же сервер, но было бы легко изменить, какой сервер (или кластер серверов) будет фактически отвечать на запросы данных.

Например:

1. http://example.com/index.html
   • приводит к тому, что HTTP-запрос обрабатывается сервером приложений
2. http://example.com/remote/data?filter=all
   • сервер приложений создаетзапрос данных с удаленного сервера
3. Сервер приложений
   • анализирует удаленный ответ
   • вставляет данные в шаблон HTML
   • возвращает результат клиенту

Примечание: это не включает в себя кэширование, которое у меня было бы.

Это означает, что для одного HTTP-запроса клиента я мог бы в конечном итоге сделать 4-5 дополнительных HTTP-запросов для создания ответа.Это архитектурный шаблон, который будет хорошо работать в Google AppEngine или вообще?Эффективно ли обрабатывает Google внутренние запросы (экземпляр-сервера-приложения-экземпляра)?

Answer 1

Этот шаблон не имеет большого смысла для AppEngine.

Учтите, что существуют фиксированные ограничения для некоторых ресурсов AppEngine, таких как URLFetch, которые могут быстро истощаться.Кроме того, ресурсы, подлежащие оплате, такие как процессорное время, входящая пропускная способность и исходящая пропускная способность, будут использоваться с гораздо большей скоростью, чем это необходимо.

Кроме того, это существенно ограничивает возможности вашего приложения AppEngine масштабировать.На самом деле, это отрицательная обратная связь.По мере увеличения количества внешних запросов нагрузка на ваше приложение будет стремительно возрастать .Это антитеза того, что вы должны пытаться достичь с помощью приложения AppEngine.

Наконец, я бы предположил, что это сомнительная архитектура для приложения на любой платформе, а не толькоAppEngine.Инженеры-программисты легко могут влюбиться в абстракцию, создавая послойные слои ради таких ценностей, как модульность, портативность, слабая связь - список можно продолжать и продолжать.Однако любое решение, принятое по абстрактной причине, которая приводит к очень реальному и значительному снижению производительности, является де-факто анти-паттерном.

Answer 2

Сначала с точки зрения архитектуры можно создать слой доступа к данным REST над хранилищем, см., Например, документы Microsoft Azure http://msdn.microsoft.com/en-us/library/dd179423.aspx

Естественно, вы столкнетесь с некоторой потерей производительности при выходе за пределы ядра приложения иделать ваши запросы через urlfetch.Я бы посоветовал сравнить выставление счетов за хранилище данных с urlfetch перед выполнением перемещения.

Если вы создаете DAL для выполнения этих вызовов REST на удаленной БД, нет никакой причины фактически делать urlfetches для вашего хранилища данных GAE.Просто напишите поставщика движка приложений, который делает эти вызовы БД напрямую с помощью DataStore API http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/datastore/package-summary.html