Инструментарий техлида

Прошедший выпуск Podlodka Techlead Crew был посвящен межсервисному взаимодействию. Как и всегда, были знакомые вещи и не очень. В конечном счете, невозможно знать и помнить обо всём. Вот и я выписал себе очередной набор инструментов, которые показались мне крайне интересными. Чем и спешу поделиться.

Продолжаю наблюдать популяризацию идеологии Contract First. С ростом компании растет количество сервисов и продуктов, что неминуемо приводит к необходимости их интеграции и согласования работ между командами разработки. Идеология Contract First — один из инструментов для решения этих проблем, масштабирования компании и процессов. Тема абсолютно не новая, но с популяризацией микросервисов и изобилием протоколов и технологий межсервисного взаимодействия вновь начала набирать популярность.

Взяв курс на Contract First, очень важен вопрос выбора инструментов, поскольку они должны унифицировать процесс, контролировать его и ускорять. Иначе говоря, хотелось бы иметь какой-то стандарт или общий подход к описанию API (хотя бы на уровне компании), возможность верифицировать спецификации (делать ревью, архитектурный контроль, тестирование контрактов) и создавать их максимально быстро и удобно.

Файлы TypeSpec можно положить в Git и получить все преимущества версионирования, контроля изменений, тестирования и т.п. Всё точно так же, как и при написании кода.

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

Разработка и развитие API требует контроля обратной совместимости. Любые изменения в API должны подвергаться жесточайшему контролю. Помочь в этом может проект OpenAPI-diff.

Я затронул тему тестирования контрактов, которую подробно описывает Крис Ричардсон (см. Consumer-driven contract test, Consumer-side contract test, Consumer-Driven Contracts). Насколько применим этот подход в реальной практике в сочетании с вышеописанным инструментарием. В частности, можно ли интегрировать эти инструменты и Spring Cloud Contract.

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

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

В современной практике очень часто можно встретить необходимость гетерогенного хранения данных или необходимость в транзакционной логике при выполнении бизнес-процессов с участием нескольких (микро)сервисов. В этом случае на помощь приходит шаблон Saga и два классических подхода к его реализации: оркестрация и хореография. Реализация данного шаблона без использования какого-то фреймворка крайне затруднительна, но даже с фреймворком всё не так просто. Внедрить Saga в существующий проект — ещё то приключение. Существенно упростить жизнь помогает проект Temporal.

Всё выглядит так, что Temporal позволяет достаточно быстро добавить Saga в существующий проект, особенно если он написан без использования таких структурообразующих фреймворков, как Spring.

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

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

При этом было отмечено, что очень важно не маскировать бизнес-ошибки за кодами HTTP 2xx (например, "HTTP 200 Недостаточно средств"). Это создает серьезные проблемы при сборе статистики о работе системы на уровне инфраструктуры.

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

P.s. Если вам интересна данная тематика, присоединяйтесь к моей новостной ленте в Telegram или здесь. Буду рад поделиться опытом. ;-)