我目前正在Azure中开发基于SOA的架构，使用不同的Web API服务（他们可能有资格作为微服务，但我对使用该术语犹豫不决）。
我有一个由Azure Scheduler触发的服务。它做了一些＆＃34;东西＆＃34;然后需要调用另一个Web API（通过HttpClient）服务来触发别的东西。为此，我需要知道第二个服务的URI。在本地运行时，这很好，因为它类似于
POST http://localhost:1234/2ndService/api/action
但是，当我部署到Azure（使用Internal Only作为访问级别）时，它会获得一个模糊的URI，例如http://microsoft-apiapp8cf3d453-39d8-4b3b-ad00-e9d8008a9b58，我显然无法在部署时猜测。
有关如何解决此问题的任何想法？或者我在这里犯了一个根本性错误？
答案 0 :(得分：2)
您是否考虑过通过queues in Azure Table Services传递邮件，而不是依赖公共http端点？它非常简单，并且会更加强大，因为您可以利用保证消息传递等内置功能。</ p>
总体思路是服务A做了一些“东西”，然后在队列ONE上放置一条消息。服务B从队列ONE连续读取，直到它从服务A（或任何其他服务）获取新消息，然后执行其“STUFF”。您可以继续将此类呼叫链接到需要通知的其他服务。
如果您想要更优雅的解决方案，可以使用Service Bus Topics查看，但概念基本相同。
此外，由于您提到您的体系结构与微服务非常相似，因此您可以查看专为您的方案设计的新Service Fabric。
答案 1 :(得分：0)
对于Azure Web Apps，您可能始终会看到此类属性转到Web应用程序仪表板，然后是属性。从Visual Studio部署时，您可以根据需要设置URL - 只需选中它，它就可以正常工作。
答案 2 :(得分：0)
不太清楚你使用什么技术 - 是IaaS VM吗？它是Web Apps吗？
从我的角度来看，每个服务都应该作为单独的Web应用程序（或API应用程序，如果您需要）部署。每个Web应用程序都在yourwebapp.azurewebsites.net中定义了自己的名称，因此一旦您在Azure中配置了Web App no 1，就会知道它的地址，因此您将从Web App no 2中调用它。
在所有情况下，您应该拥有完全合格的域名，而不是本地/内部域名。