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