From a9933fb8423b5cc0459661a67931ce29f6e118c0 Mon Sep 17 00:00:00 2001 From: ruden Date: Sat, 16 Dec 2023 12:02:18 +0300 Subject: [PATCH] mironov-eo-lab-8 --- tasks/mironov-eo/lab_8/README.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 tasks/mironov-eo/lab_8/README.md diff --git a/tasks/mironov-eo/lab_8/README.md b/tasks/mironov-eo/lab_8/README.md new file mode 100644 index 0000000..0cb1f44 --- /dev/null +++ b/tasks/mironov-eo/lab_8/README.md @@ -0,0 +1,27 @@ + # Отчет по лабораторной работе №8 + +Выполнил студент гр. ИСЭбд-41 Миронов Е.О. + +## Задачи + +Написать небольшое эссе (буквально несколько абзацев) своими словами. А помогут Вам в этом вопросы из списка: +1. Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач? +2. Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем? +3. Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями? +4. Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд? +5. Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет. + +## Эссе + +Сложные системы пишутся в микросервисной архитектуре для большей отказоустойчивости. Также это позволяет не повторять существующий код а решить проблему всего 1 раз и вынести в отдельный сервис, что соответствует принципу DRY и еще куче архитектурных паттернов. Микросервисная архитектура - это решение в котором есть свои плюсы и минусы, и далеко не каждому приложению подойдет такая архитектура. Я пока что считаю, что проще развернуть несколько экземлпяров монолита (возможно с несколькими обособленными сервисами), чем уходить в микросервисы, но это скорее всего потому что я еще не сталкивался с проектом которому действительно нужна микросервисная архитектура. + +Системы оркестрации приложений позволяет гибко управлять набором существующих контейнеров. Они позволяют вынести настройки группы контейнеров в отдельный конфигурационный файл. Системы оркестрации приложений помогают более быстро минимизировать количество однотипной работы при разворачивании контейнеров(имею ввиду создание образа, запуск и т. д.) + +Очереди обработки сообщений нужны для создания асинхронного API и ослабления связи между экземплярами сервисов. Мы посылаем сообщение брокеру и не заботимся о его доставке получателям, мы в принципе не знаем кто наши получатели. И наоборот получателей не волнует кто отправил сообщение, они знают только очередь из которой они его получили. + +Плюсы микросервисов - высокая отказоустойчивость, быстрое развертывание (хотя конечно зависит от реализации). +Минусы - задержки при передаче по сети, также любая передача по сети - лишняя угроза безопасности, сложность проектирования и разработки, сложность мониторинга системы. + +Распределенная система и параллельные вычисления - несвязанные понятия. Нам по большинству без разницы куда внедрять параллельность, в микросервисы или в монолит. Могу только представить ситуацию, когда два каких-то микросервиса физически размещены на одной машине, и при одновременных параллельных вычислениях будут мешать друг другу в борьбе за ресурсы процессора. +Если рассматривать многопоточность отдельно, то она тоже не всегда применима. Если рассматривать ситуацию, когда процессор постоянно активен на большой процент своей мощности, то при параллельной обработке одних данных, у нас будут медленее обрабатываться другие данные. Это применимо когда нам нужно как можно быстрее обработать что-то, к примеру когда на запрос клиента выполняются долгие вычисления и мы стараемся быстрее дать ответ (вешать тяжелые вычисления на клиентский запрос без всяких ограничений очень плохо), а ресурсами на выполнение какого-то фонового job можно и немного пожертвовать, из-за чего он выполнится позже (хотя на практике все с точностью наоборот). +При написании параллельных алгоритмов высок риск отхватить очень трудно находимую ошибку, поэтому лучше использовать параллельность там, где это действительно необходимо \ No newline at end of file