оригинальный контент в


Они разрабатывают

Вы когда-нибудь слышали утверждение, что «настоящие системы масштабирования асинхронны»?

Если это предложение не имеет для вас большого смысла, угадайте, что оно сделает ─ я распакую эту штуку для вас!

копия @sseraphini

Изображение


Во-первых, что такое асинхронные системы? Это системы, которые работают не синхронно. То есть каждая часть делает одно дело в разное время.

Конечно, в конце концов, это части, которые объединяются для достижения большего дела, но интеграция между этими частями не связана.


Когда мы говорим о развязке, мы обязательно вводим косвенность. То есть, чтобы отделить А от Б, нам нужно ввести что-то между ними.

Есть несколько способов сделать это, и два самых распространенных — обмен файлами и системы очередей. Сосредоточимся на очередях.

Изображение


Пока гладко?

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

Представьте себе систему, состоящую из 4 приложений, которые синхронно интегрируются, например, через HTTP. A, который вызывает B, который вызывает C, и D, который вызывается A.

Изображение


Предположим, что эта система, как она есть сегодня, поддерживает до 100 r/s (запросов в секунду). Это означает, что A, B, C и D поддерживают по 100 об/с каждый.

Максимальная емкость системы всегда равна наименьшей емкости среди участвующих приложений.


Если бы нам нужно было увеличить эту пропускную способность, чтобы поддерживать 200 об/с, обязательно пропускная способность A, B, C и D была бы по 200 об/с каждая.

Это классическая чушь синхронной интеграции: все должно масштабироваться, когда что-то нужно масштабировать.


Проблема пропускной способности r/s — лишь один из аспектов масштабируемости. Например, отказоустойчивость, как правило, ниже в синхронных системах. Если какое-то одно из 4-х приложений дает сбой, запрос тоже не работает ─ система в целом дает сбой в восприятии пользователя.


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

Взгляните на эту диаграмму той же системы, гипотетически переформулированной для асинхронности.

Изображение


Теперь, если подумать о запросах в секунду при преобразовании системы в асинхронную, приложение A — единственное, которому действительно необходимо поддерживать заданную пропускную способность.
Очередь в интеграции будет выполнять роль буфера, а B/C и D будут работать в соответствии с их индивидуальными возможностями.


Еще один важный момент — отказоустойчивость. С точки зрения пользователя сбой в B, C или D не будет непосредственно заметен, и A по-прежнему сможет получать запросы и отвечать на них. Это красиво, правда?


Но не верьте, что асинхронные системы — это тысяча чудес, которые решат вашу жизнь!

Асинхронная система может быть намного сложнее, и опыт пользователя может значительно измениться.


Как правило, при разработке асинхронных систем мы полагаемся на необходимый пользовательский опыт.

Например, может быть, бронирование места в кинотеатре станет попыткой, а не мгновенным ответом «сработало», сработало». Как справиться с этим промежуточным состоянием?


Приложения, которые работают за пределами непосредственного восприятия пользователями, также могут иметь ограничения по времени обработки. Еще в примере с кинотеатром, если бронирование места было в приложении Б, возможно, пользователь не захочет ждать 2 часа, чтобы узнать, прошло ли бронирование успешно.


В конце концов, как и во всем в жизни, важно понимать плюсы и минусы каждого подхода.

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


Как всегда, большое спасибо, что дочитали до этого места!

Поцелуй для тех, кто целуется, или объятие для тех, кто обнимается. 😗 🤗