20 lines
6.1 KiB
Markdown
20 lines
6.1 KiB
Markdown
# Устройство распределенных систем
|
||
Сегодня всё больше и больше сложным систем начинают переводить, или проектировать в распределённом формате.
|
||
## Причины популярности РС
|
||
На то есть много причин, перечислим основные из них:
|
||
|
||
- **Размеры.** На данный момент заметна тенденция создания не просто отдельных приложений для выполнения конкретных задач, а формирования некоторой экосистемы, где пользователь может делать много всего через единую точку входа. Это повышает сложность проектирования системы: она больше физически не может поместиться в голове у разработчиков. Поэтому переход на структуру, когда всё разбито на мелкие, взаимосвязанные элементы вполне оправдан.
|
||
|
||
- **Масштабируемость.** Нагрузка на системы растёт постоянно. И нет оснований полагать, что дальше будет не так. Монолит конечно может держать нагрузку, но он лишён возможности точечного горизонтального масштабирования (упёрлись в то, что у нас очень долго работает механизм отправки сообщений о готовности – увеличили количество таких сервисов – узкое место ушло)
|
||
|
||
- **Переиспользуемость.** Написанные один раз сервис авторизации, можно с минимальными доработками перенести и в другие продукты. Это сокращает затраты на разработку системы.
|
||
|
||
## Оркестраторы
|
||
Так же, с приходом распределённых систем важную роль стали играть оркестраторы. Фактически, они смогли собрать в себе сразу ряд полезных функций: мониторинг состояния системы, оповещения пользователей о том, что что-то не так, организация процесса быстрого развёртывания, Возможность сбора, агрегации и анализа логов, для поиска узких мест системы и их дальнейшего устранения. Но, как и всегда, оркестратор имеет и минусы: он требует ресурсы (и порой не малые) для своей работы, порог входа у него не всегда низкий.
|
||
## Очереди сообщений
|
||
В распределённой системе, помимо прочего, появляется возможность активно использовать системы асинхронного обмена сообщениями через очереди. Этот механизм значительно экономит ресурсы процессора, так как позволяет вместо нахождения в бесконечном цикле ожидания (пока запрос обработается) делать что-то полезное. К тому же брокеры сообщений, которые часто используются в асинхронной обработке, могут повышать надёжность системы: если в момент обработки сообщения упадёт сервис-приёмник, то информация о подтверждении не доедет до очереди и сообщения будет доставлено через другой экземпляр, а не потеряется, так как очередь будет считать его недоставленным, и повторять отправку.
|
||
## Параллельные вычисления
|
||
Что же касается параллельных вычислений – это в первую очередь вопрос производительности. Использование нескольких потоков может ускорить работу кратно, но не всегда это применимо, так как порой перестройка алгоритма может потребовать ресурсов многократно больших, чем будет выигрыш, полученный от ускорения. Если речь о чистой математике(умножить матрицы) – это и правда полезно, а вот попытка развести высокоуровневую бизнес-логику по потокам – может быть изначально плохой идеей.
|
||
## Недостатки РС
|
||
Стоит так же отметить, что распределённые системы, несмотря на достоинства, имеют и недостатки. В основном их источник – отсутствие большого опыта создания таких систем, а так же простое правило, что вероятность ошибки в системе тем больше, чем из большего количества элементов она состоит. Отлаживать монолит и искать в нём уязвимости – проще, чем задумываться над тем, что будет, если в момент REST запроса один из сервисов откажет, или сеть упадёт.
|