Расскажу про системы с микросервисной архитектурой (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):
Каждый прямоугольник на схеме ссылается на код с логикой:
Payment Process - проведение оплаты вызовом MS Payment.
Error Message - если оплата не состоялась по какой-то причине, то происходит отправка сообщения об ошибке и завершение процесса.
Change Stock - изменение количества товара в MS Stock.
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. В этом поле содержится размер скидки, которую интернет-магазин предоставил покупателю.
Для реализации этого небольшого изменения необходимо:
Понять, есть ли в системе подобное поле для скидок, которые предоставляет наш магазин. Если есть, то проработать их взаимодействие и исключить путаницу.
Добавить поле в API-шлюзе для внешних систем.
Добавить поле в API MS Order, его логику и, возможно, БД.
Понять, необходимо ли передавать новое поле в MS Payment. Или достаточно изменить логику расчета цены товара при передаче данных о заказе.
Обновить публикуемые сообщения, связанные с созданием заказа. Определить, какие еще сервисы должны быть оповещены о предоставлении скидки через брокер сообщений (например, MS Accounting).
Добавить в MS Accounting новое поле и логику его обработки.
Продумать, что делать, если на любом из этапов случится сбой (транзакций на весь процесс нет в силу разных БД у микросервисов).
Узнать, как этот показатель должен отражаться в бизнес-отчетах и добавить его в 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 для аналитика
Несмотря на все проблемы и сложности, работать с микросервисами мне понравилось. И вот почему:
Во-первых, это интересно. Это как большой конструктор, из которого можно собирать разные процессы. Менять кубики местами и переворачивать нужными гранями для разных плоскостей. Если нравятся интеграции и копаться в технических аспектах - то вы по адресу.
Относительно легко добавлять новые продукты и функции. Для этого пишут новые микросервисы и не нужно беспокоиться о том, что новый код как-то сломает работающие процессы. И даже если вы правите уже работающие микросервисы, то отследить зависимости и влияние проще, чем в монолите.
Если вы знаете свои процессы, то скорее всего быстро сможете определить, в каком микросервисе у вас сбоит при ошибке. И так как микросервисы относительно простые - то исправить тоже будет несложно (наверное). И при обновлении можно выкатить только свой микросервис, не беспокоя соседей.
Скорее всего вы будете работать с профессионалами. Микросервисная архитектура создает вызовы для аналитиков, разработчиков, QA, DevOps и даже менеджеров. То есть все члены команды должны обладать определенным опытом и навыками для нормальной реализации этого подхода.
Как писала выше, работа с MSA - это возможность узнать много нового и поработать с разными технологиями. А значит и развиваться в любимом деле, вырасти как специалист и открыть для себя новые карьерные перспективы.
В системах с микросервисами аналитик бОльшую часть времени занимается именно анализом. На "неаналитические" задачи попросту не остается ресурса. Здесь аналитик по полной реализует свои профильные hard и soft скиллы.
Итог
Микросервисная архитектура - это много разных технологий, интеграций и возможностей для развития как систем, так и людей.
Работа на проекте с MSA подразумевает особый подход, определенные навыки и знания. Нужно разобраться в деталях процессов и технологий. Возможно, изучить что-то или придумать новую схему работы, взаимодействия с заказчиком и коллегами.
Все это вполне постижимо и действительно интересно, хоть поначалу и не совсем прозрачно.
Надеюсь, после этой статьи кому-то станет немного понятнее, что может скрываться за этими загадочными словами в вакансиях. И к чему готовиться, если у вашего техлида внезапно улучшилось настроение и загорелись глаза.
