27/07/2022

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

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

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

Особенности

  • дает простоту и независисмость деплоймента; Мы можем деплоить каждый микросервис отдельно. Например, если есть изменения в микросервисе А, то мы деплоим только его и нам не нужно передеплаивать UI или другие микросервисы;

  • каждый микросервис имеет одну свою собственную, как правило простую функцию; и как правило, поддерживается одной командой, иногда даже из 1-2 человек;

  • отсутсвие иерархической структуры; микросервис может комуницировать с БД или с другим микросервисом, нет какой то четкой структуры.

  • микросервисы взаимодействуют друг с другом напрямую;

Преимущества

  • микросервисы взаимодействуют по очень легковесным сетевым протоколам, как правило это REST;

  • мы можем в пределах одного приложения использовать какие угодно технологии и языки программирования; например, один микросервис на java, а другой на nodejs и это отлично работает;

  • простота масштабирования микросервисной архитектуры;

Проблемы для автоматизации тестирования

  • каждый микросервис имеет собственную ценность для заказчика если монолитное приложение мы тестируем и используем все целиком, то в тут каждый микросервис имеет свою ценность; и не обязательно его использовать с тем UI клиентом, который был написан изначально, клиент может захотеть использовать другой клиент, мобильный клиент или переписать UI; нам важно, чтобы микросервис сам по себе выполнял те функции, которые на него возложены;

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

  • нужно также тестировать взаимодействие между микросервисами

Архитектура для автотестирования

  • тесты на java
  • конфигурация spring
  • билд через Maven
  • BDD - Cucumber
  • взаимодействие с UI - Selenium(Selenide)
  • взаимодействие с BackEnd - RestAssured
  • хранилице тестов - Google Cloud Platform
  • управление контейнерами - Kubernetes
  • для запуска тестов - Selenoid
  • для отчетности - Report Portal, Allure

Unit тесты пишутся разработчиками.

Integrartion тестирование - разбито на 2 слоя: слой клиента, который работает как аналог UI, отправляет запросы и принимает ответы и уровень тестов, где происходят проверки.

UI тестирование - имеет 3 слоя: уровень страниц (pages), уровень шагов (steps), уровень тестов (tests)

Далее UI тесты подключаются к Selenoid - это браузеры, которые запускаются в докер контейнерах и оркестрируются Kubernetes' ом. Чтобы включить ui тесты в pipeline.

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

Для решения этой проблемы мы подключаем клиентскую часть Backend тестов через dependency в Мавен проект UI тестов, для того чтобы создать тестовые данные или ускорить работу UI тестов(например для быстрого логина в приложение).

Для проверки взаимодействия микросервисов, мы подключаем клиентскую часть backEnd тестов для микросервиса 1 к клиентской часть backend тестов микросервиса 2 и проверяем.

Для предоставления результатов используется Allure репорт, он используется для внутренних нужд.

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

Selenoid

  • доступен сразу из коробки

  • есть 2 решения:

    1. деплоится на виртуальную машину
    2. деплоится в kubernetes кластер если есть cloud платформа то можно бытсро с помощью seleonoid поднять браузер в cloud'е
  • браузеры стартуют очень быстро (~30сек)

  • надежность браузеры сами закрываются ничего не зависает

  • запись видео

Docker

Docker container - экземпляр Docker Image который содержит три атрибута:

  • docker image
  • среда запуска
  • стандартный набор инструкций

Преимущества

  • приложения портируемые и стандартно упакованные запустить можно везде где есть docker engine
  • деплоймент простой и повторяемый
  • поддержка микросервисной архитектуры каждый микросервис запакован, изолирован и запускается отдельно

Tools for containers orchestration

  • kubernetes - самый распространненый инструмент
  • docker swarm - нативный tool
  • rancher
  • mesos

Источник информации:

  1. Automation testing solution for micro service architecture