45 уникальных просмотров

Как построить систему, способную выдержать высокие нагрузки, на примере онлайн-банка

Зачем нам вообще проектировать системы?

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

Так начинается проектирование высоконагруженных систем, где мы постепенно учимся выбирать подходящие технологии, чтобы клиенты оставались довольны.

Задержка и пропускная способность

Когда сервер один, а клиентов много, запросы начинают накапливаться в очереди. Представьте, что вы приходите в отделение банка, где работает всего один менеджер. Чем длиннее очередь, тем дольше вы ждёте (это задержка). Пропускная способность – это сколько клиентов менеджер способен обслужить за час. Если менеджер очень медленный, очередь быстро растёт. В системах то же самое: чтобы избежать очередей, нужно либо ускорить работу сервера, либо добавить дополнительные серверы.

Масштабирование и его виды

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

Вертикальное масштабирование – это когда мы берём наш сервер и увеличиваем его мощность. Например, если кассир банка не справляется, мы можем посадить на его место самого быстрого и опытного сотрудника. Это быстрое решение, но мощности одного сотрудника всё равно будут ограничены.
Горизонтальное масштабирование – это когда мы ставим рядом много одинаковых серверов, и они начинают обслуживать клиентов одновременно. Как если бы в отделении банка вместо одного кассира поставили пять окон, и очередь стала двигаться быстрее. Горизонтальное масштабирование надёжнее и помогает выдерживать очень большие нагрузки, но требует правильного управления запросами.

Автоматическое масштабирование

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

Теорема CAP и банковские транзакции

Важный момент в работе банковских систем – это точность данных. Предположим, вы отправляете деньги другу. Для банка критически важно знать, сколько денег на вашем счёте прямо сейчас. Здесь появляется теорема CAP, которая гласит, что невозможно одновременно гарантировать:

Согласованность данных (Consistency) – видеть всегда точные данные о состоянии счета.
Доступность (Availability) – банк всегда принимает запросы.
Устойчивость к разделению сети (Partition tolerance) – банк продолжает работать даже если связь с некоторыми серверами прерывается.

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

Масштабирование базы данных

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

Индексы – как оглавление в книге, помогают быстро находить нужные данные, например, баланс клиента по номеру счёта.
Партиционирование – база делится на части, чтобы каждый сервер работал только с одним куском. Например, база клиентов разбивается по регионам.
Архитектура master-slave – основной сервер (master) принимает платежи, а копии (slave) отвечают на простые запросы, например, показывают баланс.
Шардирование – данные клиентов разделяются на группы и хранятся на разных серверах. Например, клиентов с номерами счетов от 1 до 1000 храним на одном сервере, от 1001 до 2000 – на другом.
Недостаток шардирования – оно усложняет работу с запросами, требующими данных сразу из нескольких шардов.

SQL или NoSQL – что выбрать?

SQL – это базы данных, где всё чётко структурировано и данные хранятся в таблицах. Их чаще выбирают там, где важна строгая точность и надёжность информации. Например, для банковских операций: ведения баланса, переводов денег и расчёта процентов по кредитам. Такие базы обеспечивают строгую целостность данных (ACID), поэтому вы всегда уверены, что деньги клиента не исчезнут случайно. Но SQL-базы сложнее масштабировать, особенно если данных становится много.

NoSQL – это базы, в которых данные можно хранить свободно, без строгой структуры. Их используют, когда заранее неизвестно, какие данные придётся хранить и как часто они будут меняться. Например, банк хочет хранить поведение клиентов в мобильном приложении или анализировать комментарии пользователей. NoSQL проще и дешевле масштабировать при росте объёма данных, но при этом данные могут временно не совпадать в разных частях системы.

Идеальное решение – это сочетание, когда SQL – для финансовых операций и ключевых данных, а NoSQL – для аналитики, статистики, мониторинга и работы с быстро меняющейся информацией.

Почему онлайн-банк разбивается на микросервисы?

Сначала онлайн-банк может быть монолитным приложением – всё в одном месте. Но чем больше становится банк, тем сложнее управлять таким приложением. Поэтому оно разбивается на части (микросервисы), где каждая часть отвечает за что-то своё:

Один микросервис отвечает за вход клиентов.
Другой – за отправку денег.
Третий – за обработку платежей по кредитам.

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

Балансировщик нагрузки
Когда много одинаковых микросервисов, нужно распределять нагрузку равномерно. Балансировщик нагрузки – это как менеджер в банке, направляющий клиентов в свободные кассы. Он следит, чтобы никто не простаивал, а кто-то другой не перегружался.

Кэширование – зачем оно банку?
Представьте, клиент каждое утро проверяет баланс счета. Чтобы не пересчитывать его каждый раз заново, банк сохраняет баланс в кэше – это как короткая записка, на которой уже готов ответ. Так клиент быстрее получает нужную информацию, а сервер меньше нагружается.

Хранилище файлов и документов – почему не база данных?
Банк хранит много документов: договоры, чеки, фото клиентов. Это файлы большого размера (BLOB). Их неудобно хранить в базе данных, потому что она станет медленной. Для таких целей используют специальные хранилища (например, AWS S3), которые надёжно и быстро работают с большими файлами.

CDN – быстрая доставка контента
Представьте, банк решил показать всем клиентам новый рекламный видеоролик, размещённый на сервере в Москве. Клиенты с Дальнего Востока будут долго его загружать. CDN – это сеть серверов по всему миру, которые сохраняют копию видео и показывают клиентам его из ближайшей точки. Клиенты видят видео быстро, а сервер банка не перегружается.

Брокер сообщений – асинхронные задачи в банке
Если клиент запросил большую выписку по счету, которая требует много времени, банк не заставляет его ждать. Он отправляет задачу в специальную очередь – брокер сообщений (например, RabbitMQ или Kafka). Эта задача будет выполнена позже, а клиент получит уведомление, когда всё будет готово.

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

Apache Kafka – потоковая обработка данных
Kafka часто используется банками для сбора огромного потока данных: например, отслеживания транзакций по картам. Она выдерживает тысячи запросов в секунду, хранит и передаёт данные быстро и надёжно.

Консистентность данных – когда важна точность?
Для банковских платежей нужна строгая консистентность (Strong Consistency) – недопустимы ошибки. Но для подсчёта бонусных баллов допустима eventual consistency – небольшая задержка обновления.

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