Микросервисы глазами аналитика

Расскажу про системы с микросервисной архитектурой (MSA). Как они устроены, как я их анализировала, какие увидела проблемы и преимущества.

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

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

1. Что такое система с MSA

"Микросервисная архитектура - это стиль проектирования, который разбивает приложение на отдельные сервисы с разными функциями. <...> В микросервисной архитектуре единицей модульности являются сервисы. Сервисы обладают API, которые служат непроницаемым барьером." К. Ричардсон "Микросервисы. Паттерны разработки и рефакторинга"

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

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

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

1.1. Выявление микросервисов

Вы спросите меня, что такое микросервисы? Я отвечу, что это, как правило, небольшие сервисы.

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

Самый сложный, вероятно, вопрос: как выделять микросервисы? Правильного ответа или алгоритма для этого нет. Все зависит от домена и того, какие проблемы вы решаете.

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

Давайте рассмотрим на примере способ декомпозиции по поддомену.

Этот подход основан на domain-driven design (DDD). То есть необходимо выявить поддомены системы, у каждого из которых своя доменная модель. Далее поддомены конвертируются в микросервисы.

Допустим, мы делаем систему для заказа продуктов в небольшом магазине рядом с домом. У нас есть пользовательские истории:

• заказа (order);

• оплаты (payment);

• доставки товара (delivery).

Для обеспечения этих процессов необходимо где-то хранить информацию о наличии и количестве продуктов (stock). А также вести финансовый и бухгалтерский учет всех операций (accounting).

Опираясь на доменную модель, мы можем выделить следующие микросервисы:

• Orders - для сбора, хранения и обработки заказов;

• Payment - для проведения продаж;

• Delivery - для хранения информации о передаче в доставку (этот сервис будет взаимодействовать с внешней системой службы доставки);

• Stock - для хранения информации об остатках товаров в магазине и их характеристиках;

• Accounting - для хранения бухгалтерских и учетных данных (возможно это просто адаптер для нашей 1С).

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

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

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

1.2. Микросервисы и бизнес-процессы

Бизнес-процессы в системе с MSA обычно проходят через несколько микросервисов.

Вернемся к нашему примеру заказа товаров через интернет. С учетом выявленных микросервисов процесс будет примерно таким:

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

Но что происходит, когда в системе работает сразу несколько бизнес-процессов?

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

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

Например, мы можем в системе для заказа товаров через интернет также проводить процесс продажи товаров непосредственно в магазине. В новом процессе сервис Stock появляется только после оплаты. В отличие от заказа через интернет, где есть предварительная проверка наличия товара.

Для ускорения и упрощения реализации бизнес-процессов в MSA иногда создают отдельные управляющие микросервисы и/или используют инструменты автоматизации.

1.2.1. Управляющие микросервисы

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

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

Так, для обработки продажи товара в магазине можно создать управляющий микросервис Processes. Он сначала вызовет MS Payment для проведения оплаты, затем MS Stock для изменения остатков товара и MS Accounting для фиксации финансовых операций в отчетности.

1.2.2. Платформы BPM

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

Вернемся к нашему примеру продажи в магазине:

При реализации этого процесса через Camunda необходимо сделать его BPMN-схему (например, в Camunda Modeler):

Каждый прямоугольник на схеме ссылается на код с логикой:

1. Payment Process - проведение оплаты вызовом MS Payment.

   1. Error Message - если оплата не состоялась по какой-то причине, то происходит отправка сообщения об ошибке и завершение процесса.

2. Change Stock - изменение количества товара в MS Stock.

3. Change Accounting - обновление фин. отчетности в MS Accounting.

При инициации продажи MS Processes запустит этот процесс и Camunda выполнит каждый этап в заданной последовательности.

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

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

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

1.3. Интеграции

Как вы, наверное, уже догадались, система с MSA - это тот еще Вавилон, где интегрируются все со всеми любыми мыслимыми способами.

Помимо своей базы данных у каждого микросервиса еще и свой API, любого протокола и вероисповедания. Вот он, век индивидуализации, во всей своей красе.

1.3.1. Взаимодействие между микросервисами

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

