aleikin_artem_lab_8 #229
15
.gitignore
vendored
Normal file
15
.gitignore
vendored
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
################################################################################
|
||||||
|
# Данный GITIGNORE-файл был автоматически создан Microsoft(R) Visual Studio.
|
||||||
|
################################################################################
|
||||||
|
|
||||||
|
/.vs
|
||||||
|
/aleikin_artem_lab_3
|
||||||
|
/aleikin_artem_lab_4
|
||||||
|
/aleikin_artem_lab_5/MultiplyMatrix
|
||||||
|
/aleikin_artem_lab_6/DerminantMatrix
|
||||||
|
/dozorova_alena_lab_2
|
||||||
|
/dozorova_alena_lab_3
|
||||||
|
/dozorova_alena_lab_3/PostService/obj/Debug/net6.0/.NETCoreApp,Version=v6.0.AssemblyAttributes.cs
|
||||||
|
/dozorova_alena_lab_4
|
||||||
|
/dozorova_alena_lab_5/ConsoleApp1/obj
|
||||||
|
/dozorova_alena_lab_6/ConsoleApp1/obj
|
29
aleikin_artem_lab_8/readme.md
Normal file
29
aleikin_artem_lab_8/readme.md
Normal file
@ -0,0 +1,29 @@
|
|||||||
|
# Лабораторная работа 8 - Про устройство распределенных систем
|
||||||
|
## ПИбд-42 || Алейкин Артем
|
||||||
|
|
||||||
|
### Ответы на вопросы
|
||||||
|
|
||||||
|
#### Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
|
||||||
|
В первую очередь это удобно, эффективно и безопасно. Например при распредленном стиле, взаимодействие между частями кода(по факту его разделили на микросервисы) сильно ослабляется, за счёт чего мы получаем модульность.
|
||||||
|
> Модульность сама по себе даёт множество преимуществ.
|
||||||
|
> > 1. Возможность нанимать совершенно разные команды сотрудников для разработки конкретных модулей. То есть каждый модуль(сервис) может развиваться и масштабироваться независимо от остальных.
|
||||||
|
> > 2. Дебагинг, отслеживание ошибок, контролирование кода всё это проще, ведь мы сразу понимаем в каком модуле приложения находится нерабочий код, чтобы оперативно назначить разработчика для исправления ошибок.
|
||||||
|
> > 3. Отказоустойчивость - в том же вконтакте может упасть, к примеру, сервис музыки, но это означает, что только он и будет нерабочим, в том время как остальные сервисы даже не знают об этом и продолжают работать в штатном режиме.
|
||||||
|
|
||||||
|
#### Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
|
||||||
|
Нужны они для возможности централизованного запуска и управления всеми сервисами приложения.
|
||||||
|
Так же они значительно упрощают разворачивание своего приложения на чужих машинах.
|
||||||
|
|
||||||
|
#### Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
|
||||||
|
Очереди обработки сообщений нужны для возможности реализации "общения" сервисов между собой.
|
||||||
|
Некоторые сервисы могут зависеть от результатов других сервисов, для этого нужно "уведомить" второй сервис, о том, что он должен что-то сделать.
|
||||||
|
А также очереди ответственны за сохранность переданных данных.
|
||||||
|
|
||||||
|
#### Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
|
||||||
|
Я думаю, что о преимуществах достаточно подробно расписал это в первом пункте, поэтому здесь будут упомянут лишь недостатки.
|
||||||
|
К недостаткам я могу отнести следующие факторы:
|
||||||
|
> 1. Ослабление централизованного контроля - имеется в виду, что каждый модуль(сервис) более суверенный и мы далеко не всегда можем знать (имеется в виду, если проект разрабатывается командой людей, а не одним человеком), что там происходит. Что-то вроде черного ящика - даём данные и забираем результат, а процесс получения результата нам неизвестен.
|
||||||
|
> 2. Увеличение сложности разработки проекта в целом - требуется больше времени на проектирование архитектуры приложения, появляются накладные расходы на написание кода прослоек между сервисами, так же стоит отметить сложность отлавливание распредленных ошибок.
|
||||||
|
|
||||||
|
#### Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
|
||||||
|
Параллельные вычисления целесообразны, когда задача требует обработки больших объёмов данных или сложных вычислений. Например, анализ пользовательской активности, обучение моделей машинного обучения или обработка видео выгодно распределять между узлами. Но если задача не требует высокой производительности и её легко решить последовательно, внедрение параллелизма может усложнить систему без ощутимой пользы.
|
Loading…
Reference in New Issue
Block a user