Управление версиями API функций Azure — как структурировать мой код?

Я создал демонстрационное приложение микросервисов, реализованное с помощью Azure Function Apps. Для разделения задач я создал уровень API, бизнес-уровень и уровень данных.

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

После долгих размышлений я решил использовать для своей демонстрации API-версию на основе запросов.

У меня есть вопрос,

Как лучше всего организовать мой код, чтобы облегчить это? Есть ли другой способ организовать мой код для размещения разных версий, кроме использования разных пространств имен/репозиториев?

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

Любая помощь будет оценена по достоинству.


api azure-functions versioning design-principles
person j Doe    schedule 19.02.2019    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Самый простой способ реализовать управление версиями в Функциях Azure — использовать конечные точки. Атрибут HttpTrigger позволяет определить пользовательский маршрут, где вы можете установить ожидаемую версию.

// Version 1 of get users
[FunctionName(nameof(V1UserList))]
public static IEnumerable<UserModel> V1UserList(
[HttpTrigger(AuthorizationLevel.Function, "get", Route = "v1/users")]HttpRequest req, ILogger log)
{
}

// Version 2 of get users
[FunctionName(nameof(V2UserList))]
public static IEnumerable<UserModel> V2UserList(
[HttpTrigger(AuthorizationLevel.Function, "get", Route = "v2/users")]HttpRequest req, ILogger log)
{
}

При изолированном развертывании каждой версии требуется компонент маршрутизатора для перенаправления запросов на правильную конечную точку API.

Компонент маршрутизатора может быть реализован в Azure с использованием различных служб, таких как:

  • прокси-серверы функций Azure: вы можете указать конечные точки на приложение-функция, реализованное другим ресурсом. Вы можете использовать эти прокси-серверы, чтобы разбить большой API на несколько приложений-функций (как в архитектуре микросервисов), при этом предоставляя клиентам единую поверхность API.
  • Управление API :Azure Управление API поддерживает импорт приложений-функций Azure в качестве новых API или добавление их к существующим API. Процесс автоматически создает ключ узла в приложении-функции Azure, который затем назначается именованному значению в службе управления API Azure.

Пример кода для API управления версиями в Функциях Azure

person Ketan    schedule 25.02.2019
comment
К вашему сведению, этот ответ в основном взят отсюда: medium.com/@fbeltrao / - person bytedev; 19.01.2021