Неспособность добиться успеха и добиться успеха в случае неудачи

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, но вы все равно можете найти другие полезными.

В будущем будет добавлено больше функций с большим количеством настраиваемых параметров!

Предложения

Буду признателен, если вы поделитесь своим мнением о проекте и сочтете его полезным.

Спасибо за прочтение! 😃

Надеюсь, вам понравилась эта статья и введение в концепцию прокси-сервера Хаоса.

Хотя здесь я использовал свой личный проект, эту концепцию невероятно просто реализовать. Не стесняйтесь брать мой проект и форкнуть его или просто создавать свою собственную реализацию!