Warning: mkdir(): No space left on device in /var/www/tgoop/post.php on line 37

Warning: file_put_contents(aCache/aDaily/post/java_fillthegaps/--): Failed to open stream: No such file or directory in /var/www/tgoop/post.php on line 50
Java: fill the gaps@java_fillthegaps P.287
JAVA_FILLTHEGAPS Telegram 287
Масштабирование: основные типы

Что такое масштабирование? Какие виды вы знаете? - популярные вопросы на собеседованиях на позицию мидл и выше.

На практике нас волнует не абстрактная стратегия масштабирования, а вполне конкретный вопрос: как обеспечить тот же уровень сервиса, если нагрузка на систему вырастет.

Иногда достаточно просто поменять код. Например, добавить кэш и снизить нагрузку на БД. В итоге сервис обработает в 10 раз больше запросов, и этого улучшения хватит на несколько лет. Но это не масштабирование, а оптимизация.

При масштабировании считается, что с кодом всё отлично и мы упираемся в физические ресурсы. Процессор не справляется, память кончается и так далее. И вопрос становится более конкретным: как добавлять аппаратные ресурсы к текущей системе?

На самом верхнем уровне масштабирование делится на горизонтальное и вертикальное.

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

При горизонтальном нагрузка распределяется на несколько машин
Отказ одного экземпляра не так страшен
Пределы масштабирования гораздо шире
Нужна инфраструктура для поддержки

В книжке Art of Scalability приводится концепт scale cube и три вектора горизонтального масштабирования:

🔸Horizontal duplication: несколько копий одного сервиса

Простая реализация, нам нужен только балансировщик
Запутанный код
Тяжело обновлять версию сервиса
Большие и перегруженные кэши

🔸Functional decomposition: делим монолит на микросервисы

Каждый сервис отвечает за небольшой функционал
Простой и понятный код каждого сервиса
Более специфичные и эффективные кэши
Поделить монолит на отдельные сервисы и наладить общение между ними - чудовищно непросто
Сложная инфраструктура

🔸Data partitioning или шардирование

Сервисы одни и те же, но каждый экземпляр работает на ограниченном количестве данных и своём экземпляре БД
Отказы БД менее критичны
Кэширование работает отлично
Нужен компонент для перенаправления запросов
Сложная логика работы с данными

На практике три подхода комбинируются в разных пропорциях.
1



tgoop.com/java_fillthegaps/287
Create:
Last Update:

Масштабирование: основные типы

Что такое масштабирование? Какие виды вы знаете? - популярные вопросы на собеседованиях на позицию мидл и выше.

На практике нас волнует не абстрактная стратегия масштабирования, а вполне конкретный вопрос: как обеспечить тот же уровень сервиса, если нагрузка на систему вырастет.

Иногда достаточно просто поменять код. Например, добавить кэш и снизить нагрузку на БД. В итоге сервис обработает в 10 раз больше запросов, и этого улучшения хватит на несколько лет. Но это не масштабирование, а оптимизация.

При масштабировании считается, что с кодом всё отлично и мы упираемся в физические ресурсы. Процессор не справляется, память кончается и так далее. И вопрос становится более конкретным: как добавлять аппаратные ресурсы к текущей системе?

На самом верхнем уровне масштабирование делится на горизонтальное и вертикальное.

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

При горизонтальном нагрузка распределяется на несколько машин
Отказ одного экземпляра не так страшен
Пределы масштабирования гораздо шире
Нужна инфраструктура для поддержки

В книжке Art of Scalability приводится концепт scale cube и три вектора горизонтального масштабирования:

🔸Horizontal duplication: несколько копий одного сервиса

Простая реализация, нам нужен только балансировщик
Запутанный код
Тяжело обновлять версию сервиса
Большие и перегруженные кэши

🔸Functional decomposition: делим монолит на микросервисы

Каждый сервис отвечает за небольшой функционал
Простой и понятный код каждого сервиса
Более специфичные и эффективные кэши
Поделить монолит на отдельные сервисы и наладить общение между ними - чудовищно непросто
Сложная инфраструктура

🔸Data partitioning или шардирование

Сервисы одни и те же, но каждый экземпляр работает на ограниченном количестве данных и своём экземпляре БД
Отказы БД менее критичны
Кэширование работает отлично
Нужен компонент для перенаправления запросов
Сложная логика работы с данными

На практике три подхода комбинируются в разных пропорциях.

BY Java: fill the gaps


Share with your friend now:
tgoop.com/java_fillthegaps/287

View MORE
Open in Telegram


Telegram News

Date: |

Activate up to 20 bots Telegram has announced a number of measures aiming to tackle the spread of disinformation through its platform in Brazil. These features are part of an agreement between the platform and the country's authorities ahead of the elections in October. The initiatives announced by Perekopsky include monitoring the content in groups. According to the executive, posts identified as lacking context or as containing false information will be flagged as a potential source of disinformation. The content is then forwarded to Telegram's fact-checking channels for analysis and subsequent publication of verified information. The Standard Channel How to Create a Private or Public Channel on Telegram?
from us


Telegram Java: fill the gaps
FROM American