Преобразование версий интерфейса App Engine в модули

Question

Я немного "злоупотребил" концепцией "внешней версии" в App Engine (java), чтобы реализовать модули до их появления. У меня есть конфигурация, состоящая из: module1-dot-myapp.appspot.com, module2-dot-myapp.appspot.com, module3-dot-myapp.appspot.com и т. Д., Основанная на концепции версии (чаще используется с цифры: 1-точка-myapp и т. д.).

В частности, код во всех версиях идентичен, но каждая из них практически используется для разных целей. Такое разделение позволяет различным клиентам использовать разные версии API, отдельное расписание развертывания, промежуточные версии, разделение журналов и т. Д.

Мой вопрос в этих условиях, как лучше всего преобразовать мое приложение в "настоящие" модули? такой, что "module1" является фактическим модулем (все еще сопоставленным с тем же url - module1-dot-appspot.com)?

Answer 1

Примечание: мой ответ прибывает из некоторого подобного упражнения, но во время выполнения Python GAE, вероятно, также есть дополнительные специфичные для Java вещи.

Первое, на что нужно обратить внимание (возможные ограничители шоу), - это конфиги уровня приложения - их нужно будет объединить с вашими старыми версиями приложений (если они существуют), и они будут доступны всем вашим модулям (или направлены в модуль по умолчанию). только), поэтому они могут работать не так, как раньше, лучше пересмотреть последнюю документацию по этим конфигам:

• файл отправки
• очередь
• хрон
• Индексы БД

Примечание: в многомодульных приложениях Python эти конфигурации могут не обновляться автоматически при загрузке приложения, каждое из них может быть загружено явно, с использованием соответствующих утилит конфигурации приложения.

Отдельный график развертывания практически бесплатен (каждый модуль может быть развернут независимо). Но может быть некоторое влияние из-за настроек на уровне приложения (например, несколько вызовов CLI вместо одного)

Разделение бревен происходит бесплатно.

Постановка может потребоваться пересмотреть, в зависимости от того, что именно вы подразумеваете под этим.

Кроме этого - вы бы поместили разные старые версии вашего приложения в отдельные подкаталоги модулей в вашем новом приложении. Проверьте, поддерживает ли ваша система контроля версий это проще. Старые файлы конфигурации приложения должны быть "переведены" в файл (ы) конфигурации соответствующего модуля, а некоторая информация попадет в верхний файл конфигурации нового приложения.

Маршрутизация URL модуля должна позволять прозрачное сопоставление URL, но обратите внимание, что URL фактически будут <module>-dot-<appname>.appspot.com и единственный способ получить точно такие же URL-адреса - удалить все старые версии приложения перед развертыванием новой (из-за конфликтующих URL-адресов: <module>-dot-<appname> против <appversion>-dot-<appname>, не уверен, что вы получите старый или новый обслуживающий код или если вообще возможно развернуть новый код без ошибок). Сначала вы можете использовать новое имя приложения, просто чтобы все утки выстроились в очередь перед переключением (возможно, это будет новая сцена, которую вы могли бы рассмотреть в будущем). Возможно, вам будет полезно дополнить маршрутизацию URL файлом отправки, если у вас его еще не было.

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