[Л/Р 8] Островская Софья #98
62
tasks/ostrovskaya-sf/lab_8/README.md
Normal file
62
tasks/ostrovskaya-sf/lab_8/README.md
Normal file
@ -0,0 +1,62 @@
|
|||||||
|
# Отчет по лабораторной работе №8
|
||||||
|
|
||||||
|
Выполнила студентка гр. ИСЭбд-41 Островская С. Ф.
|
||||||
|
|
||||||
|
## Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
|
||||||
|
|
||||||
|
Существует несколько причин, по которым сложные системы, такие как социальные сети, часто разрабатываются в распределенном стиле с отдельными приложениями или сервисами, выполняющими ограниченный спектр задач:
|
||||||
|
|
||||||
|
1. Масштабируемость. Каждый сервис может быть масштабирован независимо от других, что позволяет обрабатывать большой объем трафика без значительного снижения производительности.
|
||||||
|
|
||||||
|
2. Устойчивость к сбоям. Отказ в работе одного приложения или сервиса не приводит к полному отказу системы.
|
||||||
|
|
||||||
|
3. Гибкость. Разделение функциональности на отдельные приложения или сервисы позволяет командам разработчиков работать над разными частями системы независимо друг от друга.
|
||||||
|
|
||||||
|
## Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
|
||||||
|
|
||||||
|
Системы оркестрации приложений были созданы для управления и координации распределенными системами, состоящими из множества приложений или сервисов. Они позволяют упростить и автоматизировать множество задач, таких как развертывание, масштабирование, мониторинг, сбор журналов, управление конфигурацией и т. д.
|
||||||
|
|
||||||
|
Сложности:
|
||||||
|
1. требуется дополнительное время и усилия на освоение и настройку инструментов оркестрации;
|
||||||
|
2. системы оркестрации могут иметь свои ограничения и требования к структуре и формату приложений.
|
||||||
|
|
||||||
|
## Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
|
||||||
|
|
||||||
|
Очереди обработки сообщений используются для организации и управления потоком информации между разными компонентами или сервисами в распределенной системе. Они обеспечивают асинхронную коммуникацию, где отправитель размещает сообщение в очереди, а получатель обрабатывает его в своем темпе.
|
||||||
|
|
||||||
|
Под сообщениями может подразумеваться различная информация, которая должна передаваться и обрабатываться между компонентами.
|
||||||
|
|
||||||
|
Это могут быть:
|
||||||
|
1. запросы на выполнение определенных операций;
|
||||||
|
2. данные для обработки;
|
||||||
|
3. уведомления о событиях.
|
||||||
|
|
||||||
|
Использование очередей обработки сообщений позволяет более гибко управлять потоком информации и улучшить отзывчивость системы, а также обеспечить отказоустойчивость, если один из компонентов временно недоступен. Это также может упростить масштабирование и обеспечить более эффективное использование ресурсов.
|
||||||
|
|
||||||
|
## Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
|
||||||
|
|
||||||
|
Преимущетва:
|
||||||
|
1. Масштабируемость. Распределенные приложения могут легко масштабироваться, чтобы справиться с большим трафиком или нагрузкой;
|
||||||
|
2. Отказоустойчивость. Если один узел выходит из строя, остальные узлы продолжают работать, что обеспечивает высокую доступность системы;
|
||||||
|
3. Балансировка нагрузки. Распределенная архитектура позволяет равномерно распределять нагрузку между узлами, что повышает производительность системы;
|
||||||
|
4. Улучшенная производительность. Распределённая архитектура может обеспечить лучшую производительность, так как данные и вычислительные операции могут быть распределены между несколькими узлами.
|
||||||
|
|
||||||
|
Недостатки:
|
||||||
|
1. Сложность разработки. Требуется учитывать множество аспектов, таких как координация между узлами, балансировка нагрузки и обработка отказов;
|
||||||
|
2. Задержки. Из-за необходимости коммуникации между узлами могут возникать задержки, особенно если система распределена по географически удаленным местоположениям;
|
||||||
|
|
||||||
|
## Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
|
||||||
|
|
||||||
|
Внедрение параллельных вычислений в сложную распределенную систему может быть целесообразным во многих случаях. Однако, это требует внимательного анализа и оценки конкретных требований и характеристик системы.
|
||||||
|
|
||||||
|
Примеры, когда внедрение параллельных вычислений действительно нужно:
|
||||||
|
|
||||||
|
1. Когда требуется обработка больших объемов данных.
|
||||||
|
2. Когда требуется повысить производительность и отзывчивость.
|
||||||
|
3. Когда задачи могут быть распараллелены. Если задачи в системе независимы и могут быть разделены на отдельные подзадачи, то внедрение параллельных вычислений будет эффективным. Например, в системе обработки изображений, каждое изображение может быть обработано параллельно, что значительно увеличит скорость обработки.
|
||||||
|
|
||||||
|
Примеры, когда внедрение параллельных вычислений не обязательно:
|
||||||
|
|
||||||
|
1. Когда система имеет низкую нагрузку и обрабатывает небольшой объем данных;
|
||||||
|
2. Когда задачи зависимы и не могут быть распараллелены. Если задачи в системе зависимы и требуют последовательного выполнения, то использование параллельных вычислений может привести к ошибкам или неправильным результатам;
|
||||||
|
3. Когда стоимость внедрения параллельных вычислений превышает выигрыш в производительности.
|
Loading…
Reference in New Issue
Block a user