Просто о сложном – архитектура приложения простыми словами.

Цифровая революция бушует вокруг нас, и даже если вы не человек из IT-сферы, многие понятия так или иначе докатываются и до вас: блокчейн, контейнеры, ИИ, микросервисная архитектура.
Эти слова как «базворды» жужжат на каждом шагу, и сегодня я хочу рассказать об одном из них – что такое микросервисная архитектура на простом примере.

Слово микросервисная уже наталкивает на некую измельчённость и атомарность. И, наверное, кто-то уже задавался вопросом: раз есть микросервисная архитектура, а какая ещё бывает? Наносервисная? Макросервисная? Просто сервисная?
Начнём с того, что IT — это инженерная наука, а инженеры всегда направлены на создание конкретных изобретений, и чем серьёзнее изобретения, тем более сложными они становятся и в конечном итоге превращаются в систему.

Ещё в 60-х годах появилась теория решения изобретательских задач (ТРИЗ). Примечательным фактом является то, что теория эта родилась в СССР, что я лично считаю предметом для гордости. А всем инженерам (в том числе IT-специалистам) рекомендую с ней ознакомиться.

Так вот, согласно ТРИЗ, система может развиваться в 3-х направлениях:1. Линейно улучшаться и развиваться «вправо» — превращаясь в мощный монолит;2. Переходить в надсистему — становиться сервисом большой системы;3. Измельчаться — переходить на микроуровень.

ИТ-системы – такие же инженерные системы как системы водоснабжения, энергоснабжения, двигатель внутреннего сгорания и так далее.
А потому к ним применимы все те же законы и правила, описанные в ТРИЗ.

Микросервисная архитектура – это 3-й путь развития системы, дробление функционала на более мелкие и автономные части, которые сами по себе являются независимыми элементами и объединяются в систему с помощью вышестоящей логики.

1. Линейное развитие и совершенствование

Ярким примером линейного развития системы являются автомобили. Развиваясь не одно десятилетие, автомобили стали более экономичными, комфортными и безопасными. В них появились новые узлы и функции, такие как ABS, кондиционер, гидроусилитель руля и прочее. Но по своей сути они изменились мало — это всё ещё конструкция повозки, состоящей из 4 колёс, приводимых в движение двигателем внутреннего сгорания. Даже появление электромобилей принципиально ничего не меняет в конструкции: модифицируются только некоторые конструктивные элементы — двигатель, коробка передач.

А функция бензобака просто переносится в батарею.

2. Переход в надсистему

Переход в надстоящую систему в качестве модуля и прекращение самостоятельного развития. Порой самостоятельные функции системы по каким-то причинам (экономическим, эстетическим, конструктивным) проще перенести в виде модуля в другую, более крупную систему, чем развивать самостоятельно. В таком случае сначала такая система становится модулем более крупного образования, а затем мы и вовсе перестаём рассматривать её как самостоятельный элемент, а рассматриваем как функцию системы.

Яркий пример — MacBook. Так выглядит его «подкапотка»:

В MacBook уже нет привычных процессоров, дисков и оперативной памяти, которую можно легко заменить, вынув из соответствующего слота. Всё это представлено единой монолитной системой микросхем, распаянных на материнской плате (надсистеме) и выполняющих заданные им функции.

3. Измельчение системы

Пример реализации перехода на «микросервисный уровень» можно наблюдать на левой картинке, где представлен классический (или олимпийский) лук в разборе.

Каждая деталь лука представляет собой самостоятельный, отделяемый компонент и выполняет конкретную функцию.

Справа можно наблюдать реализацию той же функции — метание стрел — реализованную в монолитной системе.

Другим примером может служить человеческое общество. В древности для выживания нам требовалось знать очень много вещей об окружающем мире: что можно есть, а что нет; как лечить раны; как шить одежду; как строить дом и так далее.

С развитием технологий количество знаний и изобретений возросло настолько, что мы просто не в состоянии знать всё. Поэтому люди начинают специализироваться на определённых областях знаний и углубляют свои познания в этих областях.

