Для чего нужна микросервисная архитектура

Микросервисная архитектура: теория и практика

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

В какой-то момент объём кода вырос до полного собрания сочинений Толстого. Как следствие – обновления разрабатываются все дольше, а тестировать их все сложнее. Это стандартная проблема для сложного программного обеспечения. Решить проблему узких мест на проекте можно используя микросервисы: везде, где есть «тяжелые» процессы, теоретически их можно вынести в специальное окружение.

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

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

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

Приложения, построенные на монолитной архитектуре (или просто монолиты) – это не обязательно приложения с одной функцией. Они содержат отдельные классы и функции, однако те крепко связаны друг с другом. Изъятие одного модуля неизбежно вызывает изменения в работе всей системы. Отсюда – ряд значимых недостатков:

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

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

Сервисы связываются между собой и с клиентами с использованием лёгких протоколов, например, HTTP. В результате создается простая для настройки система, которую проще регулярно обновлять. Ключевая идея микросервиса – независимость от окружающей среды и высокий уровень повторного использования.

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

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

Работать с микросервисами мы умеем уже очень давно. Году так в 2014 мы разрабатывали на Symfony логистический проект – расчет маршрутов доставки. Когда пользователь выбирает, например, доставку из Копенгагена в Токио, и ему предлагается несколько маршрутов по разным ценам.

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

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

Пользователь выбирал город. Задача попадала на сервер очередей. Демоны забирали эту задачу и рассчитывали каждый свой маршрут. То, что в один поток рассчитывалось бы 5-10 минут, мы получали в среднем за 15 секунд за счет параллельного расчета. Для сегодняшних реалий это очень много, но на момент разработки проекта – это был прорыв.

Микросервисы удобно реализуются при разработке на фреймворках – мы любим Laravel, Symfony – тоже ок. А вот для сайтов на Битрикс – все не так просто. Интернет-магазин нашего постоянного клиента Ormatek работает именно на Битриксе. На начало 2021 года там было около 200 тысяч товарных предложений.

Товарное предложение (или SKU) – это вариант товара. Например, кровать модели Dario Classic. Чтобы её купить, надо выбрать размер, основание и вариант исполнения (цвет и материал обивки). Товарное предложение – это кровать, для которой уже выбраны все доступные параметры.

Может показаться странным, что у магазина матрасов и мебели такой объемный каталог. Но каждая кровать может быть представлена в десятке размеров. С десятком вариантов оснований. А еще в 40+ вариантах исполнения. Если всё это перемножить – получается 4000+ вариантов на одну кровать. Очень серьезно.

Такой объем каталога создавал две проблемы:

Мы вынесли поиск, фильтрацию, сортировки и импорт в микросервисы. Для этого внедрили поисковую систему Elasticsearch. При старой архитектуре (использовался штатный модуль поиска 1С-Битрикс) поиск занимал около 10 секунд, что для обычного пользователя слишком много.

При поиске на такой объемной базе товаров Битрикс генерирует очень тяжелые запросы, которые нельзя поменять. Такие запросы получаются, например, когда Битриксу надо сформировать страницу списка кроватей из 120 тысяч SKU. Или при фильтрации, когда по свойствам надо сформировать и вывести нужные карточки товаров. Помимо свойств товаров, запрос должен учитывать ещё и их изображения. Какую именно картинку для товара выводить, заказчик задает через отдельное свойство-флаг.

Да, сначала мы пытались оптимизировать битриксовый поиск. И даже довели его скорость до 8 секунд. Но уперлись в ограничения Битрикса. Начали думать в сторону кеширования, но в случае с фильтром кеширование бесполезно, так как каждую комбинацию и каждый параметр фильтрации (малейшее движение ползунка) кешировать нецелесообразно.

Итак, мы решили перенести сортировку и фильтры в Elasticsearch. Если очень примитивно и схематично, то вот что у нас происходит теперь:

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

У нас есть собственный продукт, разработкой которого занимается отдельная команда – SingularityApp, планировщик дел и задач. Десктоп, iOS, Android и PWA-версия. Он состоит из множества различных решений для пользователей, которых становится все больше – новые фичи добавляются несколько раз в месяц.

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

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

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

Заодно решили проблему «узких мест» – часто выполняемых участков кода, которые своей производительностью ограничивали работу всей системы в целом. Весь функционал, который требует много ресурсов, например поиск или оптическое распознавание (OCR), мы также вынесли в отдельные сервисы, работающие в изолированной среде. Чтобы они не отбирали ресурсы у остальных частей проекта.

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

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

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

По сути докер – это виртуальный сервер. Можно создать в рамках одного физического сервера (компьютера) много виртуальных серверов и разделить ресурсы между ними так, как надо нам. А потом разместить микросервисы в докерах, чтобы они не толкались и не дрались друг с другом за ресурсы.

В качестве бонуса – в каждом докере можно использовать свое программное обеспечение. Например, у нас есть сервер разработки – dev. Там докеры используются, в том числе, для сайтов с разными версиями PHP, чтобы ничего не конфликтовало.

Еще добавилась такая такая штука, как балансировщик нагрузки (мы используем Docker Swarm). Это, по сути, система-оркестратор, которая позволяет управлять всем зоопарком микросервисов и гибко перераспределять ресурсы между ними.

Теперь мы при необходимости можем запускать на сервере несколько экземпляров одного сервиса (если это потребуется для распределения нагрузки), а низконагруженные сервисы оставлять по одному. Даже можем поднимать на нескольких серверах разные сервисы. А балансировщик нагрузки позволяет это делать практически без вмешательства человека.

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

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

Сначала мы оставили одновременно два сервера SingularityApp: новые устройства пользователей автоматически заходили на микросервисный сервер, а старые – на монолитный. Никакой практической разницы для пользователей не было, приложение на обоих серверах работало одинаково.

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

