Неспособность добиться успеха и добиться успеха в случае неудачи
TL; DR: ваши микросервисы уязвимы для непредвиденных сбоев, если службы, от которых они зависят, каким-то образом дают сбой (а вы не справляетесь с этим). Проверьте свои HTTP-микросервисы на неисправность с помощью «Chaos Proxy».
Вот один, который я сделал ранее:
Chaos Engineering - что это такое?
Chaos Engineering - отличная идея - создать автоматизированное решение / инструмент для случайной попытки каким-либо образом взломать систему; в конечном итоге узнать, как система ведет себя в таких ситуациях. Затем вы можете использовать полученные знания, чтобы найти способы сделать систему более отказоустойчивой в условиях этих сбоев в будущем.
Что такое прокси-сервер Хаоса?
Прокси-сервер Хаоса - это служба, к которой могут подключаться ваши микросервисы.
Он направляет трафик к микросервисам реального назначения и возвращает ответы микросервисам через прокси-сервер, но делает это очень ненадежным способом.
Через прокси запросы случайным образом задерживаются и / или случайным образом завершаются ошибкой неожиданным образом - все с единственной целью помочь вам понять, как микросервис реагирует на эти различные условия сбоя.
Зачем кому-то нужен ненадежный HTTP-прокси?
В конце концов все терпит неудачу. Все.
Примите это и примите неудачу. Дизайн на неудачу. Успешно.
Микросервисы часто взаимодействуют с другими сервисами через REST и HTTP. Как ваши микросервисы справляются с ситуацией, когда сервисы, от которых они зависят, неизбежно выходят из строя каким-то непредсказуемым образом?
Ваши микросервисы подвержены непредвиденным сбоям, если службы зависят от сбоев ( и вы не учли сбой или не определили, как ваша служба должна себя вести ).
Почему это полезно?
Недавно я расследовал утечку JDBC соединения в микросервисе.
В современных фреймворках, абстрагируемых от операций JDBC, утечки соединений в наши дни не должно происходить, но, увы, утечка соединения произошла.
Я хотел оценить, насколько устойчивым был микросервис (A) к сбоям и задержкам в другом микросервисе (B), от которого он зависел.
Мне нужен был способ имитировать периодические сбои и задержки в микросервисе «B», пока я выполнял запросы и автоматические регрессионные тесты локально для микросервиса «A».
Я мог получить доступ к микросервису «B» в удаленной среде, но из-за различных ограничений я не мог запустить «B» локально, чтобы попытаться изменить его для выдачи ошибок.
Я не мог найти что-то из существующих, что было бы легким, достаточно простым в настройке, и это выполнило то, что я надеялся достичь.
После некоторой игры родилась первая итерация ClusterFk Chaos Proxy!
Благодаря ClusterFk Chaos Proxy я смог определить, что при достаточно задержанных ответах от микросервиса «B» соединения JDBC в микросервисе «A» будут складываться и оставаться там до тех пор, пока HTTP-запрос был активен - даже если JDBC сделка действительно давно совершена.
Когда причина известна, это открыло ряд возможных решений проблемы (и простой способ проверить их эффективность с помощью прокси-сервера хаоса), например:
- Реализуйте контролируемый тайм-аут по запросу от «A» до «B».
- Реализуйте тайм-аут соединений JDBC и вернитесь в пул соединений.
- Сделайте элементы обработки асинхронными, чтобы поток запроса завершился быстрее.
Прокси-сервер ClusterFk Chaos
Предпосылка проста:
- Настройте локально работающую тестируемую службу так, чтобы она указывала на прокси-сервер Chaos, и настройте прокси-сервер Chaos так, чтобы он указывал на вашу реальную запущенную службу зависимого назначения.
- Включите ClusterFk Chaos Proxy и настройте «стратегию хаоса».
- Используйте свой микросервис (запускайте запросы на нем).
- Наблюдайте, как горит мир (через журналы мониторинга или поведение приложений).
- Необязательно - извлеките уроки из хаоса и внесите изменения, чтобы повысить устойчивость своего микросервиса.
- Повторить.
Когда я впервые собирал Chaos Proxy, я ничего не знал о концепции Chaos Proxy, но решил закончить первую итерацию.
Начало работы
ClusterFk Chaos Proxy находится на DockerHub. Для простой установки:
docker pull andymacdonald/clusterf-chaos-proxy
А затем настройте файл docker-compose
, указав сведения о целевой службе - например, если ваша служба B работает на http://10.0.0.231:8098
:
version: "3.7" services: user-service-chaos-proxy: image: andymacdonald/clusterf-chaos-proxy environment: JAVA_OPTS: "-Dchaos.strategy=RANDOM_HAVOC -Ddestination.hostProtocolAndPort=http://10.0.0.231:8098" ports: - "8080:8080"
Настройте стратегию хаоса согласно проекту README.md :
NO_CHAOS - Request is simply passed through
DELAY_RESPONSE - Requests are delayed but successful (configurable delay)
INTERNAL_SERVER_ERROR - Requests return with 500 INTERNAL SERVER ERROR
BAD_REQUEST - Requests return with 400 BAD REQUEST
RANDOM_HAVOC - Requests generally succeed, but randomly fail with random HTTP status codes and random delays
Тогда просто: docker-compose up
Как только приложение будет запущено, вы можете указать микросервисы, которые вы хотите протестировать, на экземплярах прокси-сервера ClusterFk Chaos (вместо реальных целевых сервисов). Затем просто запустите микросервис и начните его тестирование и использование.
В зависимости от выбранной вами стратегии прокси-сервер будет влиять на вашу стратегию в отношении отправляемых к нему запросов.
Вероятно, самые полезные стратегии - это RANDOM_HAVOC
и DELAY_RESPONSE
, но вы все равно можете найти другие полезными.
В будущем будет добавлено больше функций с большим количеством настраиваемых параметров!
Предложения
Буду признателен, если вы поделитесь своим мнением о проекте и сочтете его полезным.
Спасибо за прочтение! 😃
Надеюсь, вам понравилась эта статья и введение в концепцию прокси-сервера Хаоса.
Хотя здесь я использовал свой личный проект, эту концепцию невероятно просто реализовать. Не стесняйтесь брать мой проект и форкнуть его или просто создавать свою собственную реализацию!