Устойчивые функции рекомендации и средства диагностики
В этой статье описаны некоторые рекомендации при использовании Устойчивые функции. В нем также описываются различные средства для диагностики проблем во время разработки, тестирования и использования в рабочей среде.
Рекомендации
Использование последней версии расширения Устойчивые функции и пакета SDK
Существует два компонента, которые приложение-функция использует для выполнения Устойчивые функции. Одним из них является пакет SDK для Устойчивые функции, который позволяет создавать оркестратор, действия и функции сущностей с помощью целевого языка программирования. Другим является расширение Устойчивый, который является компонентом среды выполнения, который фактически выполняет код. За исключением приложений в процессе .NET, пакет SDK и расширение имеют независимые версии.
Оставаясь в курсе последних расширений и пакета SDK, вы гарантируете, что ваше приложение получает преимущества от последних улучшений производительности, функций и исправлений ошибок. Обновление до последних версий также гарантирует, что корпорация Майкрософт может собирать последние диагностические данные телеметрии, чтобы ускорить процесс исследования при открытии обращения в службу поддержки в Azure.
- Сведения о получении последней версии расширения функций см. в статье об обновлении версии расширения устойчивых функций.
- Чтобы убедиться, что вы используете последнюю версию пакета SDK, проверка диспетчер пакетов используемого языка.
Придерживаться ограничений кода Устойчивые функции
Поведение воспроизведения кода оркестратора ограничивает тип кода, который может быть записан в функцию оркестратора. Пример ограничения заключается в том, что функция оркестратора должна использовать детерминированные API, чтобы каждый раз, когда он воспроизводился, он создает один и тот же результат.
Примечание.
Анализатор Устойчивые функции Roslyn — это анализатор динамического кода, который позволяет пользователям C# придерживаться Устойчивые функции определенных ограничений кода. Сведения о том, как включить анализатор Roslyn в Visual Studio и Visual Studio Code, см. в Устойчивые функции Анализатор Roslyn.
Ознакомьтесь с параметрами Функции Azure производительности языка программирования
Используя параметры по умолчанию, выбранная языковая среда выполнения может накладывать строгие ограничения параллелизма для функций. Например, разрешая выполнять только 1 функцию за раз на данной виртуальной машине. Эти ограничения обычно могут быть расслаблены путем настройки параллелизма и параметров производительности языка. Если вы хотите оптимизировать производительность приложения Устойчивые функции, вам потребуется ознакомиться с этими параметрами.
Ниже приведен неисчерпающий список некоторых языков, которые часто используются для точной настройки параметров производительности и параллелизма, а также их рекомендаций по выполнению этих действий.
Гарантия уникальных имен Концентратора задач для каждого приложения
Несколько приложений устойчивых функций могут совместно использовать одну и ту же учетную запись хранения. По умолчанию имя приложения используется в качестве имени концентратора задач, что гарантирует, что случайное совместное использование центров задач не произойдет. Если необходимо явно настроить имена центров задач для приложений в host.json, необходимо убедиться, что имена уникальны. В противном случае несколько приложений будут конкурировать за сообщения, что может привести к неопределенному поведению, включая оркестрации, которые неожиданно "застряли" в состоянии ожидания или выполнения.
Единственным исключением является развертывание копий одного приложения в нескольких регионах. В этом случае для копирования можно использовать один и тот же концентратор задач.
Следуйте инструкциям при развертывании изменений кода для запуска оркестраторов
Неизбежно, что функции будут добавлены, удалены и изменены в течение времени существования приложения. Примеры распространенных критических изменений включают изменение подписей действий или функций сущностей и изменение логики оркестратора. Эти изменения являются проблемой, когда они влияют на оркестрации, которые по-прежнему выполняются. При неправильном развертывании изменения кода могут привести к сбою оркестрации с недетерминированной ошибкой, зависание на неопределенный срок, снижение производительности и т. д. Ознакомьтесь с рекомендуемыми стратегиями устранения рисков при внесении изменений в код, которые могут повлиять на выполнение оркестрации.
Сохранение входных и выходных данных функции как можно меньше
Вы можете столкнуться с проблемами с памятью, если вы предоставляете большие входные и выходные данные в Устойчивые функции API.
Входные и выходные данные для Устойчивые функции API сериализуются в журнал оркестрации. Это означает, что большие входные и выходные данные могут со временем значительно способствовать росту журнала оркестратора, что рискует вызвать исключения памяти во время воспроизведения.
Чтобы снизить влияние больших входных данных и выходных данных в API, можно делегировать некоторые действия под оркестраторам. Это помогает сбалансировать нагрузку памяти журнала от одного оркестратора до нескольких, поэтому сохраняя объем памяти отдельных историй небольшим.
Это сказало, что рекомендуется иметь дело с большими данными, чтобы сохранить его во внешнем хранилище и только материализовать эти данные внутри действий, когда это необходимо. При принятии этого подхода вместо передачи данных в качестве входных и /или выходных данных api Устойчивые функции можно передать некоторый упрощенный идентификатор, позволяющий извлекать эти данные из внешнего хранилища при необходимости в действиях.
Сохранение небольших данных сущностей
Как и для входных и выходных данных для Устойчивые функции API, если явное состояние сущности слишком велико, могут возникнуть проблемы с памятью. В частности, состояние сущности необходимо сериализовать и десериализировать из хранилища по любому запросу, поэтому большие состояния добавляют задержку сериализации к каждому вызову. Поэтому, если сущности нужно отслеживать большие данные, рекомендуется выгрузить данные во внешнее хранилище и отслеживать некоторый упрощенный идентификатор в сущности, который позволяет материализовать данные из хранилища при необходимости.
Настройка параметров параллелизма Устойчивые функции
Один рабочий экземпляр может одновременно выполнять несколько рабочих элементов, чтобы повысить эффективность. Однако обработка слишком большого количества рабочих элементов одновременно рискует исчерпанием ресурсов, таких как емкость ЦП, сетевые подключения и т. д. Во многих случаях это не должно быть проблемой, так как масштабирование и ограничение рабочих элементов обрабатываются автоматически. Это сказало, что если у вас возникли проблемы с производительностью (например, оркестраторы, занимает слишком много времени, зависли в ожидании и т. д.) или выполняются проверки производительности, можно настроить ограничения параллелизма в файле host.json.
Примечание.
Это не замена для точной настройки параметров производительности и параллелизма среды выполнения языка в Функции Azure. Параметры параллелизма Устойчивые функции определяют только то, сколько работ можно назначить определенной виртуальной машине за раз, но не определяет степень параллелизма в обработке, которая работает внутри виртуальной машины. Последний требует точной настройки параметров производительности среды выполнения языка.
Использование уникальных имен для внешних событий
Как и в случае с функциями действий, внешние события имеют по крайней мере однократную гарантию доставки. Это означает, что при определенных редких условиях (которые могут возникать во время перезапуска, масштабирования, сбоя и т. д.), приложение может получать дубликаты одного и того же внешнего события. Поэтому рекомендуется, чтобы внешние события содержали идентификатор, который позволяет вручную де дублироваться в оркестраторах.
Примечание.
Поставщик хранилища MSSQL использует внешние события и обновляет состояние оркестратора транзакционно, поэтому в серверной части не должно быть риска повторяющихся событий, в отличие от поставщика хранилища по умолчанию служба хранилища Azure. Тем не менее, рекомендуется, чтобы внешние события имели уникальные имена, чтобы код переносимый между внутренними серверами.
Инвестиции в стресс-тестирование
Как и в случае с любой производительностью, идеальные параметры параллелизма и архитектуры приложения в конечном итоге зависят от рабочей нагрузки вашего приложения. Поэтому рекомендуется, чтобы пользователи инвестировали в использование средств тестирования производительности, которые имитируют ожидаемую рабочую нагрузку и используют ее для выполнения экспериментов производительности и надежности для своего приложения.
Избегайте конфиденциальных данных во входных, выходных данных и исключениях
Входные и выходные данные (включая исключения) в api-интерфейсы Устойчивые функции постоянно сохраняются в выбранном поставщике хранилища. Если эти входные данные, выходные данные или исключения содержат конфиденциальные данные (например, секреты, строка подключения, личную информацию и т. д.), то любой пользователь с доступом на чтение к ресурсам поставщика хранилища сможет получить их. Чтобы безопасно справиться с конфиденциальными данными, рекомендуется получить эти данные в функциях действий из Azure Key Vault или переменных среды, а также никогда не передавать эти данные непосредственно оркестраторам или сущностям. Это должно помочь предотвратить утечку конфиденциальных данных в ресурсы хранилища.
Примечание.
Это руководство также относится к CallHttp API оркестратора, который также сохраняет полезные данные запроса и ответа в хранилище. Если целевые конечные точки HTTP требуют проверки подлинности, которые могут быть конфиденциальными, рекомендуется реализовать http-вызов внутри действия или использовать встроенную поддержку управляемого удостоверения, которая CallHttpне сохраняет учетные данные в хранилище.
Совет
Аналогичным образом избежать ведения журнала, содержащих секреты, как любой пользователь с доступом на чтение к журналам (например, в приложении Аналитика), сможет получить эти секреты.
Средства диагностики
Существует несколько средств, которые помогут вам диагностировать проблемы.
Устойчивые функции и журналы платформы устойчивых задач
Расширение Устойчивые функции
Устойчивое расширение выдает события отслеживания, позволяющие отслеживать сквозное выполнение оркестрации. Эти события отслеживания можно найти и запросить на портале Azure с помощью средства Аналитика Application Insights. Подробные сведения об отслеживании можно настроить в logger разделе "Функции 1.x" или logging "Функции 2.0" файла host.json. См . сведения о конфигурации.
Платформа устойчивых задач
Начиная с версии 2.3.0 расширения "Устойчивые функции" можно также собирать создаваемые базовой платформой устойчивых задач (DTFx) журналы. Узнайте , как включить эти журналы.
Портал Azure
Диагностика и решение проблем
Диагностика приложений-функций Azure — это полезный ресурс портал Azure для мониторинга и диагностики потенциальных проблем в приложении. Он также предоставляет рекомендации по устранению проблем на основе диагноза. См. сведения о диагностике приложений-функций Azure.
трассировки оркестрации Устойчивые функции
портал Azure предоставляет сведения о трассировки оркестрации, помогающие понять состояние каждого экземпляра оркестрации и отслеживать сквозное выполнение. При просмотре списка функций в приложении Функции Azure вы увидите столбец Монитора, содержащий ссылки на трассировки. Для получения этих сведений необходимо включить приложения Аналитика.
Расширение монитора Устойчивые функции
Это расширение Visual Studio Code, которое предоставляет пользовательский интерфейс для мониторинга, управления и отладки экземпляров оркестрации.
Анализатор Roslyn
Анализатор roslyn Устойчивые функции — это анализатор динамического кода, который позволяет пользователям C# придерживаться Устойчивые функции определенных ограничений кода. Сведения о том, как включить анализатор Roslyn в Visual Studio и Visual Studio Code, см. в Устойчивые функции Анализатор Roslyn.
Поддержка
Для вопросов и поддержки вы можете открыть проблему в одном из репозиториев GitHub ниже. При создании отчетов об ошибке в Azure, включая такие сведения, как идентификаторы затронутых экземпляров, диапазоны времени в формате UTC, показывающие проблему, имя приложения (если возможно) и регион развертывания значительно ускорит исследования.