Как думать при проектировании высоконагруженной системы?
Многие считают, что проектирование крупного проекта — магия и волшебство. На самом деле научиться можно всему, и никакой магии тут нет. Нужно правильно думать, применять архитектурные приёмы и паттерны проектирования.
Проектируем «банк»
Каждый из нас был в банке. И многие помнят, что, скажем, 15 лет назад, организация обслуживания клиентов была заметно хуже, а времени вы тратили больше. Как ни странно, банк можно сравнить с высоконагруженной масштабируемой системой, которая используется в вебе.
Итак, представьте огромную очередь в одно из окошек банка. Очевидно, что главной целью любого более-менее вменяемого руководства будет увеличение пропускной способности отделения. Первое, что приходит в голову — горизонтальное масштабирование (достраиваем окошки, усаживаем дополнительных операторов). Вроде всё просто: несколько окошек — несколько очередей, которые уменьшатся в размерах. Однако это не самое эффективное разделение, ведь придётся дублировать всё: принтер, компьютер, канцелярские принадлежности и много чего ещё. И каждый оператор будет решать множество задач: выдавать кредиты, оформлять карточки, выплачивать пенсии, принимать платёжки… Минусы очевидны — повышенные затраты, много затраченных ресурсов, возможный недогруз.
К тому же, разные процессы выполняются с разной скоростью и три человека, одновременно оформляющие пластиковые карточки в 3 окошках, заставят ждать всех остальных.
Значит, нужно подумать не только над распараллеливанием очередей, но и над специализацией, т. е. следует провести горизонтальное масштабирование вместе с функциональным разделением. Пусть каждая группа банковских работников занимается только своим делом: кто-то принимает платёжки, кто-то выдаёт кредиты, кто-то пластиковые карты и пр.
Впрочем, и эта ситуация неидеальна, мы можем ускорить процесс. Давайте упростим взаимодействие посетителя с операторами. Речь идёт о том самом «едином окне», которое вы сегодня видите, когда входите в банк, — специальном аппарате, принимающем запросы и выдающем клиенту квиток (тот самый, на котором написано, в какое окошко вам следует обратиться, исходя из цели вашего прихода). Номер квитка высвечивается над свободным оператором с соответствующей специализацией. Таким образом мы организуем и конвейер, и входящую балансировку. Ещё раз: мы получаем не просто разделение по сервисам, но можем балансировать нагрузку, выделяя на каждую стадию тот объём ресурсов, который необходим.
Теперь добавляем отложенные вычисления. Например, некоторые запросы (процессы) можно выполнять не сразу, а при спаде нагрузки либо после окончания операционного рабочего дня. Допустим, клиент подал заявку на кредит, а проверить его данные в системе мы можем тогда, когда это удобнее нам (с учётом заложенных на это временных норм, разумеется).
Также можно добавить предобработку — это, например, подготовленные инструкции по заполнению платёжных поручений и т. п.
Ещё можно заранее распечатать стандартные бланки или подготовить формы, в которых будет заполнено всё, кроме данных клиента — это кэширование.
Кроме того, вводим толстого клиента — ставим перед входом в банк онлайн-терминал и банкомат, которые позволят выполнить массу операций вне зависимости от работы основного офиса.
Изюминка на торте — сотрудник на входе, который будет отвечать на вопросы и выполнит роль фронтенда, самостоятельно обрабатывая лёгкие запросы («Могу ли я оплатить здесь эту квитанцию?», «До скольки вы работаете?», «Что мне выбрать на терминале, если я хочу открыть счёт?»).
Делаем выводы
Итак, мы получили на выходе сложную систему, включающую в себя: — распараллеливание; — предобработку; — очередь; — балансировку; — конвейер; — отложенные вычисления; — кэширование; — толстого клиента.
Результат — серьёзное увеличение пропускной способности. Как видим, никакой магии нет — всего лишь логика, инженерный подход и немного интуиции.