Теперь есть врачи, строители, энергетики, сотрудники пищевой индустрии и так далее, и каждое направление деятельности, в свою очередь, делится на более мелкие специализации.

Далее я постараюсь на бытовых примерах рассказать, как работает та или иная архитектура, в чём её плюсы и минусы.

Итак, представим ситуацию: нам нужно сделать ремонт в квартире, и мы выбираем подходящего исполнителя.

Мы хотим получить конечный продукт — это сделанный в квартире ремонт. Для того чтобы достичь этой цели, нам нужно найти исполнителя, который выполнит для нас ряд функций: выравнивание пола, шпатлёвку стен, поклейку обоев и так далее.

Каждый исполнитель будет представлять собой тот или иной архитектурный паттерн, и на таких примерах я постараюсь рассказать, как будут распределяться и выполняться функции в каждом из паттернов.

Монолитная система

Обычно у нас нет строительного образования, опыта строительства и времени разбираться во всех деталях. Поэтому мы выбираем самый очевидный для нас вариант — «ремонт под ключ».

Таким образом, мы общаемся с одной точкой входа — бригадиром — и считаем, что в системе (бригаде) есть все необходимые навыки для выполнения работ.

С точки зрения бригады, чтобы выполнить ваш запрос — сделать ремонт любой сложности — она должна либо иметь всех специалистов под рукой, что обычно невозможно, либо повышать квалификацию небольшого количества членов бригады, каждый из которых начинает осваивать несколько специальностей.

И таким образом порой приходится жертвовать качеством отдельно взятых навыков, ведь сложно достичь совершенства во всём.

Постоянно получая новые запросы от клиентов и сталкиваясь с разными трудностями, бригада развивает в себе новые компетенции и работает над своей производительностью. Таким образом, бригада покрывает всё больше нужд клиентов и может выполнять всё больший объём работ, но и зависимость членов бригады друг от друга пропорционально возрастает. Если кто-то из членов бригады выпадет из процесса по причине болезни, отпуска или, скажем, увольнения, работа всей бригады будет парализована, а найти замену будет крайне трудно из-за большого количества функций, возложенных на этого исполнителя.

• Все функции сосредоточены в одном месте;
• Единая, общая база данных;
• Относительная простота проектирования и отслеживания изменений;
• Снижение стоимости владения за счёт использования единого технологического стэка.

• Высокая зависимость бизнеса от конкретного ИТ-актива;
• Низкая скорость развития и сложности тестирования;
• Сложность замены отдельных элементов системы;
• Сложность масштабирования.

Сервисная архитектура

Ситуация становится более сложной, когда вам говорят: «У нас нет нормального электрика, сантехника и т. д., мы можем сделать только часть работ, а вот на остальные вам нужно искать кого-то ещё». Это может произойти, если вы решите снизить зависимость от одного исполнителя и нанимаете несколько команд. Например, в силу того, что я писал выше - чем универсальнее работник, тем хуже его навыки в какой-то определённой области.

В результате вы получаете несколько бригад, каждая из которых выполняет только свой определённый блок функций (сервис). Теперь у вас сервисная архитектура. Ваша зависимость от одной бригады снижается, и вам проще выполнять замену бригады, стремясь получить лучшее качество, стоимость или время исполнения.

Однако теперь вам приходится искать нужных людей, согласовывать план работ, решать конфликты, управлять логистикой и другими процессами. Возникает потребность в функции координации, которую обычно называют оркестрацией.

Функция оркестрации присутствует и в монолите, но за счёт его многофункциональности, сосредоточенной в одном месте, она не так явно бросается в глаза. Монолит не скажет вам: «Я только плитку кладу, а вот кто и когда будет клеить обои, я не знаю».