P.S. Все уже с ними поигрались, споткнулись десятки раз и снова возвращаются к монолитам там где надо, а не как раньше лендинг на 100 сервисов (утрирую).

P.S. видимо люди на VC пишут, когда для хабра слишком глупы

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

Позвольте полюбопытствовать, а по сравнению с какими протоколами Http вдруг стал «лёгким»?

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

Каждый сервис тратит процессорное время на кодирование-декодирование данных. Это вроде бы мизер в рамках одного сервисе, но когда их становится слишком много.

есть MySQL (база данных сайта), в нём по прежнему хранятся SKU,
есть Elasticsearch, в него мы тоже поместили все SKU, когда нам нужны определенные SKU с определенными свойствами, мы эти параметры передаем в Elasticsearch и за 0,5 сек. получаем не сами SKU, а список их id-шников. Эти id мы отдаем в MySQL и говорим: «Выведи их на страницу».

Я не спорю, что микросервисы где-то и в чем-то хороши, но это не абсолютно. Честно говоря, я как-то затруднюсь себе представить более-менее крупную 100% монолитную систему. Это вообще как? Одна программа, которая делает все-все-все? Такое вообще бывает?

Это микросервисы? Если да, то «изобрели» их очень давно. Еще во времена System/36..38 и всяких разных ЕС ЭВМ и БЭСМ. Если нет, то что это? Уж точно не монолит.

Источник

Плюсы микросервисной архитектуры

Знакомство с микросервисной архитектурой серьезно изменило мой подход к разработке. В этой публикации я расскажу о различных аспектах использования микросервисов. Для иллюстрации некоторых из них буду использовать архитектуру проекта по аренде недвижимости.

Подопытное приложение
Клиент просматривает список доступных квартир и бронирует их, также он может размещать на сервисе свои квартиры.

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

Компоненты: C — данные по квартирам (ядро), 1 — бронирование, 2 — оплата, 3 — логирование броней, 4 — размещение квартир, 5 — администрирование контента.

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

Каждой задаче свой инструмент

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

Для примера рассмотрим третий компонент нашего приложения — логирование. В самом базовом понимании нам нужно просто записывать текст в разные файлы.

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

Незаменимых нет

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

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

Каждому свое

В рамках одного проекта вам придется заниматься логикой взаимодействия для разных типов пользователей. Обслуживающий персонал вашего проекта (например: администраторы и модераторы) не исключение (модули 4 и 5).

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

Вы маленькие, даже когда вы большие

Когда 20+ человек работают над кодом одного проекта, даже с очень хорошей архитектурой, это вызывает проблемы. Багов становится гораздо больше, тестирование превращается в пытку и т.д. В итоге продукту очень трудно развиваться и практически невозможно сделать качественный скачек через обновления.

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

В итоге каждый из 6 компонентов будет обслуживаться 1-3 разработчиками. И в своей работе они не будут пересекаться с коллегами из параллельных микросервисов. Также стоит обратить внимание, что с микросервисами удобно будет работать в рамках версионности, которая легко реализуется в классическом API.

Итоги

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

А еще базовые функции каждого нового продукта можно будет собрать из уже готовых микросервисов. И это просто великолепно!

Источник

Микросервисы: почему это не панацея?

В последние годы только ленивый не слышал о микросервисах. «Долой монолитную архитектуру, микросервисы — это будущее веб-разработки!» — об этом трубят буквально все компании, в технологическом стеке которых появились Kubernetes и начали внедряться практики DevOps.

Вот только стоит ли вам что-то менять в софте, если и так все работает? Давайте разбираться.

Микросервисная архитектура: что это?

Микросервисная архитектура — это подход к веб-разработке, при котором приложение разбивается на множество частей, каждая из которых выполняет какую-то единственную функцию. Каждый микросервис «привязан» к отдельному домену (используя при этом автономное хранилище с данными и не зависимые от внешних модулей средства для связи с этим хранилищем) и может быть развернут независимо.

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

Связь микросервисов друг с другом: меньше зависимостей, больше универсальности

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

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

Какие технологии используются для создания микросервисной архитектуры?

Чаще всего для создания микросервисов используются инструменты Docker (для контейнеризации) и Kubernetes (для оркестровки контейнеров), идеальные для развертывания в корпоративных средах.

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

Преимущества и недостатки микросервисов

Выясним плюсы и минусы микросервисов.

Долой монолит. Да здравствуют микросервисы

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

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

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

Нужны ли вам микросервисы, если «и так все нормально работает»?

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

Так стоит ли игра свеч? Или же микросервисы — это очередное технологическое «ноу-хау», которое скоро устареет?

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

Тем не менее, существуют случаи, когда такое слепое следование IT-трендам выливается в проблемы с производительностью. Ведь, как мы знаем, каждый из микросервисов/веб-сервисов “привязывается” к отдельному источнику данных (СУБД). А это значит, что при одновременном использовании многих функций приложения подобная его структура будет подразумевать синхронное выполнение не одного десятка пользовательских запросов. И чем больше будет микросервисов-компонентов приложения, тем будет больше рисков того, что сервер окажется перегруженным.

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

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

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

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

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

Заключение

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

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

На правах рекламы

Многие наши клиенты уже оценили преимущества эпичных серверов!
Это недорогие виртуальные серверы с процессорами AMD EPYC, частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит оторваться на полную — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Поспешите заказать!

Источник

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

Расскажу про системы с микросервисной архитектурой (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 подразумевает особый подход, определенные навыки и знания. Нужно разобраться в деталях процессов и технологий. Возможно, изучить что-то или придумать новую схему работы, взаимодействия с заказчиком и коллегами.

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

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

Источник