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

Как устроены микросервисы? 

Чтобы понять насколько микросервисы сложны, приведем такой пример. К примеру, у вас есть программа Word и вам нужно ее запустить. Как вы это делаете? У вас есть всего один exe-файл, который вы нажимаете, и программа запускается. То есть Word - это монолит, который скомпилирован в один исполняемый файл, который очень легко запустить и с которым очень легко работать.

Если бы Word был бы написан как микросервисы, у нас было бы 20 exe-файлов. И нужно было бы их запускать в правильном порядке. То есть, необходимо сначала запустить Word интерфейс пользователя, потом Word обработка ошибок ввода текста, потом Word обработка изображений, потом Word обработка стилей. И только тогда со временем, возможно, запустится вся система. Деплой системы из-за микросервисов становится невероятно сложным процессом. Из-за этого даже появилась отдельная профессия - Devops. То есть благодаря тому, что программисты заранее решили, что микросервис — это хорошая идея, они сами говорят, мы не хотим заниматься деплоем этой системы, поэтому пусть кто-то другой за нас этим займется. Но обычно даже Devops потом не справляются с этой задачей. Все равно возникают постоянно какие-то проблемы, шероховатости, связанные с деплоем. И ни Docker, ни Kubernetes ничего не поможет, если неправильно разбить систему на компоненты.

Netflix

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

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

Атрибуты в IT-архитектуре

Давайте обратимся к атрибутам, которые существуют в архитектуре и заставляют нас объединять код в единое место. Это три атрибута:

• Общие функции (модуль делает что-то одно)
• Общие причины для изменения
• Общий релиз

И эти атрибуты в какой-то степени противоречат друг другу. То есть если мы стремимся к тому, чтобы следовать одному атрибуту, мы как бы жертвуем двумя остальными.

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

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

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

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

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

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

Каждый из этих атрибутов дает свои преимущества для программистов. Первый атрибут упрощает удобство релиза компонентов. Второй атрибут упрощает удобство разработки. А третий, он делает проще удобство последующего использования компонента. И вот в начале разработки, самый главный атрибут – это второй - удобство разработки. Это тот атрибут, который заставит компонент быть большим.

Противоречия атрибутов

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

Обратимся к диаграмме противоречий

Зеленая точка - это место, в котором находится компонент. Когда программисты принимают решение о том, что они должны быть маленькими, то все свое внимание отдают нижнему принципу - CRP Разделение для устранения лишних выпусков. Другими принципами приходится жертвовать. Но REP Объединение для удобства пользователей и CCP Объединение для удобства сопровождения - эти атрибуты затрагивают слишком большое количество компонентов и усложняется повторное использование. На стадии начала проекта - это очень плохо. На этом этапе, наоборот, компонент должен быть большой, а во главу угла поставлено удобство разработки. К примеру, если есть варианты использования администратора, они все должны находиться в одном компоненте, даже если они выполняют разные функции для системы.

Вернемся к диаграмме противоречий. Лишь спустя время фокус в проекте начинает постепенно смещаться в левую часть - Объединение для удобства пользователей. Когда проект уже большой, в нем уже много компонентов, когда мы его, возможно, интегрируем в другие системы, этим проектом начинают пользоваться другие программные системы, в этот момент мы уходим влево. Но, возможно, нам всё равно иногда приходится уходить и вниз, то есть сделать компоненты поменьше по размеру.

Программист IT-компании ICONICA Андрей Петрица:

Для понимания, насколько сложно работать с архитектурой, приведу пример из своей практики. Когда-то я работал на проекте, это была шведская финансовая биржа. Мы использовали на работе очень большой компонент. Он назывался Symfony. Это был фреймворк, который делал всё для нашего проекта. Мы были полностью на нем связаны. В чем была проблема? Symfony был очень большой по размеру, и у него была маленькая часть, которой мы пользовались. Она называлась авторизацией. Когда мы обновили версию Symfony, у нас сломалась авторизация на всем проекте. А все потому, что мы использовали только маленькую часть от этого компонента. То есть, по сути, мы использовали маленькую часть, но зависели от всего компонента сразу, поэтому у нас такая проблема и случилась.

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

Поэтому хорошо было бы в этом компоненте, то есть нашего проекта, сделать инверсию зависимости: 

Блок Authorizer можно сделать совсем маленьким, поскольку мы в нем используем только маленькую часть нашего фреймворка. Symfony его реализует, и потом мы можем при необходимости заменить Symfony на любой другой компонент. И теперь, если авторизация не работает, она нас не устраивает, мы можем легко использовать другую авторизацию. Даже можем ее сами написать, потому что там она была совсем маленькая, не было никакой необходимости ее так сильно усложнять, используя такой огромный комбайн, как Symfony. Потребность делать компоненты маленькими, она есть, но это наименее приоритетный атрибут.

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

Микросервисы – это всего лишь стратегия деплоя, и они никак не влияют на архитектуру. Если это монолит, тогда что происходит? Просто функции нашей программы они все выполняются в одном адресном пространстве. Если это микросервисы, то просто есть ряд функций, которые выполняются на отдельном процессоре и получают данные по интернету. И это решение никак не влияет на архитектуру. Это всего лишь решение, которое нужно принимать в определенных ситуациях.