Alexey/DAS_2024_1
2
7
Fork 1
Code Issues Pull Requests 101 Actions Packages Projects Releases Wiki Activity

minhasapov_ruslan_lab_8

Browse Source
This commit is contained in:
Safgerd 2024-11-18 07:35:52 +04:00
parent 3b9698ac38
commit 729994bd69
1 changed files with 18 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
minhasapov_ruslan_lab_8/README.md Normal file
View File

@ -0,0 +1,18 @@
# Лабораторная работа №8
#### ПИбд-42. Минхасапов Руслан
---
#### Эссе
Представим огромный завод, который выпускает "сложный" продукт. Вместо того, чтобы абсолютно все делать в одном цехе, производство делят на отдельные части, например, где делают заготовки, собирают, красят и т.д. Каждая часть сфокусирована на чем то своем, что повышает эффективность и делает управление проще. По такому же приципу строятся и распределенные системы, как, например, социальная сеть. Вместо одного монолита, весь функционал разбивается на отдельные сервисы - авторизация, лента с новостями, мессенджер и т.д., что упрощает разработку, масштабирование и тестирование, так как прктически каждый сервис можно изменять и развивать независимо. Трудно представить, как Вконтакте смог бы обслуживать миллионы пользователейс одним гигантским приложением...
С увеличением количества сервисов, появляется проблема - как развернуть, мониторить и масштабировать "миллионы" отдельных приложений? Для ее решения и были созданы системы оркестрации. Они делают все, что нам необходимо: автоматизируют управление жизненным циклом, упрощают развертывание, масштабирование, а также обновление самих сервисов. На самом деле - оркестрация, хоть, с одной стороны, упрощает экспулатацию сложной системы, но и добавляет новый уровень абстракции, который тоже нужно понимать и поддерживать... К счастью, небольшие проекты могут обойтись и без оркестрации!
Чаще всего для взаимодействия между сервисами используют сообщения. Сервисы обмениваются сообщениями, которые могут представлять собой практически что угодно - запросы, уведомления, данные и т.д. Очедери действуют как буфер и "развязывают" сервисы друг от друга, это повышает надежность и позволяет сервисам работать асинхронно, даже если один из них... "упал" (временно недступен).
Хотя распределенные системы масштабируемы, отказоустойчивы и позволяют разделить работу между командами разработчиков, но и они имеют свои недостатки. Распределенные системы куда сложнее в разработке и отладке, нежели монолитные приложения.
Распределенные системы масштабируемы, отказоустойчивы и позволяют разделять работу между разными командами. Но у них есть и недостатки. Они сложнее в разработке и отладке, чем монолитные приложения. Например, если один сервис обновил информацию, а другой еще не получил обновление, то возникает несогласованность данных. Как пример, вспомним Вконтакте, допустим, мы изменили свою аватарку, но на некоторых страницах до сих пор отображается старая фотография, это и есть проблема консистентности. Также, общение между сервисами по сети занимает время, что приводит к задержкам в работе приложения.
Затрагивая тему параллельных вычислений, то их целесообразно использовать внутри отдельных сервисов, когда требуется выполнить ресурсоемкую задачу, например обработка изображения или машинное обучение. Однако не всегда стоит распараллеливать все и вся. Если задача простая, то накладные расходы на организацию параллелизма могут превысить выгоду от ускорения, что можно было увидеть в последних лабораторных работах. Приводя пример, можно рассмотреть обработку простого текстого запроса или транзакции в банковской системе, тут нет необходимости в распараллеливании, так как это может нарушить целостность данных.