novopolcev_alexander_lab_8 is ready
This commit is contained in:
parent
5dd9e26f07
commit
6e00a994c0
36
novopolcev_alexander_lab_8/README.md
Normal file
36
novopolcev_alexander_lab_8/README.md
Normal file
@ -0,0 +1,36 @@
|
||||
# Лабораторная работа №8 - Про устройство распределенных систем
|
||||
|
||||
## Задание
|
||||
|
||||
Написать небольшое эссе (буквально несколько абзацев) своими словами.
|
||||
|
||||
* Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
|
||||
* Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
|
||||
* Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
|
||||
* Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
|
||||
* Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
|
||||
|
||||
|
||||
### Эссе:
|
||||
|
||||
Создание системы на основе микросервисов позволяет каждому сервису выполнять конкретную задачу, что делает обслуживание и развитие системы гораздо проще. Такая архитектура облегчает адаптацию к изменяющимся требованиям бизнеса. К примеру, если в социальной сети нужно добавить новую функциональность, такую как обработка изображений, ее можно внедрить в отдельный сервис, не влияя на работу остальных частей системы.
|
||||
|
||||
Системы оркестрации разработаны для автоматизации развертывания, масштабирования и управления контейнерами в распределённой среде. Они значительно облегчают разработку и эксплуатацию распределённых систем, предлагая инструменты для автоматического масштабирования, восстановления после сбоев и управления сетевыми ресурсами.
|
||||
|
||||
Очереди сообщений обеспечивают асинхронную передачу данных между различными частями системы. Они предотвращают блокировку процессов, ожидающих завершения других задач, и гарантируют надёжную доставку данных даже при временных сбоях. Например, в социальных сетях сообщения о новых комментариях или лайках помещаются в очередь, откуда затем извлекаются и обрабатываются соответствующими сервисами.
|
||||
|
||||
Преимущества такой архитектуры включают:
|
||||
|
||||
Масштабируемость: Легко увеличиваем мощность системы, добавляя дополнительные ресурсы.
|
||||
Отказоустойчивость: Даже если один из компонентов выйдет из строя, другие продолжат работать.
|
||||
Модульность: Разработка и поддержка упрощены, поскольку каждый модуль выполняет отдельную функцию.
|
||||
Недостатками являются:
|
||||
|
||||
Сложная архитектура: Управление множеством взаимодействующих сервисов требует значительных усилий.
|
||||
Задержки и сетевые проблемы: Передача данных между сервисами через сеть может вызывать задержки и сбои.
|
||||
Параллельные вычисления полезны там, где необходимо быстро обработать большой объём данных или выполнить сложные расчёты. Например, социальные сети вроде «ВКонтакте» ежедневно обрабатывают огромное количество информации (постов, комментариев, фотографий, видео). Параллельная обработка данных позволяет быстрее отвечать на запросы пользователей и поддерживать высокую производительность.
|
||||
|
||||
Тем не менее, в некоторых случаях параллельные вычисления могут оказаться излишними. Например, небольшие аналитические отчёты, создаваемые раз в день, могут быть успешно выполнены стандартным однопоточным процессом без значительной потери времени. Применение параллелизма в таком случае будет неоправданным.
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user