Поделиться через

Устойчивость и высокий уровень доступности в микрослужбах

Подсказка

Это фрагмент из электронной книги «Архитектура микрослужб .NET для контейнеризованных приложений .NET», доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать в формате PDF

Архитектура микросервисов .NET для приложений .NET в контейнерах, миниатюра обложки электронной книги.

Устранение непредвиденных сбоев является одной из самых сложных проблем, особенно в распределенной системе. Большая часть кода, на который разработчики пишут, включает обработку исключений, и это также место, где больше всего времени тратится на тестирование. Проблема более сложная, чем просто написание кода для обработки сбоев. Что происходит, когда компьютер, на котором работает микрослужба, выходит из строя? Не только необходимо обнаружить этот сбой микрослужбы (что само по себе является сложной задачей), но и нужно что-то, чтобы перезапустить микрослужбу.

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

Проблемы устойчивости усугубляются во время других сценариев, таких как при сбоях во время обновления приложения. Микрослужба, работающая с системой развертывания, должна определить, может ли она продолжать переходить к более новой версии или вместо этого откатить к предыдущей версии для поддержания согласованного состояния. Такие вопросы, как наличие достаточного количества компьютеров, чтобы продолжать двигаться вперед и как восстановить предыдущие версии микрослужбы, необходимо учитывать. Этот подход требует от микрослужбы выдавать сведения о работоспособности, чтобы общее приложение и оркестратор могли принимать эти решения.

Кроме того, устойчивость связана с тем, как должны вести себя облачные системы. Как уже упоминалось, облачная система должна принимать сбои и пытаться автоматически восстановить их. Например, в случае сбоев сети или контейнеров клиентские приложения или клиентские службы должны иметь стратегию повтора отправки сообщений или повторных запросов, так как во многих случаях ошибки в облаке являются частичными. В разделе "Реализация устойчивых приложений" в этом руководстве описывается, как обрабатывать частичный сбой. В нем описываются такие методы, как повторные попытки с экспоненциальной задержкой или шаблоном Circuit Breaker в .NET с помощью таких библиотек, как Polly, которые предлагают разнообразные стратегии для обработки этой темы.

Управление здоровьем и диагностика в микросервисах

Это может показаться очевидным, и это часто упускается из виду, но микрослужба должна сообщить о его работоспособности и диагностике. В противном случае есть мало аналитических сведений с точки зрения операций. Корреляция диагностических событий между различными независимыми службами и устранение несоответствий машинных часов для понимания последовательности событий представляет собой сложную задачу. Таким же образом, как вы взаимодействуете с микрослужбой по согласованным протоколам и форматам данных, существует необходимость стандартизации процесса регистрации событий о работоспособности и диагностике, которые в конечном итоге становятся частью хранилища событий для запросов и просмотра. В подходе к микрослужбам важно, чтобы разные команды согласились с одним форматом ведения журнала. В приложении должен быть согласованный подход к просмотру диагностических событий.

Медицинские проверки

Работоспособности отличается от диагностики. Работоспособность — это микрослужба, сообщающая о текущем состоянии для принятия соответствующих действий. Хорошим примером является работа с механизмами обновления и развертывания для поддержания доступности. Хотя служба в настоящее время может быть неработоспособной из-за сбоя процесса или перезагрузки компьютера, служба может по-прежнему работать. Последнее, что вам нужно, это только усугубить ситуацию, выполнив обновление. Лучший подход — сначала провести расследование или дать микрослужбе время на восстановление. События здоровья микрослужбы помогают нам принимать обоснованные решения и, по сути, помогают создавать самовосстанавливающиеся службы.

В разделе «Реализация проверок работоспособности в ASP.NET Core служб» этого руководства мы объясняем, как использовать новую библиотеку ASP.NET HealthChecks в микрослужбах, чтобы они могли сообщать своё состояние в службу мониторинга для принятия соответствующих мер.

Вы также можете использовать отличную библиотеку с открытым исходным кодом с именем AspNetCore.Diagnostics.HealthChecks, доступную на сайте GitHub и в виде пакета NuGet. Эта библиотека также выполняет проверку работоспособности, но с необычным подходом, она обрабатывает два типа проверок:

  • Liveness: проверяет, жив ли микрослужба, то есть, если она может принимать запросы и отвечать.
  • Готовность: Проверяет, готовы ли зависимости микрослужбы (база данных, службы очередей и т. д.), чтобы микрослужба могла делать то, что она должна.

Использование потоков событий для диагностики и журналов

Журналы предоставляют сведения о выполнении приложения или службы, включая исключения, предупреждения и простые информационные сообщения. Обычно каждый журнал находится в текстовом формате с одной строкой на событие, хотя исключения также часто показывают трассировку стека между несколькими строками.

В монолитных серверных приложениях можно записывать журналы в файл на диске (файл журнала), а затем анализировать его с помощью любого средства. Так как выполнение приложения ограничено фиксированным сервером или виртуальной машиной, обычно это не слишком сложно для анализа потока событий. Однако в распределенном приложении, где несколько служб выполняются во многих узлах в кластере оркестратора, возможность сопоставить распределенные события является проблемой.

Приложение на основе микрослужб не должно пытаться хранить выходной поток событий или файлов журнала самостоятельно, а даже не пытаться управлять маршрутизацией событий в центральное место. Он должен быть прозрачным, то есть каждый процесс должен просто записывать свой поток событий в стандартный вывод, который будет собираться инфраструктурой среды выполнения, где он выполняется. Примером этих маршрутизаторов потоков событий является Microsoft.Diagnostic.EventFlow, который собирает потоки событий из нескольких источников и публикует его в выходных системах. Они могут включать простые стандартные выходные данные для среды разработки или облачных систем, таких как Azure Monitor и диагностика Azure. Существуют также хорошие сторонние платформы анализа журналов и средства, которые могут выполнять поиск, оповещение, отчет и мониторинг журналов, даже в режиме реального времени, например Splunk или ПО промежуточного слоя.

Оркестраторы управляют сведениями о работоспособности и диагностике

При создании приложения на основе микрослужб необходимо иметь дело с сложностью. Конечно, одна микрослужба проста для решения, но десятки или сотни типов и тысячи экземпляров микрослужб является сложной проблемой. Это не просто создание архитектуры микрослужб— вам также требуется высокий уровень доступности, адресность, устойчивость, работоспособность и диагностика, если вы планируете иметь стабильную и сплоченную систему.

Схема кластеров, предоставляющих платформу поддержки для микрослужб.

Рис. 4-22. Платформа Микрослужб является основой для управления работоспособностью приложения

Сложные проблемы, показанные на рис. 4-22, трудно решить самостоятельно. Команды разработчиков должны сосредоточиться на решении бизнес-проблем и создании пользовательских приложений с помощью подходов на основе микрослужб. Они не должны сосредоточиться на решении сложных проблем инфраструктуры; Если бы они сделали, стоимость любого приложения на основе микрослужб будет огромной. Таким образом, существуют платформы, ориентированные на микрослужбы, называемые оркестраторами или кластерами микрослужб, которые пытаются решить сложные проблемы создания и запуска службы и эффективного использования ресурсов инфраструктуры. Такой подход снижает сложность создания приложений, использующих подход микрослужб.

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

Дополнительные ресурсы

НазадДалее