Опыт ВсеИнструменты.ру: как тестировать микросервисы и нужны ли они вашему бизнесу

Примерно в 2018 году мы поняли, что нам нужны микросервисы. Команды разработки компании и их функционал, количество пользователей, товаров и заказов росли. Нам стало трудно рассчитывать доставку до конечного клиента. Было понятно, что решить эти проблемы на монолитах нельзя, нужно выносить их в отдельные сервисы. Вот что из этого получилось, рассказали заместитель IT-директора Алексей Шкирмановский и Тимлид отдела автоматизации тестирования Евгений Жильцов.

Сегодня у ВсеИнструменты.ру около сотни микросервисов и будет примерно в два раза больше после «распила» из текущих монолитов.

Преимущества микросервисов — изолированность кода и масштабируемость. В отличие от монолитов, масштабировать микросервисы быстрее и гораздо дешевле.

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

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

Тем не менее мы выбрали стек технологий и создали группу микросервисов логистики. И интегрировали со всеми монолитами / сервисами где эта логика была необходима: системы отчетности, ERP-систему, мобильное приложение, сайт.

Выбранный стек технологий менялся несколько раз прямо на ходу. Первый микросервис мы запускали на РНР (тогда же стало понятно, что он вообще не подходит для этой задачи). От него нельзя добиться нужной нам скорости ответа сервиса, через год сервисы, написанные на PHP, мы переписали на Go.

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

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

Сначала нужно определиться со стратегией и выбрать виды тестирования.

После выбора стратегии нужно обсудить активности тестировщиков; решить, как генерировать тестовые сценарии; рассчитать требуемые ресурсы.

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

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

Получившееся техническое задание позволяет оценить необходимое на тестирование время. Оно зависит от опыта тестировщика и объемов задач. Затем можно приступать к тестированию.

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

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

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

С другой стороны, начав с самого сложного процесса, значительно завязанного на клиентах, мы получили мощную экспертизу и теперь уверенно движемся вперед. Мы переосмыслили все ключевые бизнес-процессы компании, запустили несколько складов, в которых микросервисы отлично себя показали. Сейчас, например, при изменении логистических процессов, мы заходим в админку, меняем логику и все изменения автоматически «разъезжаются» по системам. На монолите на аналогичную операцию потребовался бы квартал и команда из 10 человек.

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

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

Автотестирование. Его нужно внедрить и постоянно совершенствовать. Этот процесс значительно экономит время разработчиков и тестировщиков. Когда мы только запускали микросервисы, на ручное тестирование регресса уходила неделя. Сейчас нужно около 25 минут.

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

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