Различные серверные конечные точки в API в зависимости от продуктов в Azure API Management

Я абсолютно новичок в управлении API Azure и сомневаюсь в том, как управлять продуктами и API.

Давайте представим этот сценарий: я создаю 3 разных продукта: один для представления моей среды разработки (DEV), второй для представления моей среды предварительной подготовки (PRE) и последний для представления моей производственной среды (PRO). Я создаю несколько API, которые хочу опубликовать в своей среде DEV, а затем продвигать другим. Поэтому мне нужно, чтобы каждый API в каждом продукте указывал на разные серверные службы, поскольку мои серверные службы различаются в каждой среде.

Например: у меня есть 3 разных версии моей серверной службы: ServiceDEV, ServicePRE и ServicePRO. При разработке своего API я использую в качестве серверной службы службу с именем ServiceDEV, поэтому мой API назначается для разработки продукта. Позже я хочу сохранить эту версию DEV для своего API, но я также хочу «развернуть» этот API в Product PRE, чтобы он действовал как фасад для ServicePRE, и то же самое произойдет при продвижении его до PRO.

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

Я не знаю, удовлетворит ли политика мои потребности в этом предмете.

Надеюсь, вы понимаете, что я имею в виду ...

Как я могу справиться с этой ситуацией? Я неправильно фокусирую этот объект? Есть идеи, как это преодолеть?

Спасибо!


person Roberto Rodríguez    schedule 20.06.2018    source источник


Ответы (1)


Если вы последуете этому подходу, вы действительно сможете использовать политики для управления разными бэкэндами для разных продуктов. Вы можете создавать API-интерфейсы, не указывая полностью URL-адрес серверной службы, а затем использовать политику set-backend-service на уровне продукта для прямого вызова соответствующей конечной точки. Одним из ограничивающих факторов этого подхода является то, что любые изменения, которые вы можете захотеть сделать с API в среде разработки (подумайте, измените сигнатуру операции или политики), будут немедленно видны в других средах, а также это единый API во всех их. Если это проблема, рассмотрите возможность наличия дублирующих (трех экземпляров) API-интерфейсов - по одному для каждой среды, а затем переместите их конфигурацию с помощью вызова API Azure.

person Vitaliy Kurokhtin    schedule 25.06.2018
comment
Прекрасный ответ, Виталий. Большое тебе спасибо :-) - person Roberto Rodríguez; 27.06.2018