Согласно недавнему исследованию компании O’Reilly о внедрении микросервисной архитектуры (MSA), почти треть респондентов заявили, что их работодатели переносят или внедряют большинство систем с использованием микросервисов. Микросервисами уже пользуются более трех четвертей опрошенных.
На зарубежном рынке микросервисную архитектуру используют такие гиганты, как Twitter, Facebook, Amazon, Spotify, Uber, Google. Компания Netflix использует свыше 700 микросервисов для каждой конкретной задачи — из них состоит весь сервис. Например, один элемент хранит информацию о сериалах, которые посмотрел тот или иной пользователь. Другой — отвечает за ежемесячную оплату за пользование сервисом. Третий — изучает предпочтения, историю просмотров, чтобы предложить релевантный конкретному человеку сериал.
Что за зверь Micro Service Architecture?
Новичок, сталкивающийся с MSA (Micro Service Architecture), на первых порах восклицает: «эти микросервисы еще изучал в далекие студенческие годы», и отчасти они правы, но лишь отчасти.
Давайте разберемся почему, но для начала рассмотрим базовые понятия.
MSA — это способ создания программных продуктов, предполагающий разработку независимых друг от друга модулей. Каждая часть приложения отвечает за определенную задачу и может быть изменена или расширена без дополнений в других. При этом сервисы взаимодействуют между собой с помощью обмена сообщениями.
Система с MSA — сильная и независимая. Согласно задумке, она может не заботиться о масштабируемости, использовать разные стеки технологий и легко исправлять свои ошибки. Ее подход позволяет быстро развиваться и быть гибкими в поддержке.
На практике это все может оказаться запутавшейся в себе и своих связях, перегруженной и довольно хрупкой конструкцией. Для эффективного управления каскадом микросервисов, как единым организмом, требуется достаточно высокая квалификация и отлаженная работа по координации этого «улья». Такие системы сложны для понимания и требуют особого внимания к архитектуре, в том числе со стороны аналитиков.
Макромир микросервисов
Понять суть микросервиса проще всего на сравнении или даже противопоставлении его крупному приложению — монолиту.
В отличие от монолита, каждый микросервис реализует свою функцию, имеет свою базу данных и в некоторых случаях свой стек технологий.
Давайте более подробно сфокусируемся на наиболее важных характеристиках микросервиса.
Он небольшой — несет минимальную выделенную функцию. Если искать аналогию, то это часть из конструктора Lego, которая используется для создания «Тысячелетнего сокола».
Микросервисная архитектура — воплощение паттернов High Cohesion: высокая сплоченность и слабая связность. Микросервис обязан быть независимым компонентом, то есть такой единицей, код которой может быть независимо заменен или обновлен.
Слабая связность — это когда можно легко внести изменения в один сервис, не трогая остальные. Для достижения подобного подхода нужно гарантировать, что каждый сервис знает о других только необходимый минимум.
Определение границ микросервиса — самый важный шаг. От этого будет зависеть вся дальнейшая его жизнь и серьёзно повлияет на жизнь команды, отвечающей за него.
Один из наиболее известных способов разбиения на микросервисы — это определение бизнес-возможностей приложения и создание по одному микросервису на каждую из них. Бизнес-возможности представляют собой функции, которые будут доступны пользователям при работе с приложением.
Например, «Управление созданием заказов» трансформируется в отдельный сервис order creation service. А функция «Управления платежами» в отдельный независимый микросервис по платежам, который может быть встроен в десятки платформ.
Одной из важнейших задач — суметь корректно выделить минимальную самостоятельную бизнес-функцию, которая в дальнейшем будет трансформирована в отдельный микросервис и обосновать решение. В начале пути это возможно сложно, но все приходит с опытом и в дальнейшем уже не будет составлять существенных трудозатрат.
Чтобы минимизировать ошибки при определении границ, нужно вначале их продумать. Поэтому, как правило, оправданным является подход Monolith First, когда вначале систему развивают в традиционной парадигме, а когда появляются устоявшиеся области, их выделяют в микросервисы. Главное, чтобы выигрыш от разбиения превышал сложности пересмотра этих границ.
Такой подход к постепенному формированию набора микросервисов похож на итерационное развитие, используемое в Agile, ещё его называют «эволюционным проектированием» (Evolutionary Design).
Принципы проектирования сервисов на микросервисной архитектуре
На самой поверхности в масштабных проектах существует методологическая проблематика перехода на микросервисы. Если кратко, то её провоцируют:
Разные принципы проектирования продуктов, которые приносят хаос при понимании работы «улья» микросервисов.
Разные приоритеты и фокусы — непонятно куда, зачем и когда двигаться.
Разное понимание потребностей клиентов. Это существенная проблема так как продукт реализуется именно под клиента, иначе зачем он вообще?
Решить указанные проблемы можно за счет внедрения не архитектурных принципов проектирования сервисов на микросервисной архитектуре, на которые системные аналитики могут опираться в работе.
Так декларирование унифицированных критериев качества оказания услуг и осуществления действий для закрытия потребности внешних или внутренних клиентов позволит системным аналитикам внести ясность и упростить взаимодействие при согласовании критериев качества сервиса, имеющего микросервисную архитектуру. По-простому систематизировать существующих хаос.
Есть 6 проверенных временем принципов, которые необходимы для владельцев сервисов при определении и согласовании критериев качества, других системных аналитиков, технологов при разработке, модификации сервисов.
Пройдемся по ним более подробно и начнем с принципа «Знай своего клиента».
Каждый сервис должен знать поставщиков (сервис До) и потребителей (сервис После или Клиент). Изменения сервиса должны согласовываться с внутренним потребителем, поставщиком.
Например, если ты общепродуктовый сервис материнского капитала, то в данном случае точно должен понимать, что потребителем является стрим ипотеки, а поставщиком является Пенсионный фонд. При проектировании должны быть учтены все пожелания/ требования стрима Ипотеки в рамках атрибутивного состава или перечня обрабатываемых документов, а также потребности самих клиентов банка по вопросам материнского капитала, которые возможно не реализованы прямо сейчас, но могут быть затронуты в скором времени и при планировании развития микросервиса эти вопросы лучше учесть на старте.
Перейдем к принципу «Следи за своим здоровьем». Он означает что владельцу сервиса необходимо контролировать заявленные критерии качества, выявлять отклонения и их причины. В компании должны быть выстроены единые стандарты по метрикам качества, предъявляемым к мониторингу микросервисов.
Мониторинг критично важен. Если дело касается микросервисов, чтобы своевременно реагировать на возможные шероховатости при интеграциях или в работе, нужно прикрутить к микросервису хотя бы верхнеуровневый мониторинг в виде Grafana, Kibana и желательно заняться этим вопросом планомерно. В противном случае оперативно понять причины целого ряда проблем будет задачей, с которой не справятся ни специалисты поддержки, ни очень квалифицированные разработчики.
Что касается принципа «SMART цифровизации», то он говорит о том, что владелец сервиса должен стремиться к его в продвижению во всех возможных каналах взаимодействия с клиентом.
При этом нужно четко понимать:
Что именно необходимо достичь.
В чем будет измеряться результат.
За счёт чего планируется достичь цели и возможно ли её достигнуть вообще.
Уместность цели.
Момент во времени, до которого цель должна быть достигнута (задача выполнена).
При этом системным аналитикам всегда нужно взвешивать риски и подсвечивать экономическую целесообразность руководителям по выкатке потенциальных фичей. При этом необходимо учитывать омниканальность реализуемого решения, то есть взаимную интеграцию разрозненных каналов коммуникации в единую систему для обеспечения бесшовной и непрерывной коммуникации с клиентом.
Принцип «Максимизации сквозной обработки» говорит о том, что сервис на микросервисной архитектуре не создает дублирующие документы и атрибуты, исключает повторный ввод данных, «предзаполняет» данные для процесса автоматически из мастера источников.
Проще говоря, по итогу выполнения пунктов чек-листа происходит исключение дублирования работы, минимизация человеческой ошибки ввода данных, а также автоматизация обогащения данных из других служебных сервисов за счет различных интеграций, поскольку сама БД микросервиса ограничена и не зависима.
Принцип «Secure-by-Design» подразумевает, что владелец сервиса стремится обеспечить безопасность на всех этапах производственного процесса — от идеи до вывода сервиса из эксплуатации.
Это позволяет на старте избежать ситуаций, когда, например, статусная модель мастер системы и отдельного микросервиса не совпадают, что влечет целый ворох проблем по рассинхронизации процесса.
Что же касается принципа «Эволюционируй вместе с искусственным интеллектом», то это значит, что владелец сервиса на микросервисной архитектуре стремится использовать возможности AI для создания интеллектуальных сервисов.
Все мы двигаемся в ногу со временем и сейчас использование ИИ, включая рекомендательные системы и другие классные вещи, чтобы получать автоматические рекомендации по улучшению сервиса для клиента, становятся повседневностью. Но для понимания можно ли использовать возможности AI прямо сейчас, нужно дать четкие ответы на поставленные вопросы из чек-листа, Если по всем пунктам можно проставить галочку, то уже пора задумываться о прикручивании тех или иных возможностей AI к сервису, которые позволят сделать его более востребованным для клиентов и улучшить качество.
Лайфхак для облечения работы с микросервисами
Одна из сложностей при огромном количестве микросервисов — это необходимость их упорядочивания и систематизации. В противном случае, можно просто утонуть в различных несвязанных наименованиях API микросервисов, тратя буквально вечность на поиски ответов в тонне документации, что есть что и как их связать.
Важным моментом, существенно облегчающим в будущем отражение связей в документации, является правильное наименование API сервисов, которое существенно упростит жизнь и поддержку версионирования.
Представленный подход как раз позволит решить данную проблематику и наглядно позволить с ходу ответить на ряд важных вопросов. Советую сохранить его в свою коллекцию полезной информации.
What next?
С теорией заканчиваем. Если остались вопросы по микросервисной архитектуре, то готов ответить в комментариях.
В следующей статье перейдём к практике работы с микросервисами с точки зрения системных аналитиков.
