Azure Web API - как общаться между службами

Question

Я в настоящее время разрабатываю архитектуру на основе SOA в Azure, используя разрозненные сервисы Web API (они, вероятно, будут квалифицироваться как Microservices, но я не решаюсь использовать этот термин).

У меня есть служба, которая запускается Azure Scheduler. Он выполняет некоторые «вещи», а затем требует вызова другого веб-API (через HttpClient) для запуска чего-то еще. Для этого мне нужно знать URI второй службы. При работе на местном уровне, это хорошо, так как это что-то вроде

POST http://localhost:1234/2ndService/api/action

Однако, когда я раскрываю к Azure (с использованием только для внутреннего, как уровень доступа), он получает обфусцированный URI, например, http://microsoft-apiapp8cf3d453-39d8-4b3b-ad00-e9d8008a9b58, которые я, очевидно, не могу угадать во время развертывания.

Любые идеи о том, как решить эту проблему? Или я сделал здесь фундаментальную ошибку?

Answer 1

В случае с Azure Web Apps вы всегда можете увидеть такие свойства, которые находятся на панели инструментов веб-приложения, а затем свойства. При развертывании из Visual Studio вы можете установить URL-адрес по своему усмотрению - просто его проверили, и он работает нормально.

Answer 2

Вместо того, чтобы полагаться на общедоступные конечные точки http, вы считали передачу сообщений через queues in Azure Table Services? Это очень просто сделать и будет более надежным, поскольку вы можете использовать встроенные функции, такие как гарантированная доставка сообщений.

Общая идея заключается в том, что служба A выполняет некоторые «вещи», а затем помещает сообщение в очередь ONE. Служба B непрерывно читает из очереди ONE, пока не получит новое сообщение от службы A (или любой другой службы, если на то пошло), а затем выполнит ее «STUFF». Вы можете продолжить цепочку вызовов, подобных этим, другим службам, которые необходимо уведомить.

Если вы хотите более элегантное решение, вы можете посмотреть на использование Service Bus Topics, но концепция в основном такая же.

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

Answer 3

Не очень понятно, какую технологию вы используете - это IaaS VM? Это веб-приложения?

С моей точки зрения, каждая служба должна быть развернута как отдельное веб-приложение (или приложение API, если хотите). Каждое веб-приложение определило свое собственное имя, как в вашемwebapp.azurewebsites.net, поэтому, как только вы предоставили веб-приложение № 1 в Azure, вы знаете его адрес, чтобы его можно было вызывать из веб-приложения № 2.

В во всех случаях вы должны иметь полностью квалифицированные доменные имена, а не локальные/внутренние.