distributed-computing/tasks/mironov-eo/lab_8/README.md

# Отчет по лабораторной работе №8

Выполнил студент гр. ИСЭбд-41 Миронов Е.О.

Задачи

Написать небольшое эссе (буквально несколько абзацев) своими словами. А помогут Вам в этом вопросы из списка:

1. Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
2. Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
3. Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
4. Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
5. Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.

Эссе

Сложные системы пишутся в микросервисной архитектуре для большей отказоустойчивости. Также это позволяет не повторять существующий код а решить проблему всего 1 раз и вынести в отдельный сервис, что соответствует принципу DRY и еще куче архитектурных паттернов. Микросервисная архитектура - это решение в котором есть свои плюсы и минусы, и далеко не каждому приложению подойдет такая архитектура. Я пока что считаю, что проще развернуть несколько экземлпяров монолита (возможно с несколькими обособленными сервисами), чем уходить в микросервисы, но это скорее всего потому что я еще не сталкивался с проектом которому действительно нужна микросервисная архитектура.

Системы оркестрации приложений позволяет гибко управлять набором существующих контейнеров. Они позволяют вынести настройки группы контейнеров в отдельный конфигурационный файл. Системы оркестрации приложений помогают более быстро минимизировать количество однотипной работы при разворачивании контейнеров(имею ввиду создание образа, запуск и т. д.)

Очереди обработки сообщений нужны для создания асинхронного API и ослабления связи между экземплярами сервисов. Мы посылаем сообщение брокеру и не заботимся о его доставке получателям, мы в принципе не знаем кто наши получатели. И наоборот получателей не волнует кто отправил сообщение, они знают только очередь из которой они его получили.

Плюсы микросервисов - высокая отказоустойчивость, быстрое развертывание (хотя конечно зависит от реализации). Минусы - задержки при передаче по сети, также любая передача по сети - лишняя угроза безопасности, сложность проектирования и разработки, сложность мониторинга системы.

Распределенная система и параллельные вычисления - несвязанные понятия. Нам по большинству без разницы куда внедрять параллельность, в микросервисы или в монолит. Могу только представить ситуацию, когда два каких-то микросервиса физически размещены на одной машине, и при одновременных параллельных вычислениях будут мешать друг другу в борьбе за ресурсы процессора. Если рассматривать многопоточность отдельно, то она тоже не всегда применима. Если рассматривать ситуацию, когда процессор постоянно активен на большой процент своей мощности, то при параллельной обработке одних данных, у нас будут медленее обрабатываться другие данные. Это применимо когда нам нужно как можно быстрее обработать что-то, к примеру когда на запрос клиента выполняются долгие вычисления и мы стараемся быстрее дать ответ (вешать тяжелые вычисления на клиентский запрос без всяких ограничений очень плохо), а ресурсами на выполнение какого-то фонового job можно и немного пожертвовать, из-за чего он выполнится позже (хотя на практике все с точностью наоборот). При написании параллельных алгоритмов высок риск отхватить очень трудно находимую ошибку, поэтому лучше использовать параллельность там, где это действительно необходимо