Azure - 在阶段动态发现服务 Web 角色 url
我正在考虑将现有应用程序迁移到 Azure。它将在一个 Web 角色中包含一个 MVC 应用程序，并在另一个 Web 角色中包含一些 WCF 服务。上线后，该网站将位于 http://www.myapp.com，服务将位于 http://api.myapp.com 以及 MVC 应用程序配置为指向 http://api.myapp.com 处的服务。
问题在于将应用程序推送到 Azure 上的“阶段”配置时。我的理解是，每次推送到阶段都会导致服务位于新的 url（类似 http://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/ 之类的随机内容）。在这种情况下，我的 MVC 应用程序发现服务 url 的最佳方式是什么？
一种选择是设置一个 dns 条目，例如 http://stage.api.myapp.com 并更新我的 DNS CNAME 记录，以在每次推送到 stage 时指向新的 Azure staging url，但是... 恶心。
另一种选择是推送到阶段，获取服务的新 URL、MVC 角色的每个实例的 RDC 并手动更新配置。还恶心。
有没有一种简单的方法可以做到这一点？我知道我可以使用 PowerShell 之类的工具自动执行上述一些步骤，但我真的希望 Azure 框架中包含一些东西，可以让这一切变得简单。看起来这就是一个标准场景。
I'm looking into moving an existing app to Azure. It will have an MVC app in one web role and some WCF services in another web role. When live, the site will live at http://www.myapp.com and the services will be at http://api.myapp.com with the MVC app configured to point to the services at http://api.myapp.com.
The problem is when pushing the app to the "stage" configuration on Azure. My understanding is that each push to stage will cause the services to live at a new url (something random like http://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/). In this case, what is the best way for my MVC app to discover the url of the services?
One option would be to setup a dns entry like http://stage.api.myapp.com and update my DNS CNAME record to point to the new Azure staging url every time I push to stage, but... yuck.
Another option would be to push to stage, get the new urls for the services, RDC to each instance of the MVC role and manually update the configurations. Also yuck.
Is there a simple way to do this? I know I could automate some of the steps above with something like PowerShell, but I'm really hoping there's something baked into the Azure framework that makes this easy. It seems like it would be such a standard scenario.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
动态发现暂存 URL 的唯一方法是让实例检查其自己的部署 ID。我在这里假设 MVC 网站和 WCF 服务位于同一部署中。如果您检查 RoleEnvironment.DeploymentID，您会发现它与暂存中使用的“随机”URL 完全对应（即 http://[deploymentID].cloudapp.net）。
只要您在客户端动态创建 ChannelFactory，它就应该能够获取自己的 DeploymentID 并找到暂存 URL。
当然，这仅在部署时才有用。为什么不直接使用生产槽呢？该名称是稳定的，您可以依赖它或您为其设置的 CNAME（更有可能）。您始终可以拥有多个托管服务（开发、QA、产品等），并仅使用它们的生产槽。
The only way to dynamically discover what the staging URL will be is to have the instance check its own deploymentID. I am assuming here that the MVC website and the WCF service are in the same deployment. If you check the RoleEnvironment.DeploymentID, you will find that this corresponds exactly to the 'random' URL used in staging (i.e. http://[deploymentID].cloudapp.net).
As long as you are dynamically creating the ChannelFactory on the clientside, it should be able to take its own DeploymentID and find the staging URL.
Of course, this is only useful when deployed in staging. Why don't you simply use the Production slot? That name is stable and you can rely on it or the CNAME (more likely) that you set for it. You can always have multiple hosted services (dev, QA, prod, etc.) and just use the production slot on them.
不要按照@dunnry 的建议去做！ Azure 有一个非常好的端点概念来解决您的问题。您可以从 RoleEnvironment 类访问此信息。
您可以查看我的博客文章如何从客户端获取端点. 关键部分是创建一个 WCF 服务正在侦听的内部端点。但请记住，您不一定需要为此创建一个新角色，就我个人而言，我宁愿将其与原始 Web 角色一起托管在 IIS 中。具有其中两个角色以提高可靠性。
这样，部署是什么并不重要，因为服务通信将在该部署内部进行，无论是暂存还是生产。
Don't do what @dunnry is suggesting! Azure has a really good concept of endpoints that solve your problem. And you have access to this info from your RoleEnvironment class.
You can take a look at my blog post on how to get the endpoint from the client. The key part is to create an internal endpoint at which your WCF service is listening. Keep in mind though, you don't necessarily need a new role for this, and personally, I would rather host it in IIS alongide the original Web role & have two of these roles for improved reliability.
This way, it doesn't matter what the deployment is, because the service communication will take place inside that deployment, be it staging or production.