как тестировать приложения которые работают с очередями сообщений
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования мобильных приложений состоит из восьми разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
1. Установка/удаление/накатка версий
2. Запуск приложения (отображение Splash Screen)
3. Работоспособность основного функционала приложения
3.1 Авторизация (по номеру телефона/через соц. сети/e-mail)
3.2 Регистрация (по номеру телефона/через соц. сети/e-mail)
3.3 Онбординг новых пользователей
3.4 Валидация обязательных полей
3.5 Навигация между разделами приложения
3.6 Редактирование данных в профиле пользователя
3.7 Проверка оплаты
3.8 Тестирование фильтров
3.9 Бонусы
4. Корректное отображение ошибок
5. Работа с файлами (отправка/получение/просмотр)
6. Тестирование тайм-аутов
7. Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д)
8. Тестирование pop-up, алертов
9. Тестирование WebView
10. Скролл/свайп элементов
11. Тестирование PUSH уведомлений
12. Сворачивание/разворачивание приложения
13. Разные типы подключений (сотовая связь/Wi-Fi)
14. Ориентация экрана (альбомная/портретная)
15. Темная/светлая темы
16. Реклама в приложении
17. Шаринг контента в соц. сети
18. Работа приложения в фоне
19. Пагинация страниц
20. Политики конфиденциальности и прочие ссылки на документы
Тестирование совместимости
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Что проверяем?
1. Корректное отображение гео
2. Информации об операциях (чеки и т.д.)
3. Различные способы оплаты (Google Pay, Apple Pay)
4. Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.)
5. Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.)
6. Подключение внешних устройств (карта памяти/наушники и т.д.)
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
Что проверяем?
1. Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.)
2. Данные пользователя (пароли) не передаются в открытом виде
3. В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
1. Все элементы в приложении переведены на соответствующий язык
2. Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык
3. Тексты зависят от языка в системных настройках
4. Тексты приходят с сервера
5. Корректное отображение форматов дат (ГОД — МЕСЯЦ — ДЕНЬ или ДЕНЬ — МЕСЯЦ — ГОД.)
6. Корректное отображение времени в зависимости от часового пояса
Тестирование удобства использования
Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
Что проверяем?
1. Корректное отображение элементов на устройствах с различными разрешениями экранов
2. Все шрифты соответствуют требованиям
3. Все тексты правильно выровнены
4. Все сообщения об ошибках верные, без орфографических и грамматических ошибок
5. Корректные заголовки экранов
6. В поисковых строках присутствуют плейсхолдеры
7. Неактивные элементы отображаются серым
8. Ссылки на документы ведут на соответствующий раздел на сайте
9. Анимация между переходами
10. Корректный возврат на предыдущий экран
11. Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.)
12. Пиксель-перфект
Стрессовое тестирование
Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Что проверяем?
1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)
Кросс-платформенное тестирование
Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Что проверяем?
— Работоспособность приложения на различных устройствах разных производителей
Тестирование производительности
Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Что проверяем?
1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)
Зачем нужны очереди сообщений в микросервисной архитектуре: разбираем преимущества и недостатки
При проектировании микросервисов часто возникает вопрос: какой способ связи между ними выбрать.
Многие отдают предпочтение RESTful API. Однако этот подход не всегда эффективен, так как в отдельных случаях чреват долгим ожиданием на клиентской стороне и потерей информации в случае сбоев.
Мы расскажем про такой вариант для взаимодействия микросервисов, как очереди сообщений, а также попытаемся выяснить, для каких сценариев они подходят лучше всего. Разобраться в вопросе нам помог Павел Юдин, руководитель команды облачных продуктов, Tarantool / VK.
Sync vs Async: синхронное и асинхронное взаимодействие
Очереди сообщений (Message Queue) — это форма асинхронной коммуникации между сервисами. Поэтому, прежде чем говорить о них, покажем на упрощенном, немного искусственном примере разницу между синхронным и асинхронным взаимодействием.
Предположим, вы разрабатываете сайт книжного магазина и у вас есть сервис, к которому обращается пользователь, например отправка рецензии на прочитанную книгу. При нажатии кнопки «Отправить» вызывается некоторый API, который, в свою очередь, может обратиться к другим API.
При синхронном взаимодействии все запросы в этой цепочке вызовов выполняются строго друг за другом, а при выполнении последнего запроса ответы последовательно передаются в обратном направлении. В итоге пользователь вынужден пару секунд ждать сообщения о публикации своего отзыва, хотя его не интересуют особенности серверной обработки и он вполне обоснованно хочет увидеть сообщение сразу после нажатия кнопки. Конечно, время ожидания будет во многом определяться мощностью оборудования, но при пиковых нагрузках оно может стать серьезной проблемой.
Еще один недостаток такой схемы — обработка сбоев. Если на одном из шагов возникнет исключение, оно каскадно возвратится назад, и пользователь получит уведомление об ошибке с просьбой повторно отправить рецензию. Вряд ли кого-то обрадует получение подобного сообщения после длительного ожидания.
Синхронное взаимодействие на основе REST API
Описанную схему можно изменить, добавив асинхронные вызовы. Достаточно вызвать в асинхронном режиме первый REST API и параллельно вернуть пользователю сообщение о том, что его рецензия принята и будет размещена, например, в течение суток. В итоге сайт не блокируется, а вызовы всех последующих API происходят независимо от пользователя.
Но у такой схемы также есть существенный недостаток: в случае сбоя в одном из API информация, введенная пользователем, будет потеряна. Если в первом примере в случае ошибок достаточно повторно отправить рецензию, то здесь ее необходимо заполнить заново.
Вариант асинхронного взаимодействия на основе REST API
Для устранения недостатков обеих схем как раз и предназначены очереди сообщений.
Принципы работы очередей сообщений
Очереди предоставляют буфер для временного хранения сообщений и конечные точки, которые позволяют подключаться к очереди для отправки и получения сообщений в асинхронном режиме.
В сообщениях могут содержаться запросы, ответы, ошибки и иные данные, передаваемые между программными компонентами. Компонент, называемый производителем (Producer), добавляет сообщение в очередь, где оно будет храниться, пока другой компонент, называемый потребителем (Consumer), не извлечет сообщение и не выполнит с ним необходимую операцию.
Очереди поддерживают получение сообщений как методом Push, так и методом Pull:
Так как очереди могут использоваться несколькими производителями и потребителями одновременно, обычно их реализуют с помощью дополнительной системы, называемой брокером. Брокер сообщений (Message Broker) занимается сбором и маршрутизацией сообщений на основе предопределенной логики. Сообщения могут передаваться с некоторым ключом — по этому ключу брокер понимает, в какую из очередей (одну или несколько) должно попасть сообщение.
Вернемся к примеру с отправкой рецензии. Пусть та часть сервиса, к которому обращается пользователь, выступит в качестве производителя и будет направлять запросы на создание рецензий в очередь. Сразу после добавления сообщения в очередь пользователю можно направлять уведомление об успехе операции. Вся последующая логика обработки будет выполняться независимо от него на стороне потребителя, подписанного на очередь.
Завершив обработку, потребитель отправит подтверждение в очередь, после чего исходное сообщение будет удалено. Но если во время обработки произойдет сбой и подтверждение не будет получено вовремя, сообщение может быть повторно извлечено потребителем из очереди.
Вариант асинхронного взаимодействия на основе очереди сообщений
Польза и преимущества очередей сообщений в микросервисной архитектуре
Используя очереди сообщений в качестве основного средства взаимодействия микросервисов (Microservices Communication), можно добиться следующих преимуществ:
Отличительная черта микросервисов — их автономность. И очереди во многом помогают уменьшить зависимости между ними. Каждое сообщение, передаваемое в очереди, — это всего лишь массив байтов с некоторыми метаданными. Метаданные нужны для направления в конкретную очередь, а информация, содержащаяся в основной части (теле) сообщения, может быть практически любой. Брокер не анализирует данные, он выступает лишь в качестве маршрутизатора. Это позволяет настроить взаимодействие между компонентами, работающими даже на разных языках и платформах.
Очереди сообщений упрощают независимое масштабирование микросервисов. Наблюдая за состоянием очередей, можно масштабировать те сервисы, на которые приходится большая часть нагрузки. Кроме этого, очереди легко позволяют не только увеличивать число экземпляров существующих сервисов, но и добавлять новые с минимальным временем простоя. Все, что для этого требуется, — добавить нового потребителя, прослушивающего события в очереди.
Однако сами очереди также необходимо масштабировать, и это может создать дополнительные сложности.
Если один из сервисов не справляется с нагрузкой, требуется возможность запускать больше его экземпляров быстро и без дополнительных настроек. Обычно для этих целей используют балансировщик нагрузки, интегрированный с сервером обнаружения служб и предназначенный для распределения трафика. При использовании очередей сообщений сам брокер по умолчанию является балансировщиком нагрузки. Если несколько потребителей слушают очередь одновременно, сообщения будут распределяться между ними в соответствии с настроенной стратегией.
Выход из строя одного из компонентов не сказывается на работе всей системы: при восстановлении он обработает сообщение, находящееся в очереди. Ваш веб-сайт по-прежнему может работать, даже если задерживается часть обработки заказа, например, из-за проблем с сервером БД или системой электронной почты.
Правда, при этом очередь сама приобретает статус SPoF (Single Point Of Failure), поэтому необходимо заранее предусмотреть действия на случай ее аварийного отключения.
Большинство брокеров выполняют аутентификацию приложений, которые пытаются получить доступ к очереди, и позволяют использовать шифрование сообщений как при их передаче по сети, так и при хранении в самой очереди. Таким образом, очередь снимает с ваших сервисов бремя организации авторизации запросов.
Варианты использования очередей сообщений
Очереди сообщений полезны в тех случаях, где возможна асинхронная обработка. Рассмотрим наиболее частые сценарии использования очередей сообщений (Message Queue use Cases):
Сюда можно отнести задачи, которые не связаны напрямую с основным действием пользователя сайта и могут быть выполнены в фоновом режиме без необходимости ожидания с его стороны. Это обработка изображений, преобразование видео в различные форматы, создание отзывов, индексирование в поисковых системах после изменения данных, отправка электронной почты, формирование файлов и так далее.
Очереди можно использовать в качестве буфера для некоторой массовой обработки, например пакетной вставки данных в БД или HDFS. Очевидно, что гораздо эффективнее добавлять сто записей за раз, чем по одной сто раз, так как сокращаются накладные расходы на инициализацию и завершение каждой операции. Но для стандартной архитектуры может стать проблемой генерация данных клиентской службой быстрее, чем их может обработать получатель. Очередь же предоставляет временное хранилище для пакетов с данными, где они будут храниться до завершения обработки принимающей стороной.
Многие системы очередей позволяют производителю указать, что доставка сообщений должна быть отложена. Это может быть полезно при реализации льготных периодов. Например, вы разрешаете покупателю отказаться от размещения заказа в течение определенного времени и ставите отложенное задание в очередь. Если покупатель отменит операцию в указанный срок, сообщение можно удалить из очереди.
Помещая данные в очередь, вы можете быть уверены, что данные будут сохранены и в конечном итоге обработаны, даже если это займет немного больше времени, чем обычно, из-за большого скачка трафика. Увеличить скорость обработки в таких случаях также возможно — за счет масштабирования нужных обработчиков.
Нестабильная сеть в сочетании с очередью сообщений создает надежный системный ландшафт: каждое сообщение будет отправлено, как только это будет технически возможно.
Многие брокеры поддерживают очереди FIFO, полезные в системах, где важно сохранить порядок транзакций. Если 1000 человек размещают заказ на вашем веб-сайте одновременно, это может создать некоторые проблемы с параллелизмом и не будет гарантировать, что первый заказ будет выполнен первым. С помощью очереди можно определить порядок их обработки.
Очереди часто применяют для сбора некоторой статистики, например использования определенной системы и ее функций. Как правило, моментальная обработка такой информации не требуется. Когда сообщения поступают в веб-службу, они помещаются в очередь, а затем при помощи дополнительных серверов приложений обрабатываются и отправляются в базу данных.
Если у вас есть некоторая задача для группы серверов, то вам необходимо выполнить ее на каждом сервере. Например, при редактировании шаблона мониторинга потребуется обновить мониторы на каждом сервере, использующем этот шаблон. Вы можете поставить сообщение в очередь для каждого сервера и выполнять их одновременно в виде небольших операций.
Это обработка финансовых транзакций, бронирование авиабилетов, обновление записей о пациентах в сфере здравоохранения и так далее.
Сложности использования и недостатки очередей сообщений: как с ними справляться
Несмотря на многочисленные преимущества очередей сообщений, самостоятельное их внедрение может оказаться довольно сложной задачей по нескольким причинам:
Хорошая новость в том, что многие облачные провайдеры сейчас предлагают очереди как сервис (MQ as a Service). Поэтому если у вас недостаточно ресурсов для самостоятельной настройки и поддержки очередей сообщений, то можно воспользоваться одним из готовых решений. Большинство из них включает автоматизацию настройки, масштабирование, диагностику ошибок и техническую поддержку, а также поддерживает строго однократную доставку в очередях FIFO.
В каких случаях очереди неэффективны
Конечно, очереди не являются универсальным средством для любых приложений. Рассмотрим варианты, когда очереди не будут самым эффективным решением:
Выбирая инструмент для будущего приложения, обязательно взвесьте все за и против. Не стоит использовать очереди сообщений для задач, которые могут быть решены другим, более простым в настройке и обслуживании способом. Но в тех случаях, когда запланирован переход на микросервисы и бизнес-логика допускает возможность асинхронной обработки, очереди сообщений могут стать лучшим выбором для повышения производительности и надежности вашего продукта.
Если вы заинтересованы в использовании очередей, но опасаетесь, что команда не справится с их конфигурированием и последующей поддержкой самостоятельно, всегда можно воспользоваться одним из Managed-решений, представленных на рынке.
Тестирование микросервисно-ориентированных приложений
Продолжая проработку темы микросервисов, мы решили предложить вам перевод статьи о тестировании MOA (микросервисно-ориентированных приложений). В последнее время мы уже обращались к теме тестирования, но в случае микросервисов обычного модульного тестирования недостаточно, необходимо также учитывать аспекты, связанные с CI/CD и другие вещи, о которых пойдет речь в этой статье.
Микросервисы – новый стиль программной архитектуры, применяемый при создании распределенных систем и все шире внедряемый в компаниях, работающих в Вебе, в том числе, в крупнейших из них. Так, Netflix и Amazon взяли на вооружение микросервисную архитектуру, чтобы значительно ускорить релиз программных продуктов. При этом более древние монолитные системы не могут масштабироваться со скоростью, которая отвечала бы современным вызовам.
Но та польза, которую может принести микросервисная архитектура, хороша лишь настолько, насколько полно удается протестировать практические методы для ее поддержки. При проектировании тестов для проверки микросервисных систем, где темп релизов можно назвать молниеносным, требуется придерживаться новаторского мышления, как на микро- так и на макроуровне.
Далее мы исследуем три типа микросервисно-ориентированных приложений, обсудим некоторые вызовы, с которыми придется справиться, чтобы наладить их тестирование, а также поговорим о том, как пишутся тесты, позволяющие наиболее полно оценить достоинства микросервисов.
Кратко о микросервисах
Прежде чем переходить к некоторым тонкостям проектирования тестов для микросервисов, давайте вспомним, что представляют собой микросервисы. Микросервис – это детально выделенный программный компонент, которому дано четкое семантическое определение; при этом микросервис несет собственный набор данных и не зависит от других структур данных и источников данных. У каждого микросервиса свой цикл развертывания, поэтому после того, как в микросервис были внесены изменения, можно выполнить его релиз, не прерывая работы никаких других микросервисов в области действия того приложения, с которым работает этот микросервис.
Преимущества микросервисных приложений над монолитными
Также давайте рассмотрим, чем микросервис не является. На следующем рисунке показан пример типичного монолитного приложения.
Рис. 1: В архитектурах монолитных приложений обычно наблюдается сильная связанность компонентов
Компоненты Customers (Клиенты), Products (Товары), Orders (Заказы) и (Комментарии) можно трактовать как множества классов, написанных на объектно-ориентированном языке, например, на Java или C#, где customers – это массив объектов, соответствующих клиентам, products – массив объектов, соответствующих товарам и т.д. Объект customer может воспользоваться как объектом customer, так и объектом product. Либо в силу того, что все компоненты монолитного приложения обращаются к одной и той же базе данных, объект order вполне может обратиться напрямую к базе данных и получить всю информацию о товаре и заказе, которая нужна для выполнения поставленных задач. Прямой доступ к базе данных не только возможен – притом, насколько он противоречит духу объектно-ориентированного программирования на основе объектно-реляционного отображения ORM — но и активно используется, особенно в тех сферах, где существует высокий спрос на готовые фичи к условленному сроку, не важно, какой ценой.
В результате получается сильно связанная, порой хрупкая система, где релиз новой версии приложения требует значительной координации между всеми командами разработчиков, участвующими в развитии этой системы. Из-за сильной связанности весь релизный цикл не может идти быстрее, чем самая медленная работа по пересмотру какой-нибудь зависимости. Иными словами, если приложение пора обновлять и вносить в него одновременно новую фичу по клиентам и новую фичу по товарам, то релиз не состоится, пока обе эти фичи не будут готовы. Если на внесение обновления по товарам требуется один день, а на внесение изменения по клиентам требуется три недели, то релиз состоится не ранее чем через три недели. Причем, что еще сильнее усугубляет ситуацию, при релизе может потребоваться не только скоординировать новый код, касающийся клиентов и товаров, но и внести изменения в схему базы данных, и этим также придется управлять в процессе релиза.
Релиз изменений для базы данных – очень деликатное предприятие. При изменении структуры базы данных всегда существует риск непредусмотренных побочных эффектов. Помните, что, если любой компонент может обращаться к базе данных, то он и будет к ней обращаться, причем, даже производить над данными такие операции, которые не входят в зону ответственности данного компонента. Такие «манипуляции вне зоны ответственности» могут приводить к сбоям других компонентов, и подобные сбои могут оставаться незамеченными, пока не произойдет катастрофа. Иногда потенциальная опасность может обнаружиться в коде вплоть до выхода этого кода в продакшен. К сожалению, такое происходит постоянно.
Некоторые компании готовы мириться с медленными релизными циклами, какие характерны для работы с монолитными приложениями. Но, если речь идет о компании, обеспечивающей поддержку сотен тысяч пользователей, и должна при этом поддерживать в работоспособном виде тысячи компонентов, то темп «не быстрее релиза самого запаздывающего компонента» неприемлем.
Микросервисно-ориентированные приложения
В микросервисно-ориентированном приложении (MOA) каждый функциональный компонент разлагается на минимально возможные единицы, обладающие выраженным функционалом (в разумных пределах). В таком случае каждый такой функциональный компонент организуется в виде микросервиса. В каждой компании есть свой багаж унаследованного кода, а также корпоративная культура, которой следует придерживаться, поэтому невозможно расписать «как по нотам», как именно должна осуществляться декомпозиция.
Когда возникает необходимость декомпозировать монолитное приложение в MOA, главное помнить, что лучшее – враг хорошего. Убедитесь, что каждый из микросервисов структурирован согласно его семантическому определению, что для микросервиса предусмотрены собственные данные, а также собственный релизный цикл. Глубина реализации зависит от того, что может себе позволить компания, исходя из имеющегося времени, опыта сотрудников и доступных ресурсов. В некоторых микросервисах может быть всего по одной функции, в других – по много функций.
Существует три типа MOA: синхронные, асинхронные и гибридные.
Синхронные микросервисно-ориентированные приложения
На рисунке 2 показано синхронное MOA. Межсервисная коммуникация осуществляется по принципу запрос-отклик, типичному для HTTP-взаимодействий в вебе.
Рисунок 2: Микросервисно-ориентированное приложение основано на синхронной межсервисной коммуникации
Каждый микросервис сегментируется за HTTP-сервером, что открывает доступ к логике этого микросервиса. Конкретному микросервису известна только его собственная зона ответственности; также ему могут быть известен интерфейс для взаимодействия с другим микросервисом, но внутреннюю логику другого сервиса он видеть не может. Кроме того, микросервису известно только о его собственных данных. Хранилища данных других микросервисов ему не известны и для него не доступны. «Угнать» данные другого микросервиса, напрямую обратившись за ними в хранилище данных, невозможно. Единственный способ получить данные из микросервиса и передать в него новые данные – взаимодействовать с ним через публичный интерфейс.
Среди достоинств синхронных MOA – их независимость. Например, показанный выше микросервис Customers может обновиться в любой момент, когда ему это удобно. Нет никаких внешних зависимостей, которые требовалось бы к этому приспосабливать. Пока микросервис не меняет своего публичного интерфейса, а также структуру тех данных, которые он предполагает потреблять из запроса и возвращать в качестве отклика, риск сломать всю архитектуру MOA минимален.
По самой своей природе архитектура MOA такова, что сама поддерживает собственную структурную целостность. Поскольку сам микросервис несет собственные данные, его работа не затрагивает хранилищ данных других сервисов. Поскольку микросервис представлен в виде множества HTTP URL и связанных с ними структур данных, построенных по принципу запрос-отклик, границы интерфейса у микросервиса четко определены.
Синхронные MOA становятся все популярнее. Интерфейсы многих синхронных MOA основаны на парадигме REST, этот стиль в ходу с 2000 года. Но, при всей популярности, у MOA есть недостаток: малая скорость работы. Потребители синхронного микросервиса никогда не будут работать быстрее, чем этому микросервису удается справляться с запросами и откликами. Это может быть серьезной помехой, особенно при работе с микросервисами, чьи процессы требуют много времени на выполнение. Пример – сложный аналитический сервис, потребляющий и обрабатывающий терабайты данных. Немногие клиенты согласятся сидеть и ждать несколько минут кряду, пока сервис завершит работу. Было бы удобнее сообщить микросервису, какую работу нужно выполнить, а затем получить уведомление о готовности результатов.
В подобных ситуациях удобнее применять асинхронный подход к проектированию микросервисов.
Асинхронные микросервисно-ориентированные приложения
На рисунке 3 ниже показана асинхронная реализация MOA, где межсервисная коммуникация обеспечивается в виде обмена сообщениями между сторонами, вовлеченными в работу. Как правило, такое взаимодействие называется «выстрелил и забыл».
Рисунок 3: Асинхронная архитектура MOA основана на обмене сообщениями
В асинхронной архитектуре MOA сообщения могут генерироваться произвольно, либо в ответ на заданное событие. Например, когда (как показано на рисунке выше) в микросервисе Orders создается заказ, этот сервис может опубликовать событие orders_created и поместить его в сопутствующую очередь сообщений, которую слушает другой микросервис, биллинговый (на рисунке не показан) и принимает входящие сообщения. Биллинговый микросервис подхватывает сообщение с информацией о заказе и обрабатывает его таким образом, который релевантен с точки зрения биллинга.
Достоинство асинхронного подхода к проектированию микросервисно-ориентированных приложений в том, что в такой системе не бывает узких мест и, следовательно, она крайне эффективна. Недостаток в том, что такую систему очень сложно создать, а затем управлять ею.
Для крупномасштабных асинхронных систем, таких как Uber, в порядке вещей обрабатывать тысячи сообщений в секунду. Отладка такой системы сложна, поскольку у ее рабочих процессов нет четко прослеживаемых траекторий. Речь не идет о том, что сначала выполняется одно действие, а затем другое; логика срабатывает в зависимости от полученного сообщения, то есть, что угодно может произойти когда угодно.
Об этом следует помнить, прорабатывая стратегии тестирования. Например, непрактична асинхронная система, производительность которой зависит от времени запроса и отклика, так как однозначного соответствия «один запрос-один отклик» не будет никогда.
Гибридные микросервисно-ориентированные приложения
Сбалансированный подход к реализации микросервисно-ориентированного приложения – гибридный. Сервисы одновременно являются и синхронными, то есть, между ними поддерживается прямая коммуникация запрос-отклик, и в то же время асинхронной; то есть, часть сообщений генерируется вместе с синхронным обменом сообщениями или в результате такого обмена.
На рисунке 4 проиллюстрированы паттерны коммуникации, используемые при гибридном подходе к микросервисно-ориентированным приложениям. Микросервис Customers представлен и в виде URL, связанного с HTTP-сервером и в виде очереди в брокере сообщений.
Рисунок 4: Гибридный подход к проектированию микросервисно-ориентированных приложений, в котором используются как синхронные, так и асинхронные варианты коммуникации между сервисами и потребителями.
К микросервису можно добавить клиента, воспользовавшись стандартным взаимодействием типа запрос-отклик по HTTP. Происходит получение и обработка запроса, затем генерируется отклик. Однако прежде, чем будет сгенерирован отклик, сообщение с информацией о новом клиенте публикуется в сопутствующей очереди сообщений, так, чтобы его могли потреблять другие заинтересованные сервисы. Информация, отправляемая в очередь сообщений, может быть той же, что сгенерирована в HTTP-отклике, либо немного иной, на усмотрение микросервиса. Все зависит от того, как именно спроектирован микросервис, а также от соглашений об уровне качества обслуживания, которые должны выполняться данным микросервисом.
GraphQL – это технология API, поддерживающая одновременно синхронную и асинхронную коммуникацию между потребителем и сервисом. Подробнее об этой технике и подписках GraphQL рассказано здесь.
Важнейшая черта гибридного подхода заключается в том, что в нем сочетаются достоинства обоих других подходов. Но есть и сопутствующие недостатки, в частности, потенциальные узкие места, снижающие производительность, и дополнительная сложность, связанная с необходимостью поддержки двух принципиально разных типов интерфейсов, используемых микросервисом «на вход» и «на выход».
Какие сложности возникают при проектировании тестов для микросервисов
Что касается тестирования таких приложений, в первую очередь необходимо помнить, что весьма редко случается, чтобы один микросервис совместно использовался несколькими MOA. Как правило, микросервис – один из многих в конкретной предметной области в рамках приложения. Достоинство микросервисно-ориентированного подхода к проектированию архитектуры приложения – ускоренная передача кода в продакшен и отдача от него. Так, в Netflix выполняется более 4 000 развертываний в день.) Такая скорость релизов просто невозможна в среде традиционных монолитных приложений.
Также необходимо помнить, что тестирование MOA должно происходить как на микроуровне, так и на макроуровне.
Тестирование на микроуровне
На микроуровне каждый сервис должен быть досконально протестирован в пределах своей зоны ответственности. Согласно некоторым трактовкам, границей микросервиса считается функция.
Выйти за рамки традиционного модульного тестирования
Целесообразно уделить особое внимание функции внутри микросервиса, учитывая нарастающую популярность бессерверной парадигмы, согласно которой микросервис нужно представлять только как единственную функцию. Но многие практикующие тестировщики при работе с микросервисами склонны ограничиваться модульными тестами. Тогда как модульный тест нормально покрывает единственную функцию, работающую в очень ограниченных тестовых условиях, микросервис рассчитан на обслуживание аудитории в рамках всего Веба. Поэтому условия тестирования должны быть экстремальными.
Например, в рамках хорошего теста на микроуровне можно одновременно прогнать сто тысяч экземпляров микросервиса и посмотреть, как они поведут себя в таком масштабе. Недостаточно за раз проверять всего одну функцию, применяя к ней единственный модульный тест. Необходимо прогонять такие тесты на тысячах экземпляров функции одновременно, с учетом показателей хостинговой среды, в которой придется работать.
Тестируйте единицу развертывания
Наряду с тестированием функциональности микросервиса, также необходимо позаботиться о тестировании единицы развертывания, в рамках которой происходит релиз микросервиса. Как правило, микросервисы развертываются в виде контейнеров в рамках той или иной технологии оркестрации, например, Kubernetes или Docker Swarm. Важный аспект оркестрации контейнеров – обеспечение долговременной устойчивости микросервисов.
Считается, что микросервисы могут отваливаться по целому ряду причин, как из-за отказа хоста, так и из-за ошибок самого микросервиса. Вполне нормально, что в ходе одновременной эксплуатации тысяч контейнеров возникают какие-то текущие неисправности. Важность тестирования в том, что правильный выход микросервиса из игры не менее важен, чем его корректное функционирование. Тесты на микроуровне гарантируют, что микросервис будет аккуратно оживать и аккуратно умирать, при любом масштабе системы.
Убедитесь, что абсолютно все происходящее у вас логируется
Тесты также должны гарантировать, что все существенные события, происходящие в микросервисе, как следует логируются – и, что не менее важно, эти записи логов можно понять. В мире микросервисов записи логов очень важны, в особенности это касается асинхронных MOA, где нет последовательного выполнения поведений. Зачастую только данные логов помогут вам осмыслить, что же творится в приложении.
Тестирование на макроуровне
Независимо от того, является ли MOA синхронным, асинхронным или гибридным, ему показан режим тщательного тестирования. При тестировании микросервисов на макроуровне необходимо убедиться, что два аспекта не вызывают нареканий: межсервисная коммуникация и процессы развертывания.
Обеспечение разумной межсервисной коммуникации
Микросервисы по определению независимы друг от друга. Они определяют, что им делать, исходя из получаемой ими информации, поэтому точность межсервисной коммуникации критически важна для целостной эксплуатации микросервисно-ориентированного приложения.
Обеспечение межсервисной коммуникации означает организацию того, чтобы правильная информация приходила откуда нужно и уходила куда нужно. Тесты должны позволять отслеживать, как происходит обмен сообщениями, и как они обрабатываются. Это верно как для коммуникации по HTTP в режиме «запрос-отклик», так и для обмена асинхронными сообщениями, распространяемыми через брокер сообщений. Тестирование должно помочь убедиться, что поддерживаются форматы сообщений, обеспечивающие положительный путь работы системы, а неверно отформатированные сообщения отклоняются, причем с достаточными объяснениями (а не просто с ошибкой «плохое сообщение»).
Тестирование непрерывной интеграции и непрерывного развертывания
Здраво организованные процессы непрерывной интеграции и непрерывного развертывания (CI/CD) важны в любой парадигме разработки ПО, но, когда речь заходит о микросервисных приложениях, эффективный, точный и быстрый процесс CI/CD критически важен. MOA могут проходить ревизию в темпе сотен обновлений ежедневно, поэтому один микросервис, сборка которого запаздывает, может стать узким местом и затормозить весь процесс релиза.
Наилучший способ от этого перестраховаться – дать тестированию конвейера CI/CD тот же приоритет, что и любому другому высокоуровневому режиму тестирования. Выявление и исправление таких проблем как замедленная сборка микросервисов из-за артефактов в коде, медленное предоставление сред выполнения, в которых хостятся микросервисы, а также медленное поднятие уже развернутых микросервисов – необходимые предпосылки для обеспечения работоспособности конвейера CI/CD. Даже если микросервис сложен как шаттл, от него будет мало пользы, если вы не сможете быстро развертывать и пускать в ход операционные единицы.
Заключение
Микросервисы – это настоящий джокер. Микросервисно-ориентированные приложения обеспечивают гибкость и скорость, необходимые для вывода новых фич в онлайн практически с молниеносной скоростью. Большие предприятия, занятые поддержкой миллионов пользователей, усвоили это уже сегодня, но день ото дня все больше компаний берут на вооружение этот архитектурный стиль, когда их приложения достигают масштабов, сравнимых с размерами всего веба.
Хотя многие компании всерьез пытаются внедрить дух микросервисно-ориентированной архитектуры в свои процессы разработки, для тестирования этих MOA зачастую применяются практики, исходно предназначенные для монолитных приложений. Это недальновидный подход.
Напротив, компании должны осваивать современные приемы тестирования, рассчитанные на обеспечение независимости микросервисов и динамичности тех приложений, в которых эти микросервисы используются. Когда командам разработчиков и тестировщикам удается синхронизированно подходить к воплощению принципов, лежащих в основе проектирования микросервисных приложений, вся компания в гораздо большей степени может опираться на сильные стороны микросервисов.