В последнее десятилетие получил распространение новый тип архитектуры приложений, т.н. микросервисная архитектура. Он представляет собой набор независимых сервисов. Основные характеристики микросервисов:
- автоматическое развертывание;
- бизнес-логика приложения связана с приемниками сообщений, endpoints, а не с шиной данных, как было в монолитных приложениях;
- язык программирования микросервиса не зависит от языков других микросервисов;
- данные, c которыми работает микросервис, могут быть не связаны с данными других микросервисов;
- данные передаются, как правило, по шине HTTP, т.е. микросервисы имеют веб-интерфейс;
- развертывание микросервисов производится, как правило, в облаке, в полностью автоматизированной среде.
Принципы проектирования микросервисов впервые были применены в проектировании системы Unix. Микросервисы имеют четкую физическую границу. Благодаря этой особенности, они могут масштабироваться независимо друг от друга и быть написанными на разных языках программирования. Они могут разрабатываться разными командами программистов.
Микросервисы используют библиотеки функций. Основное отличие библиотек и микросервисов состоит в том, что библиотеки вызываются в том же процессе, что и программа, которая их вызвала, а микросервис вызывается в отдельном процессе. Поэтому, при изменениях в одной библиотеке необходимо повторно развертывать все приложение. Когда происходят изменения в коде одного микросервиса, то нужно повторно развернуть только этот микросервис.
Между собой микросервисы взаимодействуют с помощью веб-запросов, Remote Procedure Call. Механизм удаленных вызовов позволяет избежать проблем инкапсуляции данных. В монолитных приложениях, наоборот, всегда были проблемы с использованием данных, какая функция должна быть вызвана, внешняя или внутренняя, если они имеют одинаковые названия, какая переменная должна быть использована, локальная или глобальная, были еще проблемы с видимостью переменных. Тем, кто писал программы на языке Си, такие проблемы знакомы. Микропроцессорная архитектура позволила решить эти проблемы, но при этом увеличилось время обращения к данным, т.к. это всегда внешний вызов через веб-интерфейс.
Поскольку структура команды разработки и тестирования полностью копирует архитектуру приложения, по закону Мелвина Конвея, то при использовании микросервисной архитектуры программа разбивается на сервисы, в соответствии с потребностями бизнеса. Микросервис имеет полный набор функций для решения одной бизнес-задачи, имеет свое хранилище данных, API для взаимодействия с другими сервисами. Соответственно разбивается и команда разработчиков и тестировщиков. Поэтому тестировщик должен уметь выполнять кросс-функциональное тестирование интерфейса пользователя UX, баз данных и программного интерфейса API. Для тестирования межсервисного взаимодействия нужно разбираться в структуре всей программы, знать бизнес-задачи, т.е. быть готовым заниматься менеджментом проекта.
Согласитесь, что проблем для тестировщика при таком подходе к проектированию программ прибавляется, повышается его экспертность, по сравнению с тестированием монолитного приложения, когда можно не вникать в процесс а повторно тестировать одно и то же много раз, при внесении небольших изменений в разрабатываемый проект.
Если у Вас есть свой опыт тестирования микросервисных приложений, пожалуйста, поделитесь в комментариях.
Напоминаю, что для подписчиков есть видео и ссылки на полезные материалы в закрепленном сообщении.