Масштабирование метеора (вопрос от неспециалиста)

TL; DR, неразумно ли создавать веб-приложение, используя Meteor в качестве нашей полнофункциональной среды, когда ожидается множество одновременных пользователей в масштабе?

Мы хотим создать веб-приложение, которое на первом этапе будет поиском музыкальных продуктов (подача отправленных пользователем URL-адресов из API Youtube для запросов воспроизведения).

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

Интересно, может ли кто-нибудь помочь моему невежественному мозгу понять с точки зрения непрофессионала, является ли что-либо, что я утверждал выше, неправильным/правильным, и если да, то почему? Искренне благодарен за любой / весь вклад в это


javascript meteor scaling prototyping
person Daniel Benny    schedule 02.07.2015    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

Рекомендуемая литература: Масштабирование Meteor: проблемы реального времени Приложения

person David Weldon    schedule 02.07.2015
comment
В метеоре нет ничего, что могло бы вызвать проблемы с масштабируемостью, если вы считаете, что по своей сути метеор просто связывает js и css и предоставляет их клиенту. Это само по себе может масштабироваться даже в одном экземпляре. - Ну, тот факт, что клиент и сервер много разговаривают, и клиент обычно запускает серверные команды, является одной из таких проблем. - person Benjamin Gruenbaum; 03.07.2015
comment
Не говоря уже о том, что метеор не масштабируется, но что при решении вопроса о его масштабировании - вероятно, лучше решить эти проблемы, а не заявлять, что их не существует. - person Benjamin Gruenbaum; 03.07.2015
comment
Я пытался подчеркнуть, что накладные расходы на связь и ЦП для приложения без учетных записей и подписок близки к 0, однако накладные расходы для приложения с многочисленными и сложными подписками могут быть значительными. Цель состоит в том, чтобы запустить и найти свое место в этом континууме. - person David Weldon; 03.07.2015
comment
Затем вы можете сказать, что в ответе что-то вроде Накладные расходы для приложения без учетных записей или подписок почти равны нулю с помощью Это обычно накладные расходы, которые вы платите за учетные записи, подписки и обновления в реальном времени, если в любом случае не используете метеор, только метеор оптимизирует это для вас в том или ином случае. Или что-то вдоль этих линий. - person Benjamin Gruenbaum; 03.07.2015
comment
Это еще один из тех аргументов, которые ослабляют озабоченность, указывая на то, что узкое место находится в другом месте, в данном случае это минимизация ресурсов разработчиков вместо обычных машинных ресурсов. Он обращается к вопросу, хотя и не отвечает на него. Я думаю, это ценный совет. - person joeytwiddle; 03.07.2015
comment
Возможно, было бы понятнее предупредить о спектре приложений с разной производительностью в начале ответа. И что этот совет действительно применим только к тем, кто пишет впервые, а не к тем, кто переписывает. Я согласен с тем, что во многих случаях оптимизация может быть применена позже. - person joeytwiddle; 03.07.2015
comment
Я не уверен, как я могу дать лучший ответ, учитывая, что исходный вопрос основан на мнении и не содержит деталей. Я начинаю жалеть, что не проголосовал за закрытие этого. Возможно, мне следует сделать свой ответ вики. - person David Weldon; 03.07.2015
comment
@davidweldon спасибо за ваш вклад. Ваш ответ дал нам много поводов для размышлений. Извините за двусмысленность вопроса. Не вдаваясь в подробности, в масштабе большого количества одновременных сеансов пользователи будут публиковать сообщения, комментировать, воспроизводить динамически меняющиеся списки воспроизведения музыки, организованные в списки сообщений, как описано в Product Hunt. Таким образом, количество и сложность подписок и оперативных обновлений теоретически будут высокими по сравнению с количеством одновременных пользователей. Изучив это, я чувствую себя более уверенно, продвигаясь вперед с Meteor. - person Daniel Benny; 12.07.2015

arrow_upward
1
arrow_downward

Совсем не безрассудно. Существует веб-сайт ClassCraft, созданный с использованием Meteor, который, по-моему, посещают 15 000 человек в день.

Самым простым решением, вероятно, будет использование службы хостинга на основе Node, такой как Modulus, которая автоматически выполнит масштабирование за вас.

Следующим шагом на пути к более самостоятельному решению будет размещение вашей MongoDB у поставщика, такого как Compose или MongoLab, но разместите само приложение Meteor на своих серверах. Просмотрите mup для простого сценария развертывания или более новое решение Аруноды, над которым он работает, mupx, который использует Docker для развертывания приложений Meteor.

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

person CaptSaltyJack    schedule 02.07.2015