По вопросам масштабирования Firebase Backend - PullRequest
1 голос
/ 18 февраля 2020

Я начинаю разработку на бэкэнд-системе. Он будет поддерживать кроссплатформенные мобильные приложения. Бэкэнд имеет много функций, которые побудили меня разделить бэкенд на 8 сервисов (развернутых как облачные функции) и представленных как REST API для клиентов. Каждая из развернутых функций будет использовать firestore и будет строго запрашивать коллекции, относящиеся к этой конкретной службе. Межсервисный обмен данными по протоколу HTTP строго запрещен, и все такие обмены сообщениями ограничены облачными сообщениями.

Теперь мне недавно сказали, что Firebase будет «узким местом» и не сможет справиться с масштабированием. Я вполне уверен, что масштабирование не будет проблемой, поскольку масштабирование службы будет просто означать увеличение числа развернутых экземпляров функции. То же самое касается базы данных (Firestore). С общей точки зрения, для меня безопасно говорить, что Firebase будет масштабируемым? Я знаю, что есть много проблем, и это широкий вопрос. Тем не менее, такие проблемы даже будут существовать, когда я go для моей собственной настройки на VPS. Итак, чтобы прояснить мой вопрос: с точки зрения бэкэнда, в котором есть много сервисов, разработанных как REST API. Firebase является масштабируемой опцией? Любые предложения, ссылки или руководящие принципы будут высоко оценены.

1 Ответ

3 голосов
/ 18 февраля 2020

То, о чем вы спрашиваете, на самом деле не о «Firebase» (это платформа для разработки мобильных приложений), а о облачных функциях, которые являются масштабируемым продуктом Google Cloud без сервера. Firebase просто добавляет инструменты и API поверх основного продукта Cloud Functions. В противном случае код, развернутый с помощью Firebase CLI, ведет себя точно так же, как если бы вы развернули его с помощью инструментов Google Cloud. Подробнее об отношениях между Firebase и Google Cloud в отношении облачных функций читайте в этой статье .

То же самое относится и к Firestore, который также является продуктом Google Cloud. Он масштабируется, и вы можете прочитать о известных ограничениях . Прочитайте аналогичный блог о различиях между Firebase и Google Cloud в отношении Firestore.

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

Опять же, ни одно из этого не имеет отношения к Firebase или любому другому, его многим продуктам. Все, что вам нужно понять, - это поведение отдельных продуктов, которые вы хотите использовать, оба из которых являются продуктами Google Cloud.

Кто бы вам ни сказал, что у вас возникнут проблемы с масштабированием с помощью "Firebase", вероятно, ссылался на Продукт Firebase Realtime Database, который имеет ограничения, которые требуют использования шардинга, если вы хотите масштабировать масштабно. У Firestore такого ограничения нет - вам не нужно ничего делать, чтобы его масштабировать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...