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