Обычно архитекторы отдают предпочтение REST+JSON/GraphQL/gRPC и обмену сообщениями с помощью брокера типа Kafka и MQ Rabbit. Итоговый выбор инструментов зависит от требований и возможностей команды.

Рассмотрим возможную последовательность вызовов для реализации процесса продажи товара в магазине из нашего примера:

MS Processes вызывает MS Payment для инициации оплаты и ждет от него обратную связь, чтобы продолжить свою работу. После получения ответа, происходит аналогичный синхронный вызов к MS Stock для списания товаров. Далее в сообщении для брокера уходит информация для MS Accounting, реализуя асинхронное взаимодействие. И MS Processes завершает свою работу, совершенно не беспокоясь, получил MS Accounting данные о покупке или нет.

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

Но в любом случае всегда надо продумывать сценарии-"предохранители": то есть писать отдельный код на случай отказа каждого звена в процессе.

1.3.2. Интеграции с другими сервисами

Внешние сервисы, если им повезет, взаимодействуют с MSA-системой через API-шлюзы.

По К. Ричардсону API-шлюзы занимаются:

• объединением API для запросов к нескольким микросервисам;

• распределением запросов по нужным микросервисам;

• преобразованием разных протоколов интеграций (как микросервисов, так и внешних систем);

• реализацией граничных функций вроде аутентификации.

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

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

Как правило внешним системам шлюз предоставляет REST+JSON API, так как в нему все привыкли и считают простым для интеграции. Но можно использовать и GraphQL, который позволяет клиенту указывать в запросе, какие именно данные нужно вернуть. Этот подход помогает при работе с несколькими клиентами, у каждого из которых свои цели и пристрастия.

Можно использовать и другие инструменты для разработки API-шлюзов, можно вообще взять готовый продукт, например AWS API Gateway. Главное - не забыть договориться со всеми потребителями нашего API.

1.4. Отчеты и мониторинг

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

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

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

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

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

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

2. Что происходит с аналитиком

ыЕсли коротко, то аналитик на проектах с MSA устраняет неопределенность. Впрочем, как и везде.

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

То есть здесь кому-то очень важно уметь:

• приводить хаос в порядок;

• выявлять требования;

• проектировать интеграцию;

• понимать ключевые и потенциально опасные части процессов;

• контролировать знания команды о системе;

• доносить до бизнеса возможности и ограничения продукта.

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

2.1. Процесс разработки системы с MSA

Часто команды выделяются на продукт или продуктовое направление.

В нашем примере могло бы быть такое разделение:

• Команда А - разрабатывает все, что связано с процессом оффлайн продаж в магазине.

• Команда Б - делает процесс онлайн-продаж и все соответсвующие задачи.

Микросервисы Payment, Stock и Accounting используются в обоих процессах.

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

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

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

2.2. Задачи аналитика

Для адекватного анализа необходимо знать все, что как-либо затрагивает или может затронуть твой продукт. То есть аналитикам на проектах с MSA необходимо понимать:

• свой продуктовый процесс;

• логику работы всех задействованных в продукте микросервисов и механизмы их взаимодействий;

• процессы продуктов, которые используют те же микросервисы;

• внешние интеграции, их механизм и логику.

Рассмотрим пример, когда надо добавить в метод создания заказа новое поле discount. В этом поле содержится размер скидки, которую интернет-магазин предоставил покупателю.

Для реализации этого небольшого изменения необходимо:

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

2. Добавить поле в API-шлюзе для внешних систем.

3. Добавить поле в API MS Order, его логику и, возможно, БД.

4. Понять, необходимо ли передавать новое поле в MS Payment. Или достаточно изменить логику расчета цены товара при передаче данных о заказе.

5. Обновить публикуемые сообщения, связанные с созданием заказа. Определить, какие еще сервисы должны быть оповещены о предоставлении скидки через брокер сообщений (например, MS Accounting).

6. Добавить в MS Accounting новое поле и логику его обработки.

7. Продумать, что делать, если на любом из этапов случится сбой (транзакций на весь процесс нет в силу разных БД у микросервисов).

8. Узнать, как этот показатель должен отражаться в бизнес-отчетах и добавить его в DWH/BI (если повезет, через специально обученных людей).

