Какие соображения следует учитывать для обеспечения масштабируемости

Question

На каком языке программирования, особенно на Java, какие соображения следует учитывать, чтобы обеспечить масштабируемость приложения? Давайте рассмотрим пример веб-приложения, которое одновременно обслуживает 1000 пользователей, и ожидается, что число пользователей может возрасти до 100 000. Также предположим, что в настоящее время предоставляются только определенные функции, и в будущем нам может понадобиться добавить еще много функций, таких как отчетность и т. Д. Нужно ли нам гарантировать, что определенные виды узких мест не возникают, или мы должны избегать определенных типов конструкций, которые могут ограничивать масштабируемость ?

Answer 1

1. Избегайте блокировок, особенно глобальных блокировок, насколько это возможно.
2. Статика часто вызывает ситуации, когда блокировка кажется хорошей идеей, избегайте статики в максимально возможной степени.Они также усложняют тестирование.
3. Как хранятся ваши данные?Вы используете базу данных Sql?Как это будет масштабироваться?Можете ли вы использовать вместо этого хранилище данных NoSql.Подсказка для приложения типа учета. Ответ - нет, нам нужна трансакциональность Sql.
4. Будьте осторожны с подписками типа «тянуть», в зависимости от того, могут ли масштабироваться подписки типа «нагрузка».например, 10 потребителей, проверяющих изменение состояния один раз в секунду, в порядке, 10000 потребителей, проверяющих изменение состояния один раз в секунду, является более сложной задачей.Если публикация данных один раз в минуту публикуется гораздо эффективнее, если они меняются чаще, чем 1 раз в секунду, издатель может выбрать пакетные изменения.
5. Поиск фигур звезды на диаграмме архитектуры, что происходит, когда компьютерцентр звезды перегружен?Во многих случаях это будет ваше хранилище данных, и большинство баз данных Sql являются дорогостоящими / трудно масштабируемыми за пределами одного мастера чтения / записи с большим количеством реплик только для чтения.Если это произойдет, и вы знаете, что вы будете сильно расти, то подумайте о разделении (разделении данных по нескольким мастерам чтения / записи) на ранних этапах.
6. Кэширование - это общий кеш, подобный Memcached, который собираетсяпомочь тебе?(часто устраняет необходимость в липких сессиях)
7. Наймите экспертов пораньше, чтобы хотя бы пересмотреть дизайн.

Answer 2

Решите, что для вас значит масштабируемость.

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

Итак, выясните, что может расти, а что нет, и вкладывайте свои деньги (и время) где ты боль.Оцените это.Измерьте это.

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

Помните, что для достижения лучшей масштабируемости вы должны где-то найти компромисс.Либо ваша программа будет расти во времени, памяти, аппаратных требованиях или каким-либо другим образом.Если у вас нет показателей производительности по времени обработки, использованию памяти и т. Д., Вы не выполнили предварительные требования для обеспечения масштабируемости.

Answer 3

Узкими местами являются IO (диск, база данных, ...) и сеть. Язык программирования не такая уж большая проблема.

Answer 4

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