Добавить README.md
This commit is contained in:
parent
f956ac4f0e
commit
a3a7c8bf71
62
README.md
Normal file
62
README.md
Normal file
@ -0,0 +1,62 @@
|
||||
1. Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение
|
||||
(или сервис) функционально выполняет только ограниченный спектр задач?
|
||||
|
||||
Их пишут в таком стиле, чтобы если один из серверов "упадет", то другие смогут поддерживать работу приложения. Таким образом, если бы
|
||||
ВКонтакте писался на монолите, то все приложение со всеми функциями не было бы доступно. В случае же с распределенным, какой-то отдельный
|
||||
функционал или мини-приложение может не работать, но это не так глобально и не так ощущается пользователями, как если бы приложение
|
||||
не работало целиком. Такие системы отказоустойчивы, а также более надежны и производительны.
|
||||
|
||||
2. Для чего были созданы системы оркестрации приложений?
|
||||
Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
|
||||
|
||||
Оркестрация - автоматическое размещение, координация и управление сложными компьютерными системами и службами. Условно, определяют систему
|
||||
в контейнеры и управляет ими, отслеживает, как они работают, управляет жизненным циклом контейнеров.
|
||||
|
||||
Они были созданы для автоматизации процессов, управления инфраструктурой и масштабируемости.
|
||||
|
||||
Упрощают развертывание и обновление приложений, помогают отслеживать зависимость между сервисами и обеспечивают их корректное взаимодействие.
|
||||
|
||||
Усложняют из-за сложности настройки и постепенного увеличения числа компонентов.
|
||||
|
||||
3. Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
|
||||
|
||||
Очереди обработки сообщений — это важный компонент архитектуры распределенных систем, который обеспечивает асинхронную и надежную передачу
|
||||
данных между различными компонентами или сервисами.
|
||||
|
||||
Очереди поддерживают асинхронность, то есть возможность работы компонентов независимо друг от друга, что значит, что один компонент может
|
||||
отправить сообщение в очередь и продолжить свою работу, не дожидаясь его обработки.
|
||||
|
||||
Надежность - использование очередей уменьшают вероятность потери сообщений.
|
||||
|
||||
Также очереди помогают распределять нагрузку между приложениями.
|
||||
|
||||
Под сообщениями могут подразумеваться:
|
||||
События: Информация о том, что произошло в системе. Например, "пользователь зарегистрировался", "заказ был размещен", "файл был загружен".
|
||||
|
||||
Команды: Указания другим компонентам системы выполнить какие-то действия, например, "обработать платеж", "выполнить задачу" или "отправить уведомление".
|
||||
|
||||
Данные: Конкретные данные, которые необходимо передать, например, JSON-объект с информацией о заказе или текст сообщения.
|
||||
|
||||
Запросы: Запросы на получение информации или выполнения определенных операций, которые могут быть обработаны позже.
|
||||
|
||||
Ошибки или уведомления: Информация о проблемах или событиях, требующих внимания, например, "не удалось записать данные в базу" или "недостаточно прав".
|
||||
|
||||
4. Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
|
||||
|
||||
Преимущества заключаются в масштабируемости, отказоустойчивости и производительности. Также важную роль играет гибкость - можно разрабатывать
|
||||
и тестировать компоненты независимо друг от друга. Из этого также следует разделение ответственности - отдельные компоненты отвечают за
|
||||
конкретные задачи.
|
||||
|
||||
К недостаткам я бы отнесла сложность разработки, меньшую степень безопасности, а также проблемы с сетью. Из-за того, что компоненты разделены
|
||||
по разным узлам, это может привести к задержкам в работе. Касательно безопасности, распределенные системы больше подвержены атакам из-за
|
||||
большого количества узлов.
|
||||
|
||||
|
||||
5. Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления?
|
||||
Приведите примеры, когда это действительно нужно, а когда нет.
|
||||
|
||||
Это нужно, когда существует необходимость в обработке больших данных, в научных вычислениях, сложных вычислительных задачах и
|
||||
обработке событий в реальном времени.
|
||||
|
||||
Это нецелесообразно внедрять в систему, когда существуют сложные алгоритмы с последовательной логикой или частыми взаимодействиями,
|
||||
а также когда речь идет о небольших и простых в вычислении задач.
|
Loading…
Reference in New Issue
Block a user