Архитектура, ориентированная на Firebase

Это архитектурный вопрос.

В настоящее время я занимаюсь разработкой веб-приложения, и я привык к основному: внешнему интерфейсу, API, базе данных, настройке микросервисов.

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

Меня интересуют две основные части: облачные функции Google и Firebase. Насколько я понимаю, облачные функции Google могут запускаться при манипулировании записью базы данных в firebase.

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

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


google-cloud-firestore architecture serverless
person Alex Haller    schedule 31.12.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Насколько я знаю, триггеры облачных функций — это бета-функция в Firebase, и согласно документу существуют некоторые ограничения для триггерных событий firestore:

  • Реакция функции на изменения в Cloud Firestore может занять до 10 секунд.
  • Заказ не гарантируется. Быстрые изменения могут инициировать вызовы функций в неожиданном порядке.
  • События доставляются по крайней мере один раз, но одно событие может привести к вызову нескольких функций. Избегайте зависимости от однократной механики и пишите идемпотентные функции.
  • Триггеры Cloud Firestore для Cloud Functions доступны только для Cloud Firestore в основном режиме. Он недоступен для Cloud Firestore в режиме хранилища данных.

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

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

Кроме того, согласно документу, скорость облачных функций ограничена 16 вызовами на 100 секунд, которые могут быть быстро достигнуты, если у вас есть трафик в вашем приложении.

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

person Cosmin Ioniță    schedule 01.01.2021