Merge pull request 'haliullov_kamil_lab_8' (#407) from haliullov_kamil_lab_8 into main

Reviewed-on: #407
This commit is contained in:
Alexey 2025-01-02 13:17:59 +04:00
commit 16d3e42d0a

View File

@ -0,0 +1,33 @@
# Лабораторная работа №8 - Про устройство распределенных систем
## Задание
Написать небольшое эссе (буквально несколько абзацев) своими словами.
* Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
* Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
* Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
* Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
* Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
### Эссе:
Разбиение системы на микросервисы позволяет каждому отдельному модулю выполнять конкретную задачу, что облегчает его обслуживание и модернизацию. Такая архитектура делает систему гибче к изменениям требований бизнеса. К примеру, если в социальной сети нужно внедрить новую функциональность, связанную с обработкой изображений, её можно реализовать как отдельный сервис, не затрагивая другие элементы системы.
Системы оркестрации были разработаны для автоматизации процесса развертывания, масштабирования и управления контейнерами в распределённой среде. Они значительно облегчают создание и эксплуатацию распределённых систем, предлагая инструменты для автоматического масштабирования, восстановления после отказов и управления сетью.
Очереди сообщений используются для асинхронной передачи данных между разными частями системы. Они предотвращают блокировку процессов, ожидающих выполнения других задач, и обеспечивают надёжную доставку информации даже при кратковременных сбоях. Например, в социальных сетях действия пользователей, такие как комментарии или лайки, отправляются в очередь, где они затем последовательно обрабатываются нужными сервисами.
Преимущества такой архитектуры включают:
- Масштабируемость: возможность быстро наращивать мощности системы, добавляя дополнительные ресурсы.
- Отказоустойчивость: при выходе одного компонента из строя остальные продолжают функционировать.
- Модульность: упрощение разработки и поддержки благодаря тому, что каждый модуль отвечает за определённую функцию.
Недостатками являются:
- Сложность архитектуры: управление множеством взаимосвязанных сервисов требует значительных усилий.
- Задержки и сетевые проблемы: передача данных между сервисами через сеть может вызывать задержки и сбои.
Параллельные вычисления эффективны там, где необходимо обрабатывать большие объемы данных или выполнять сложные расчёты. Например, социальные сети вроде «ВКонтакте», ежедневно обрабатывающие огромное количество контента (постов, комментариев, фотографий, видео), выигрывают от параллельной обработки данных, что помогает быстрее отвечать на запросы пользователей и поддерживать высокую производительность.
Тем не менее, в некоторых случаях параллелизация не всегда оправдана. Например, небольшие аналитические отчёты, создаваемые раз в сутки, могут быть успешно обработаны стандартным однопоточными процессами без заметной потери времени. В этом случае использование параллельных вычислений будет излишним.