27 lines
6.7 KiB
Markdown
27 lines
6.7 KiB
Markdown
|
# Отчет по лабораторной работе №8
|
|||
|
|
|
|||
|
|
Выполнил студент гр. ИСЭбд-41 Миронов Е.О.
|
|||
|
|
|
|||
|
|
## Задачи
|
|||
|
|
|
|||
|
|
Написать небольшое эссе (буквально несколько абзацев) своими словами. А помогут Вам в этом вопросы из списка:
|
|||
|
|
1. Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
|
|||
|
|
2. Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
|
|||
|
|
3. Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
|
|||
|
|
4. Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
|
|||
|
|
5. Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
|
|||
|
|
|
|||
|
|
## Эссе
|
|||
|
|
|
|||
|
|
Сложные системы пишутся в микросервисной архитектуре для большей отказоустойчивости. Также это позволяет не повторять существующий код а решить проблему всего 1 раз и вынести в отдельный сервис, что соответствует принципу DRY и еще куче архитектурных паттернов. Микросервисная архитектура - это решение в котором есть свои плюсы и минусы, и далеко не каждому приложению подойдет такая архитектура. Я пока что считаю, что проще развернуть несколько экземлпяров монолита (возможно с несколькими обособленными сервисами), чем уходить в микросервисы, но это скорее всего потому что я еще не сталкивался с проектом которому действительно нужна микросервисная архитектура.
|
|||
|
|
|
|||
|
|
Системы оркестрации приложений позволяет гибко управлять набором существующих контейнеров. Они позволяют вынести настройки группы контейнеров в отдельный конфигурационный файл. Системы оркестрации приложений помогают более быстро минимизировать количество однотипной работы при разворачивании контейнеров(имею ввиду создание образа, запуск и т. д.)
|
|||
|
|
|
|||
|
|
Очереди обработки сообщений нужны для создания асинхронного API и ослабления связи между экземплярами сервисов. Мы посылаем сообщение брокеру и не заботимся о его доставке получателям, мы в принципе не знаем кто наши получатели. И наоборот получателей не волнует кто отправил сообщение, они знают только очередь из которой они его получили.
|
|||
|
|
|
|||
|
|
Плюсы микросервисов - высокая отказоустойчивость, быстрое развертывание (хотя конечно зависит от реализации).
|
|||
|
|
Минусы - задержки при передаче по сети, также любая передача по сети - лишняя угроза безопасности, сложность проектирования и разработки, сложность мониторинга системы.
|
|||
|
|
|
|||
|
|
Распределенная система и параллельные вычисления - несвязанные понятия. Нам по большинству без разницы куда внедрять параллельность, в микросервисы или в монолит. Могу только представить ситуацию, когда два каких-то микросервиса физически размещены на одной машине, и при одновременных параллельных вычислениях будут мешать друг другу в борьбе за ресурсы процессора.
|
|||
|
|
Если рассматривать многопоточность отдельно, то она тоже не всегда применима. Если рассматривать ситуацию, когда процессор постоянно активен на большой процент своей мощности, то при параллельной обработке одних данных, у нас будут медленее обрабатываться другие данные. Это применимо когда нам нужно как можно быстрее обработать что-то, к примеру когда на запрос клиента выполняются долгие вычисления и мы стараемся быстрее дать ответ (вешать тяжелые вычисления на клиентский запрос без всяких ограничений очень плохо), а ресурсами на выполнение какого-то фонового job можно и немного пожертвовать, из-за чего он выполнится позже (хотя на практике все с точностью наоборот).
|
|||
|
|
При написании параллельных алгоритмов высок риск отхватить очень трудно находимую ошибку, поэтому лучше использовать параллельность там, где это действительно необходимо
|