Как получить доступ к хранилищу данных ndb движка приложения Google из микросервиса python2.7 в том же проекте приложения - PullRequest
0 голосов
/ 13 октября 2018

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

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

Я знаю, что вы не можете использовать API хранилища облачных данных Google в стандарте движка приложений, но наверняка должен быть другой способ?

То же самое относится и к общему memcache, если я сделаю вызов APIдо конечной точки в модуле (без службы) из микросервиса и установить что-то в memcache в конечной точке, я не вижу этого в микросервисе.Поэтому, когда Google говорит об общем хранилище данных и memcache для всего в одном приложении, включая микросервисы, как они предлагают вам доступ к нему?

Я уверен, что что-то упустил, просто не могу его найти.

1 Ответ

0 голосов
/ 13 октября 2018

Для пояснения: термин microservice не означает ничего особенного в GAE в отношении взаимодействия с хранилищем данных (или иным образом) - все сервисы / модули GAE равны с этой точки зрения.Что делает сервис / модуль GAE microservice просто функциональностью, которую он выполняет, а не его реализацией или тем, как он использует инфраструктуру, см. Архитектура микросервисов в Google App Engine .

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

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

Простейшим способом получения такого согласованного представления является IMHO, используя тот же самый исходный файл определения модели ndb(s), что может быть достигнуто путем символической ссылки одного и того же фактического исходного (ых) файла (ов) (или каталогов, содержащих их) на несколько каталогов службы / модуля, как описано в Совместное использование объектов между модулями App Engine .

Другими словами, все ваши службы / модули, нуждающиеся в запросе / доступе / ссылке на Users сущностей тем или иным способом, на самом деле будут иметь одинаковое определение модели Users, доступное для этого.

При развертывании изменений в определениях моделей (будь то в разных службах или даже в разных версиях одной и той же службы) необходимо соблюдать осторожность, выполняя:

  • , обеспечивая обратную совместимость со стратегиями миграции
  • правильная оркестровка развертывания - то есть обеспечение того, чтобы несовместимые версии / службы никогда не работали одновременно

Тот же метод можно использовать для memcache аналогичным образом: файл с общим исходным кодом экспортирует определения memcacheключи для значений memcached, которые должны быть разделены между сервисами.Или, что еще лучше, предоставьте фактические функции чтения / записи для соответствующих данных, чтобы гарантировать, что данные не только хранятся под правильными ключами, но также имеют соответствующий формат.

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

...