А вот при работе с разными сервисами так не получится. Скорее всего, вы услышите: «Когда закончите черновые работы — позвоните, если будем свободны, обои поклеим». Бригада, которая фокусируется на небольшой области деятельности, тоже выигрывает, так как может сосредоточиться на конкретных навыках, довести их до совершенства. Если все плюс-минус умеют одно и то же, то потеря члена команды не будет фатальной, хотя порой и придётся отказывать клиентам в выполнении заказа. Или можно попробовать найти доверенных партнёров на профильную деятельность.

• Повышение уровня независимости элементов системы друг от друга, снижение сложности замены элементов;
• Повышение отказоустойчивости системы в целом;
• Возможность предъявлять разные требования к элементам системы;
• Повышение гибкости развития системы;
• Повышение прозрачности бизнес-процессов.

• Усложнение проектирования архитектуры системы;
• Рост требований по производительности к сетевой инфраструктуре;
• Повышение уровня угроз по информационной безопасности.

Микросервиса архитектура

Крайне редко в жизни мы можем столкнуться с ситуацией, когда бригада, специализирующаяся на конкретном сервисе, например, на сантехнике, говорит вам: «Установкой душевых кабин мы не занимаемся, ищите другого специалиста». Это не выдуманная ситуация, а реальная история, случившаяся со мной.

В таком случае сервис «установка сантехники» начинает дробиться на более мелкие работы:

• установить смеситель;
• установить душевую кабину;
• установить систему контроля протечек;
• и так далее.

Вот вы и перешли от уровня сервисной (крупноблочной архитектуры) к микросервисной.

Микросервисы могут в свою очередь измельчаться почти до бесконечности. Например, рабочий может только устанавливать раковины, но не монтировать краны, для монтажа крана нужно будет привлечь другого специалиста.

В таком случае зависимость от каждого конкретного специалиста падает ещё больше. Если в сервисной архитектуре вы могли остаться без воды совсем, то в этом случае вам могут только не установить смеситель или раковину. И если рынок таких специалистов огромный, найти подходящего не составит проблем.

При этом сложность оркестрации возрастает в разы, если раньше вам нужно было контролировать только потоки работ (сервисы) — готовность сантехники, электрики, чистовая отделка, уборка и так далее. То в микросервисных архитектурах контролировать и управлять придётся уже каждым действием — принять установку раковины, затем смесителя, затем душевой кабины, затем зеркала и так далее.

Микросервисы требуют микроменеджмента. Ваш оркестратор должен становиться всё умнее и сложнее в настройке, он должен понимать, какие сервисы нужно вызывать в чёткой последовательности, а какие могут быть вызваны произвольно в любой момент, например сервис уборки. Вы можете вызывать уборщицу после каждой операции, что не очень оптимально, но не сломает процесс. А вдруг у вас просто пунктик на чистоте и вы готовы за это платить.

А вот если вы сначала установите раковину, а потом решите подвести к ней воду — вас ждёт крайне неприятный сюрприз с цепочкой откатов операций, повторным выполнением и потраченными зря ресурсами.

Таким образом, с одной стороны, растёт атомарность и заменимость каждого элемента архитектуры на нижнем уровне, при этом растёт сложность координации и управления на верхнем уровне.

• Высокий уровень атомарности элементов архитектуры;
• Простота масштабирования;
• Малое влияние каждого элемента на систему;
• Лёгкость замены каждого элемента.

• Дорогостоящая система оркестрации верхнего уровня;
• Сложно отслеживать сквозной процесс;
• Сложность проектирования архитектуры.

В заключение хочется сказать, что нет хороших или плохих архитектур. У каждой архитектуры есть свои плюсы и минусы, и самое главное — есть контекстные условия, исходя из которых и стоит выбирать нужный тип архитектуры.

Не поддавайтесь хайпу и красивым словам, подвергайте любые решения здравому скепсису, задавайте уточняющие вопросы, «пробуйте решения на зуб», предлагая реальные ситуации из бизнеса, и уточняйте, чем то или иное решение будет лучше или хуже в этих ситуациях.

Надеюсь, эта небольшая статья далась вам легко и помогла лучше разобраться в вопросе выбора архитектуры для IT-решений.