Что такое микро сервисная архитектура
Что такое микросервисы: особенности архитектуры, примеры использования, инструменты
Авторизуйтесь
Что такое микросервисы: особенности архитектуры, примеры использования, инструменты
Архитектурный стиль микросервисов — это подход, при котором система строится как набор независимых и слабосвязанных сервисов, которые можно создавать, используя различные языки программирования и технологии хранения данных. Концепция микросервисов позволяет поддерживать слабую связанность сервисов в процессе работы над системой, что определяют паттерны Low Coupling и High Cohesion.
Подробности — в видео и текстовой расшифровке ниже.
Монолит vs микросервисы
При монолитной архитектуре система обычно состоит из 3 блоков: пользовательский интерфейс, хранилище данных и серверная часть. Серверная часть обрабатывает запросы, выполняет бизнес-логику, работает с БД, заполняет HTML-страницы. Любое изменение в системе приводит к обновлению версии серверной части приложения.
В случае с микросервисной архитектурой обновляется только изменённый сервис. Если изменения затрагивают интерфейс сервиса, это потребует координации всех его клиентов. Цель хорошей микросервисной архитектуры — максимально уменьшить необходимость координации сервисов.
Что такое контракт
Контракт — это формализация возможностей взаимодействия с микросервисом. В случае с REST API эндпоинты сервиса и схема данных являются контрактом. Первоначальная разработка архитектуры — это декомпозиция системы на слабосвязанные сервисы, создание интерфейсов и связей между ними, поддержка целостности данных без потери производительности. Помочь с решением данной задачи могут шаблоны Tolerant Reader и Consumer-Driven Contracts.
Микросервисная команда
Команда не должна включать в себя больше людей, чем можно насытить двумя пиццами. Такое правило использовала компания Amazon при распиливания своего монолита в 2002 году. Вполне допустимо и правило developer per service, то есть один разработчик на один микросервис.
18 декабря, Онлайн, Беcплатно
Когда большая система разбивается, часто происходит так, что образовываются команды на базе технологий. При такой ситуации команды размещают логику на тех слоях системы, к которым имеют доступ. Закон Конвея в действии:
«Любая организация, которая проектирует какую-то систему (в широком смысле) получит дизайн, чья структура копирует структуру команд в этой организации»
Микросервисный подход предполагает разбиение системы на сервисы по бизнес-требованиям. Сервисы включают в себя полный набор технологий: UI, storage, backend. Это приводит к созданию кросс-функциональных команд, имеющих достаточно компетенций для реализации всех необходимых сервисов, покрывающих 100% бизнес-функционала. Команды должны отвечать за все аспекты ПО, которое они разрабатывают, включая поддержку его в режиме 24/7. В таком случае возможность проснуться от звонка в 3 часа ночи — это очень сильный стимул писать хороший код.
Насколько большим должен быть микросервис
Логика работы сервиса должна полностью уместиться в голове одного разработчика, независимо от количества кода и людей. Проектируя систему, мы имеем выбор, как разработать каждый микросервис. Например:
Архитектура микросервиса даёт полную свободу в выборе технологий и инструменария.
Инструментарий для реализации микросервисов
В процессе реализации микросервисной архитектуры существенным упрощением будет использование систем CI/CD, системы оркестрации, Service Discovering, мониторинга и сбора логов.
Необходимо быть уверенным в том, что приложение работает правильно. Для этого запускаются автоматические тесты, при этом система разворачивается в отдельной среде (Automated Deployment).
Цепочка синхронных вызовов микросервисов приведет к ожиданию ответов от всех сервисов по очереди. Поэтому используйте правило «Один синхронный вызов на один запрос пользователя», как это сделали в The Guardian, либо полностью асинхронный API, как в Netflix. Один из способов сделать асинхронный API — использовать систему обработки очередей, например, RabbitMQ, Apache Kafka или ActiveMQ.
Простым языком о микросервисной архитектуре для начинающих
Расскажем о плюсах и минусах микросервисов, а также выясним, кому подходит технология.
Что такое микросервисная архитектура
Микросервисная архитектура — распространенный подход к разработке программного обеспечения, когда приложение разбивается на небольшие автономные компоненты (микросервисы) с четко определенными интерфейсами. Именно эта архитектура характерна для cloud-native приложений, которые сейчас популярны благодаря преимуществам, что открывают для бизнеса облачные среды.
Микросервисы vs Монолит
Прежде чем начать рассказ о микросервисах, стоит вспомнить другой тип приложений, который им чаще всего противопоставляют, — монолиты. Это приложения, построенные как единое целое, где вся логика по обработке запросов помещается внутрь одного процесса. Разумеется, монолиты могут иметь модульную структуру — содержать отдельные классы, функции, namespace (в зависимости от выбранного языка программирования). Но связи между этими модулями настолько сильны, что изменение каждого из них неизбежно отражается на работе приложения в целом.
Представьте себе кирпичную стену. Она возводится из отдельных блоков. При строительстве кирпичи еще отделимы друг от друга, но со временем, когда цемент затвердевает, они становятся неразрывно связаны. Вы можете продолжить стену в одном из направлений, но для того, чтобы коренным образом изменить ранее построенное, скорее всего, придется применить кувалду.
Рассмотрим для примера типичный интернет-магазин. Монолитное приложение для него будет использовать наверняка знакомую вам трехуровневую архитектуру, включающую:
Пример монолитной архитектуры
Мы видим, что бизнес-функции приложения очень разнообразны: работа с каталогом товаров и корзиной, обработка заказов, их оплата и отслеживание статуса, ведение пользователей и так далее. Но на уровне приложения все они объединены в один монолитный блок. При разворачивании код для различных функций находится на одном сервере. Чтобы масштабировать приложение, вам необходимо запустить несколько его экземпляров на различных физических серверах.
Недостатки такой схемы монолитной архитектуры очевидны:
Даже небольшое изменение для одной из бизнес-функций будет приводить к необходимости сборки и развертывания новой версии всего приложения.
Масштабировать приходится все приложение целиком, даже если это необходимо отдельно взятому компоненту с наименьшей производительностью. В нашем примере можно предположить, что обращения к каталогу товаров будут происходить значительно чаще оформления заказов — то есть именно для этой функции стоило бы выделить дополнительные ресурсы, но в монолите это невозможно.
Отказ одного модуля чаще всего сказывается на всей работе в целом в силу тесных связей внутри приложения.
Разработчик ограничен выбранным для приложения технологическим стеком. Хотя для ряда компонентов, возможно, было бы эффективно использовать иные технологии.
Требуется большая команда, которой тяжело управлять. При этом структура команды, вероятнее всего, будет соответствовать выбранной архитектуре: отдельные специалисты по пользовательскому интерфейсу, бизнес-логике и базе данных. И каждой из этих групп потребуется владеть экспертизой по всем бизнес-функциям, что со временем будет становиться все труднее.
Так как изменения затрагивают все приложение, увеличивается время на их отладку и проверку, что приводит к редким выходам обновлений и увеличению числа выпускаемых изменений в одном релизе, а это, в свою очередь, повышает риски.
Любое изменение в базе данных будет сказываться на всем приложении и требовать значительных изменений кода.
Для небольших и редко обновляемых приложений такая архитектура может работать прекрасно. Но по мере наращивания функциональности межмодульные связи в монолите будут неизбежно увеличиваться и усложняться, изменения в одних модулях будут все больше влиять на другие — в итоге дальнейшее развитие таких систем становится крайне затруднительным. И вот тут самое время присмотреться к микросервисам.
В отличие от монолитов, в микросервисной архитектуре приложение строится как набор небольших и слабосвязанных компонентов (микросервисов), которые можно разрабатывать, развертывать и поддерживать независимо друг от друга.
Если монолитное приложение проще всего сравнить с кирпичной кладкой, то микросервисы похожи на всем знакомый конструктор Lego. У вас есть множество деталей с четкими стандартными границами для соединения друг с другом. Вы всегда можете пересобрать получившееся изделие, заменив или убрав какие-то из элементов без ущерба для остальных.
Каждый из сервисов отвечает за конкретную бизнес-задачу, имеет собственное хранилище данных и общается с другими сервисами через простые API-интерфейсы для решения более сложных задач. Так, в нашем примере можно выделить микросервисы по ведению каталога товаров, работе с корзиной, оформлению заказов, оплате и так далее.
Пример микросервисной архитектуры
Ключевые преимущества микросервисов по сравнению с монолитами
Можно развертывать только изменяющиеся микросервисы, независимо от остальной системы, что позволяет производить обновления чаще и быстрее.
Можно расширять только те сервисы, которые в этом нуждаются, то есть сервисы с наименьшей производительностью, оставляя работать остальные части системы на менее мощном оборудовании.
Отказ одного сервиса не приводит к остановке системы в целом. Когда же ошибка исправлена, необходимое изменение можно развернуть только для соответствующего сервиса — вместо повторного развертывания всего приложения. Правда, для этого еще на этапе проектирования микросервисов потребуется тщательно продумать связи между ними для достижения максимальной независимости друг от друга, а также заложить возможность корректного оповещения пользователя о временной недоступности определенного сервиса без ущерба для всей системы.
Можно подбирать различные наборы технологий, оптимальные для решения задач, стоящих перед отдельными сервисами.
При разработке микросервисов команды принято закреплять за конкретными бизнес-задачами (и сервисами, соответственно). Такие команды, как правило, показывают большую эффективность, а управлять ими легче.
Присутствует возможность повторного использования функциональности для различных целей и различными способами.
Небольшие сервисы проще заменить на более подходящую версию или удалить вовсе — это несет значительно меньше рисков по сравнению с монолитным приложением.
Каждый микросервис, как правило, использует собственное хранилище данных — поэтому изменение модели данных в одном сервисе не влияет на работу остальных.
Недостатки микросервисной архитектуры: как с ними справиться
Несмотря на множество преимуществ, микросервисы далеко не всегда оказываются оптимальным вариантом, у них есть несколько особенностей, которые стоит учитывать при выборе архитектуры.
Распределенная система
Микросервисы по своей природе распределены, а это, как известно, имеет свои недостатки: удаленные вызовы медленнее и чаще подвержены сбоям. Если ваш микросервис обращается к десятку других микросервисов, а те, в свою очередь, вызывают еще несколько, то итоговое время отклика значительно возрастает. Также по мере увеличения взаимодействий микросервисов друг с другом возрастает и число возможных точек отказа.
Известны несколько путей решения этой проблемы:
Оба метода усложняют модель программирования и увеличивают требования к квалификации.
Усложнение процессов и повышение требований к команде
Рост числа небольших независимых сервисов неизбежно увеличивает операционную сложность. Возрастает роль непрерывной интеграции и доставки, ведь невозможно обрабатывать десятки услуг без автоматизации их тестирования и развертывания. Повышаются требования к мониторингу, особенно в силу технологической разнородности сервисов.
Чтобы справиться с возросшей нагрузкой, компании нужно овладеть целым рядом новых навыков и инструментов, и важнейший из них — внедрение культуры DevOps. Необходимо обеспечить тесное сотрудничество программистов, тестировщиков, инженеров сопровождения и прочих участников разработки продукта на всех этапах его жизненного цикла. Далеко не все организации смогут справиться с таким количеством изменений. Но культурные изменения необходимы.
Необходимость поддержания согласованности приложения
Микросервисы порождают возможные проблемы с согласованностью из-за применяемого в них децентрализованного управления данными. В монолитном приложении можно выполнить множество связанных изменений за одну транзакцию, и вы будете уверены, что в случае сбоя произойдет откат и согласованность данных сохранится.
Микросервисам же требуется несколько ресурсов для выполнения цепочки изменений, распределенные транзакции не приветствуются — поэтому может возникнуть ситуация, когда при обновлении одного компонента временно перестанет отвечать другой, ожидая завершения операции на первом.
Конечно, при разработке определенных сервисов можно отдать предпочтение не согласованности, а доступности: чтобы в случае обновления или выхода из строя одного сервиса, другие продолжали работу. Но делать это нужно крайне осторожно, чтобы бизнес-логика не принимала решений на основе противоречивой информации.
То есть разработчикам необходимо всегда помнить о проблеме конечной согласованности, находить компромисс между доступностью и согласованностью и предотвращать возможные случаи рассинхронизации данных.
Таким образом, при неоправданном использовании микросервисов многие их преимущества могут быть сведены на нет. Поэтому большинство специалистов советуют начинать с монолита, поддерживая его модульность, а к микросервисам переходить при появлении потребности в них и после проведения предварительной подготовки.
Микросервисы глазами аналитика
Расскажу про системы с микросервисной архитектурой (MSA). Как они устроены, как я их анализировала, какие увидела проблемы и преимущества.
1. Что такое система с MSA
На практике это все может оказаться запутавшейся в себе и своих связях, перегруженной и довольно хрупкой конструкцией. Все зависит от способа приготовления и места приложения.
То есть, как неоднократно писали (раз, два, три), MSA полезна не везде. Решение о ее использовании не тривиально, такие системы сложны для понимания и требуют особого внимания к своей архитектуре.
1.1. Выявление микросервисов
Вы спросите меня, что такое микросервисы? Я отвечу, что это, как правило, небольшие сервисы.
И вы уйдете, так и не узнав, что каждый реализует свою функцию, у каждого своя база данных и может быть свой стек технологий.
Самый сложный, вероятно, вопрос: как выделять микросервисы? Правильного ответа или алгоритма для этого нет. Все зависит от домена и того, какие проблемы вы решаете.
В главной шпаргалке по MSA в блоке Декомпозиция есть пополняемый перечень используемых подходов.
Давайте рассмотрим на примере способ декомпозиции по поддомену.
Этот подход основан на domain-driven design (DDD). То есть необходимо выявить поддомены системы, у каждого из которых своя доменная модель. Далее поддомены конвертируются в микросервисы.
Допустим, мы делаем систему для заказа продуктов в небольшом магазине рядом с домом. У нас есть пользовательские истории:
доставки товара (delivery).
Для обеспечения этих процессов необходимо где-то хранить информацию о наличии и количестве продуктов (stock). А также вести финансовый и бухгалтерский учет всех операций (accounting).
Опираясь на доменную модель, мы можем выделить следующие микросервисы:
Но это не единственный вариант. При декомпозиции стоит внимательно изучить бизнес-процессы и пользовательские требования, а также варианты развития системы.
Например, если конечный пользователь заказывает и оплачивает продукты во внешней системе партнера (какой-нибудь продуктовый маркетплейс). В наш магазин просто приходит информация о необходимости собрать и отправить заказ. Оплату партнер отправляет нам раз в месяц суммарно за все сделанные заказы, с учетом возвратов и пр. В этом случае отдельный микросервис 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):
Процесс OfflineSale в Camunda BPM
Каждый прямоугольник на схеме ссылается на код с логикой:
При инициации продажи MS Processes запустит этот процесс и Camunda выполнит каждый этап в заданной последовательности.
Более сложные схемы могут включать разветвления, таймеры, подпроцессы и пр.
Удобно, что уже описанные элементы одного процесса легко переиспользуются в другом процессе. Также небольшие изменения можно реализовывать без программирования.
Мы рассмотрели, как выделять микросервисы и как их складывать в нужном порядке для реализации процессов. Теперь давайте посмотрим на способы взаимодействия микросервисов с друг другом и внешним миром.
1.3. Интеграции
Помимо своей базы данных у каждого микросервиса еще и свой 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-шлюза вполне может выступать MS Processes. Однако при более сложных процессах и интеграциях бывает проще и надежнее их разделить. Например, если у нас есть свой фронт и внешний сервис, которые интегрируются по разным протоколам и поддерживаются разными командами. Но внутри приложения обе интеграции запускают один и тот же процесс.
Как правило внешним системам шлюз предоставляет REST+JSON API, так как в нему все привыкли и считают простым для интеграции. Но можно использовать и GraphQL, который позволяет клиенту указывать в запросе, какие именно данные нужно вернуть. Этот подход помогает при работе с несколькими клиентами, у каждого из которых свои цели и пристрастия.
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 и БД должны появиться поле и логика его обработки. То есть разработчик с этим не подскажет. А для заказчика это будет «вам нужно всего лишь добавить одно поле».
2.3. Возможные проблемы
Обозначу основные проблемы, с которыми довелось столкнуться, в порядке убывания бесячести.
2.3.1. Ничего не понятно
Многообразие сервисов, интеграций и технологий со стороны может выглядеть как запутанный клубок разных проводов. И чтобы вытащить свою зарядку для телефона, приходится распутывать LAN, провод от лампочки, чей-то переходник и Ктулху знает что еще.
Но в отличие от проводов, с микросервисами часто еще и не понятно, как их вообще распутывать.
Можно обращаться к гуру, которые все это делали и помнят. Только гуру, как известно, всегда заняты, потому что незаменимы. И скорее всего они что-то забыли или, что хуже, не знают о том, что они что-то забыли.
2.3.2. «Чужие» доработки
Решение видится в совокупности факторов:
повсеместное покрытие автотестами, что и так обязательно для MSA;
документирование всех изменений в едином пространстве ДО реализации (например, писать новые требования на общей странице и выделять их тегами со ссылкой на задачу, где эти требования будут реализованы);
очень дружная и активная коммуникацией аналитиков.
Документирование в таких объемах само по себе может стать проблемой, поэтому стоит посмотреть в сторону автоматизации. Так вы не будете тратить время хотя бы на таблички с API и БД. Но для этого придется поуговаривать разработчиков прикрутить какой-нибудь swagger2markup и выгрузку актуальных полей БД.
2.3.3. Заказчику сложно
Бизнес ничего не понимает сильнее, чем обычно. Откуда такие сроки, почему все сломалось, зачем вам этот GraphQL?
Чтобы принимать решения по продукту, надо разбираться в работе системы. А значит и всех этих переплетениях процессов, о которых тут так много написано. Хорошо бы совместно с менеджерами составлять ту самую бизнес-документацию и поддерживать ее актуальность.
2.3.4. Требуется много знаний
На самом деле это не проблема, а возможность получить новые навыки и посмотреть на разные технологии.
Помимо знаний о самой MSA, нужно быть готовым разобраться в принципах REST, брокеров сообщений и любом способе интеграции, который придет в голову вашему архитектору.
Возможно вас также затронут JWT, инстансы, балансировка, развертывание, анализ производительности, доступности и другие сложные слова.
Ну и совершенно не лишним будет стандартный набор аналитика из работы с требованиями, моделирования, написания понятной документации, БД и SQL и проектирования интеграций.
2.4. Плюсы MSA для аналитика
Несмотря на все проблемы и сложности, работать с микросервисами мне понравилось. И вот почему:
Относительно легко добавлять новые продукты и функции. Для этого пишут новые микросервисы и не нужно беспокоиться о том, что новый код как-то сломает работающие процессы. И даже если вы правите уже работающие микросервисы, то отследить зависимости и влияние проще, чем в монолите.
Скорее всего вы будете работать с профессионалами. Микросервисная архитектура создает вызовы для аналитиков, разработчиков, QA, DevOps и даже менеджеров. То есть все члены команды должны обладать определенным опытом и навыками для нормальной реализации этого подхода.
В системах с микросервисами аналитик бОльшую часть времени занимается именно анализом. На «неаналитические» задачи попросту не остается ресурса. Здесь аналитик по полной реализует свои профильные hard и soft скиллы.
Работа на проекте с MSA подразумевает особый подход, определенные навыки и знания. Нужно разобраться в деталях процессов и технологий. Возможно, изучить что-то или придумать новую схему работы, взаимодействия с заказчиком и коллегами.
Все это вполне постижимо и действительно интересно, хоть поначалу и не совсем прозрачно.
Надеюсь, после этой статьи кому-то станет немного понятнее, что может скрываться за этими загадочными словами в вакансиях. И к чему готовиться, если у вашего техлида внезапно улучшилось настроение и загорелись глаза.