70 lines
7.8 KiB
Markdown
70 lines
7.8 KiB
Markdown
|
# Лабораторная работа №8
|
|||
|
|
|
|||
|
|
## Задание
|
|||
|
|
|
|||
|
|
Написать небольшое эссе (буквально несколько абзацев) своими словами (пожалуйста не пользуйтесь гуглом :) ) на тему "Устройство распределенных систем". А помогут Вам в этом вопросы из списка:
|
|||
|
|
|
|||
|
|
1. Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
|
|||
|
|
2. Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
|
|||
|
|
3. Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
|
|||
|
|
4. Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
|
|||
|
|
5. Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
|
|||
|
|
|
|||
|
|
## Результат
|
|||
|
|
|
|||
|
|
### Зачем сложные системы пишутся в "распределенном" стиле.
|
|||
|
|
|
|||
|
|
Причина для этого очень проста и заключается в том, что **распределенный стиль** используется для повышения гибкости, масштабируемости и отказоустройчивости системы.
|
|||
|
|
Каждая функциональная часть системы выносится в отдельный сервис, что позволяет:
|
|||
|
|
|
|||
|
|
- Масштабировать именно те компоненты, которые наиболее нагружены, без необходимости увеличивать ресурсы для всей системы;
|
|||
|
|
- Разделять ответственность между командами разработки: каждая команда работает над своим сервисом, что ускоряет процесс разработки и внедрения изменений;
|
|||
|
|
- Повышать отказоустойчивость: если один сервис выходит из строя, это не нарушает работу всей системы, другие сервисы продолжают работать.
|
|||
|
|
|
|||
|
|
Например, тотже ВКонтакте может разделять сервисы для хранения фотографий, обработку сообщений и прочее.
|
|||
|
|
|
|||
|
|
### Для чего были созданы системы оркестрации сообщений.
|
|||
|
|
|
|||
|
|
**Системы оркестрации** (например, **Kubernetes**) автоматизируют развертывание, масштабирование и управление контейнерами.
|
|||
|
|
Это особенно полезно в распределенных системах, где необходимо управлять множеством взаимодействующих сервисов.
|
|||
|
|
Оркестраторы помогают:
|
|||
|
|
|
|||
|
|
- Автоматически перезапускать или перемещать сервисы при сбоях;
|
|||
|
|
- Упрощать масштабирование сервисов при увеличении нагрузки;
|
|||
|
|
- Упрощать обновление и откат изменений;
|
|||
|
|
- Мониторить состояние всех контейнеров и сервисов.
|
|||
|
|
|
|||
|
|
Системы оркестрации позволяют быстрее и проще развертывать и поддерживать сложные системы, но также требуют опыта для настройки и сопровождения.
|
|||
|
|
|
|||
|
|
### Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями.
|
|||
|
|
|
|||
|
|
**Сообщения** — это данные или события, которые передаются между сервисами для выполнения задач.
|
|||
|
|
|
|||
|
|
Очереди сообщений (например, **RabbitMQ**, **Kafka**) используются для асинхронного взаимодействия между сервисами.
|
|||
|
|
Тем самым очереди позволяют:
|
|||
|
|
|
|||
|
|
- Обеспечить надёжность передачи данных между сервисами даже при временных сбоях;
|
|||
|
|
- Разделить большие задачи на более мелкие и обрабатывать их параллельно;
|
|||
|
|
- Оптимизировать производительность, разгружая основные сервисы от частых операций ввода-вывода.
|
|||
|
|
|
|||
|
|
Например, сообщение может представлять собой запрос на отправку уведомления, сохранение данных или запуск какой-либо задачи.
|
|||
|
|
|
|||
|
|
### Какие преимущества и недостатки распределенных приложений существуют.
|
|||
|
|
|
|||
|
|
Распределённые приложения обладают преимуществами, такими как **масштабируемость**, **отказоустойчивость** и **гибкость**.
|
|||
|
|
|
|||
|
|
Каждый сервис можно развивать независимо, подбирая для него оптимальные технологии.
|
|||
|
|
Это ускоряет разработку и внедрение изменений.
|
|||
|
|
|
|||
|
|
Однако такие системы **сложнее разрабатывать и поддерживать**, требуя точного управления взаимодействием между сервисами и сложной отладки.
|
|||
|
|
Дополнительно **возрастают расходы** на инфраструктуру и оркестрацию, так как нужны системы мониторинга и очереди сообщений.
|
|||
|
|
|
|||
|
|
### Целесообразно ли внедрять параллельные вычисления в сложную распределенную систему.
|
|||
|
|
|
|||
|
|
Параллельные вычисления могут быть полезны, когда задачи могут выполняться независимо и параллельно, например:
|
|||
|
|
- Анализ данных и машинное обучение;
|
|||
|
|
- Потоковая обработка данных, в которых система работает с частыми событиями (обработка транзакций и прочее).
|
|||
|
|
|
|||
|
|
Однако параллельные вычисления могут быть излишними для задач, которые:
|
|||
|
|
- Содержат много зависимостей и требуют синхронизации;
|
|||
|
|
- Тяжелы для разделения на независимые части, то есть все идет последовательно и следующая часть зависит от результатов предыдущей.
|