Что разработчик может сделать для масштабирования?
Все мы привыкли к тому, что за масштабирование отвечает технический сотрудник, который устанавливает Load Balancer, добавляет ресурсы, расширяет возможности этих ресурсов, запускает несколько экземпляров нашего приложения, и многое другое. Все это кратко называется вертикальное и горизонтальное масштабирование, когда мы пытаемся увеличить производительность вычислительной системы путем добавления физических и\или виртуальных ресурсов, и расширить возможности этих систем.
Разработчик на этот процесс особо не влияет и казалось бы это все что мы можем сделать.
Но нет, на самом деле очень даже можем - используй реактивщину.
Реактивный подход позволяет существенно повысить производительность информационной системы.
Немного ретроспективы. Раньше разработчики пытались повышать производительность системы путем внедрения многопоточности. Это позволило выделять один независимый поток для каждого отдельно взятого процесса, так что каждый процесс выполняется независимо друг от друга. Таким образом, множество клиентов может взаимодействовать с системой одновременно.
Ничего плохого в этом не было, кроме того, что потоки работали в блокирующем режиме. Это означает, что пока система выполняет вычислительную операцию (включая распределённую операцию между разными процессами) поток отвечающий за изначальный процесс, будет ожидать завершения всей цепочки операций. Собственно в этой цепочке ожидать будут все.
Все это приводит к принудительному и нежелательному удерживанию ресурсов выделенных для информационной системы. Такой подход ведет к снижению возможностей системы, и как результат влияет на её производительность.
Идея реактивов заключается в использовании потоков совместно с Pub/Sub парадигмой, где ресурсы используются в неблокирующем режиме.
По сути, это напоминает тостер с алгоритмом действий "Загрузил -> Включил -> Ушел -> Сигнал о готовности -> Вернулся -> Выгрузил", где каждое следующее действие уведомляет о своей готовности, не требует ожидания и позволяется выполнять другие сторонние действия пока текущее не будет завершено.
Так, доступные ресурсы системы направляются на выполнение других задач, пока выполняется тяжеловесная цепочка процессов. Как только один из процессов цепочки выполнен и готов к обработке, то произойдёт уведомление о готовности, после чего туда будут направлены свободные ресурсы для обработки этого события.
А как часто ты используешь реактивщину на своих проектах? Пиши в комментариях.
🏆 Небольшой челендж! Хотите видео-разбор “Что такое Реактивная парадигма”?
Если данный пост наберет 300 лайков, то в ближайшее время мы подготовим для вас видеоматериал с разбором этой темы.
Макс Добрынин
Все мы привыкли к тому, что за масштабирование отвечает технический сотрудник, который устанавливает Load Balancer, добавляет ресурсы, расширяет возможности этих ресурсов, запускает несколько экземпляров нашего приложения, и многое другое. Все это кратко называется вертикальное и горизонтальное масштабирование, когда мы пытаемся увеличить производительность вычислительной системы путем добавления физических и\или виртуальных ресурсов, и расширить возможности этих систем.
Разработчик на этот процесс особо не влияет и казалось бы это все что мы можем сделать.
Но нет, на самом деле очень даже можем - используй реактивщину.
Реактивный подход позволяет существенно повысить производительность информационной системы.
Немного ретроспективы. Раньше разработчики пытались повышать производительность системы путем внедрения многопоточности. Это позволило выделять один независимый поток для каждого отдельно взятого процесса, так что каждый процесс выполняется независимо друг от друга. Таким образом, множество клиентов может взаимодействовать с системой одновременно.
Ничего плохого в этом не было, кроме того, что потоки работали в блокирующем режиме. Это означает, что пока система выполняет вычислительную операцию (включая распределённую операцию между разными процессами) поток отвечающий за изначальный процесс, будет ожидать завершения всей цепочки операций. Собственно в этой цепочке ожидать будут все.
Все это приводит к принудительному и нежелательному удерживанию ресурсов выделенных для информационной системы. Такой подход ведет к снижению возможностей системы, и как результат влияет на её производительность.
Идея реактивов заключается в использовании потоков совместно с Pub/Sub парадигмой, где ресурсы используются в неблокирующем режиме.
По сути, это напоминает тостер с алгоритмом действий "Загрузил -> Включил -> Ушел -> Сигнал о готовности -> Вернулся -> Выгрузил", где каждое следующее действие уведомляет о своей готовности, не требует ожидания и позволяется выполнять другие сторонние действия пока текущее не будет завершено.
Так, доступные ресурсы системы направляются на выполнение других задач, пока выполняется тяжеловесная цепочка процессов. Как только один из процессов цепочки выполнен и готов к обработке, то произойдёт уведомление о готовности, после чего туда будут направлены свободные ресурсы для обработки этого события.
А как часто ты используешь реактивщину на своих проектах? Пиши в комментариях.
🏆 Небольшой челендж! Хотите видео-разбор “Что такое Реактивная парадигма”?
Если данный пост наберет 300 лайков, то в ближайшее время мы подготовим для вас видеоматериал с разбором этой темы.
Макс Добрынин