Azure:如何在一个虚拟网络中将一个云服务与其他云服务连接

时间:2014-02-18 15:59:06

标签: asp.net wcf azure cloud

我希望仅使用Internal Endpoint在Cloud Service 1中的WebRole中部署后端WCF服务。 并在Cloud Service 2中的WebRole中部署ASP.NET MVC前端。

是否可以使用Azure Virtual Netowork通过Internal Endpoint从前端调用后端?

更新:我正在尝试像这样构建简单的SOA架构师:

2 个答案:

答案 0 :(得分:1)

是和否。

内部端点实质上意味着角色实例已配置为接受给定端口上的流量,但该端口无法接收来自云服务外部的流量(因此它正在"内部"到云服务)。内部端点也不是负载平衡的,所以你需要" juggle"来自呼叫者自己的流量管理。

现在问题就出现了,虚拟网络允许您安全地遍历云服务边界,让云服务1中的角色实例调用云服务2中的角色实例。但是,为此,调用角色实例需要知道如何处理接收实例。如果它们位于同一个云服务中,则可以通过RoleEnvironment类对云服务拓扑进行爬网。但是这个类只适用于它所存在的云服务,它不知道虚拟网络。

现在,您可以让接收角色实例将其FQDN发布到共享区域(例如Azure表存储)。但是,除非您已使用自托管DNS服务器配置虚拟网络,否则云服务将仅使用其自己的内部DNS解析(仅允许您解析同一云服务中的短名称)。

所以,是的,你可以做你想要完成的事情,但它确实带来了一些挑战。鉴于此,我不得不争论分离部署的便利性是否足以证明解决方案的额外复杂性?如果是这样,那么我也会查看是否有更好的方法来互连两个服务,而不是直接调用(如基于队列的模式)。

答案 1 :(得分:1)

@BrentDaCodeMonkey在他的回答中提出了一些非常有效的观点,所以请先阅读。

我个人不希望通过负载平衡放弃自动发现和扩展。我的建议是您通过Azure Service Bus Relay端点公开WCF端点。这将为您提供一个“固定”端点,通过该端点进行通信(解决发现问题)和无限可扩展性,因为多个服务器可以在同一个服务总线中继地址上注册和侦听。此外,当您的Web应用程序连接到WCF服务时,它通过共享密钥身份验证向混合中引入了一些基本安全性。

如果您将服务总线实例与云服务共同定位,则中间的中继开销完全可以忽略不计,恕我直言,值得为上述优势付出代价。