Как типичное средне-крупное веб-приложение «развивается» в инфраструктуре?

Question

Тощий : Когда Facebook / Twitter / Youtube (что угодно) перешли от базовой идеи в программном обеспечении к ... большему (возможно, 100 000 пользователей?), Как они выросли?

Существует ли путь роста «передового опыта» для веб-приложений среднего размера?

Реальный вопрос : При определении или назначении ставок на проект веб-приложения среднего размера, что является значительными?В данном случае мы будем использовать PHP-фреймворк, но, похоже, они будут в основном распространяться на любой язык.

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

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

1) Инфраструктура: пространство облачных приложений, хранилище данных, синхронизация баз данных для ситуаций с несколькими центрами обработки данных.

2) Языковые и культурные проблемы: сделать приложение «привлекательным» или, по крайней мере, пригодным для использования на основных «культурных рынках»

3) проблемы с индексированием данных

4) проблемы с API / совместимостью (как встроенные приложения, такие как Facebook, так и внешний доступ к данным как для конечных пользователей, так и для крупных игроков, таких как поисковые системы и т. Д.)

... итак, я уверен, что мне не хватает примерно половины из них, и я мало представляю, как они расставляют приоритеты.

Принятый ответ здесь - довольно хорошая отправная точказа ответ, который я ищу.

Answer 1

Расширение первого элемента из вашего списка может показаться довольно важным, и оно поможет вам решить, с какими проблемами масштабирования вы столкнетесь, и даже осветить, какие классы технологий могут быть полезны. Это также затронет пункты 3 и 4, поскольку они как бы взаимосвязаны.

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

Каковы ваши функции в приложении? Они читают тяжелые или пишут тяжелые, или, может быть, оба? Когда вы просматриваете данные, должно ли оно быть в режиме реального времени самым новым из всех возможных состояний? ИЛИ это может быть отложено? Как далеко это может быть отложено? Может ли помочь кеширование? Кэширование - это самая легкая часть, также подумайте о том, как ДОБРАТЬ кеширование, вот где трудные вещи. Как выглядят данные, с которыми вы работаете? Это очень реляционный, или больше похоже на отдельные документы?

Каковы ваши требования к производительности? - В основном приложение генерирует отчеты в фоновом режиме и отправляет их по электронной почте? Или нужно отобразить идеальную карту в реальном времени всех текущих твитов из твиттера по мере их появления? Нужно ли, чтобы обновления от пользователей немедленно распространялись на других пользователей? Каждый пользователь или только его часть? Как быстро это должно быть сделано? Нужно ли загружать страницу меньше 300 мс или меньше 2 с?

Есть ли у внешних служб какие-либо ограничения, например, лимиты на запросы или ограничения? Это означает, что вам нужно ставить в очередь и группировать запросы. Некоторые ваши поставщики внешних данных отправляют вам данные быстрее, чем вы можете их обработать? Возможно, вам придется поставить его в очередь, вам может потребоваться сделать эту часть системы масштабируемой самостоятельно, с переменным числом «рабочих», которые могут перемещаться вверх и вниз. Рассмотрите возможность применения этого «индивидуально масштабируемого» принципала к другим частям системы, он приносит дивиденды в больших установках.

Надеюсь, это поможет несколько:)