tasks/mutriskov-ds/lab_8/README.md

@@ -0,0 +1,13 @@
+# Отчёт по лабораторной работе №8
+
+Выполнил: студент гр. ИСЭбд-41 Мутрисков Д.С.
+
+Сложные системы пишутся в микросервисной архитектуре для большей отказоустойчивости. Также это позволяет не повторять существующий код а решить проблему всего 1 раз и вынести в отдельный сервис, что соответствует принципу DRY и еще куче архитектурных паттернов. Микросервисная архитектура - это решение в котором есть свои плюсы и минусы, и далеко не каждому приложению подойдет такая архитектура. Я пока что считаю, что проще развернуть несколько экземлпяров монолита (возможно с несколькими обособленными сервисами), чем уходить в микросервисы, но это скорее всего потому что я еще не сталкивался с проектом которому действительно нужна микросервисная архитектура.
+
+Системы оркестрации приложений позволяет гибко управлять набором существующих контейнеров. Они позволяют вынести настройки группы контейнеров в отдельный конфигурационный файл. Системы оркестрации приложений помогают более быстро минимизировать количество однотипной работы при разворачивании контейнеров(имею ввиду создание образа, запуск и т. д.)
+
+Очереди обработки сообщений нужны для создания асинхронного API и ослабления связи между экземплярами сервисов. Мы посылаем сообщение брокеру и не заботимся о его доставке получателям, мы в принципе не знаем кто наши получатели. И наоборот получателей не волнует кто отправил сообщение, они знают только очередь из которой они его получили.
+
+Плюсы микросервисов - высокая отказоустойчивость, быстрое развертывание (хотя конечно зависит от реализации). Минусы - задержки при передаче по сети, также любая передача по сети - лишняя угроза безопасности, сложность проектирования и разработки, сложность мониторинга системы.
+
+Распределенная система и параллельные вычисления - несвязанные понятия. Нам по большинству без разницы куда внедрять параллельность, в микросервисы или в монолит. Могу только представить ситуацию, когда два каких-то микросервиса физически размещены на одной машине, и при одновременных параллельных вычислениях будут мешать друг другу в борьбе за ресурсы процессора. Если рассматривать многопоточность отдельно, то она тоже не всегда применима. Если рассматривать ситуацию, когда процессор постоянно активен на большой процент своей мощности, то при параллельной обработке одних данных, у нас будут медленее обрабатываться другие данные. Это применимо когда нам нужно как можно быстрее обработать что-то, к примеру когда на запрос клиента выполняются долгие вычисления и мы стараемся быстрее дать ответ (вешать тяжелые вычисления на клиентский запрос без всяких ограничений очень плохо), а ресурсами на выполнение какого-то фонового job можно и немного пожертвовать, из-за чего он выполнится позже (хотя на практике все с точностью наоборот). При написании параллельных алгоритмов высок риск отхватить очень трудно находимую ошибку, поэтому лучше использовать параллельность там, где это действительно необходимо