Бизнес-требования и функционал системы определяют, в каких микросервисах, API и БД должны появиться поле и логика его обработки. То есть разработчик с этим не подскажет. А для заказчика это будет "вам нужно всего лишь добавить одно поле".

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

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

2.3. Возможные проблемы

Обозначу основные проблемы, с которыми довелось столкнуться, в порядке убывания бесячести.

2.3.1. Ничего не понятно

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

Но в отличие от проводов, с микросервисами часто еще и не понятно, как их вообще распутывать.

Можно читать код. И мы, например, поймем, что нотификация отправляется при условии comission= true. А почему так происходит - не узнаем. И тем более не узнаем, что где-то в другом конце системы при comission= false отправляется другая нотификация.

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

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

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

2.3.2. "Чужие" доработки

Это когда ничего не понятно, а потом раз - и становится еще непонятнее. Потому что другая команда что-то сделала в общем микросервисе. Другая команда молодец. А у вас что-то сломалось или не работает новый функционал, который, судя по документации, должен бы работать.

Решение видится в совокупности факторов:

• повсеместное покрытие автотестами, что и так обязательно для MSA;

• документирование всех изменений в едином пространстве ДО реализации (например, писать новые требования на общей странице и выделять их тегами со ссылкой на задачу, где эти требования будут реализованы);

• обязательный этап анализа - проверка влияния доработки на другие процессы;

• очень дружная и активная коммуникацией аналитиков.

Документирование в таких объемах само по себе может стать проблемой, поэтому стоит посмотреть в сторону автоматизации. Так вы не будете тратить время хотя бы на таблички с API и БД. Но для этого придется поуговаривать разработчиков прикрутить какой-нибудь swagger2markup и выгрузку актуальных полей БД.

Ну или можно строго придерживаться правила "один микросервис - одна команда".

2.3.3. Заказчику сложно

Бизнес ничего не понимает сильнее, чем обычно. Откуда такие сроки, почему все сломалось, зачем вам этот GraphQL?

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

А еще производительность команды на микросервисах зависит от большого количества факторов. Да и задачи могу быть на самом деле не тем, чем кажутся. Тут уже аналитику надо придумать, как все эти сложности доступно объяснить. Можно попробовать пример с гномиками, как у Максима Цепкова. Или показать на простом примере вроде добавления поля discount. И, опять же, если будут схемы и описания, можно просто тыкать пальцем - где и что вам нужно в итоге сделать для реализации этой "быстрой" доработки.

2.3.4. Требуется много знаний

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

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

Помимо знаний о самой MSA, нужно быть готовым разобраться в принципах REST, брокеров сообщений и любом способе интеграции, который придет в голову вашему архитектору.

Возможно вас также затронут JWT, инстансы, балансировка, развертывание, анализ производительности, доступности и другие сложные слова.

Ну и совершенно не лишним будет стандартный набор аналитика из работы с требованиями, моделирования, написания понятной документации, БД и SQL и проектирования интеграций.

Очень рекомендую книгу Ричардсона "Микросервисы. Паттерны разработки и рефакторинга" - там про все понемногу и очень понятно объясняется.

2.4. Плюсы MSA для аналитика

Несмотря на все проблемы и сложности, работать с микросервисами мне понравилось. И вот почему:

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

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

3. Если вы знаете свои процессы, то скорее всего быстро сможете определить, в каком микросервисе у вас сбоит при ошибке. И так как микросервисы относительно простые - то исправить тоже будет несложно (наверное). И при обновлении можно выкатить только свой микросервис, не беспокоя соседей.

4. Скорее всего вы будете работать с профессионалами. Микросервисная архитектура создает вызовы для аналитиков, разработчиков, QA, DevOps и даже менеджеров. То есть все члены команды должны обладать определенным опытом и навыками для нормальной реализации этого подхода.

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

6. В системах с микросервисами аналитик бОльшую часть времени занимается именно анализом. На "неаналитические" задачи попросту не остается ресурса. Здесь аналитик по полной реализует свои профильные hard и soft скиллы.

Итог

Микросервисная архитектура - это много разных технологий, интеграций и возможностей для развития как систем, так и людей.

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

Все это вполне постижимо и действительно интересно, хоть поначалу и не совсем прозрачно.

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