.net - 如何以编程方式区分/控制 Azure 内部流量与出站流量？

Question

背景

我是名为 Ball 的开发者加速器平台的首席架构师。 The Ball 旨在在类似云的可扩展性内提供授权处理，并已通过 Web 内容管理在 Windows Azure 生产环境中运行。它解决的问题是提供全分布式规模架构，以便为后端(.NET)和前端 Web(jQuery、JSON)轻松开发插件。

该平台可管理大规模的数据/内容。它的 native 存储设计是键值 blob 存储，因此其可扩展性设计为 TB 级。它支持实例之间的灵活通信 - 两个端点都在 Azure 中运行。

我们现在正在插入用户可定义的内容集成 - 这就是问题所在。

问题/疑问

该架构已经使用低级请求管理，并且已经插入并通过 HTTP 模块/处理程序实现来监控流量/成本。但是，我没有找到任何清晰的引用资料，如何确保网络调用保留在数据中心内 - 并且我知道 Azure 基础设施也同意流量位于数据中心内。

当前的生产使用将立即导致千兆字节级的每日数据流量(每个客户)，我们需要从它启动的那一刻起就解决这个问题。考虑到该架构的成本效率，如果按出站流量费率计费，它将成为迄今为止最大的组件。

我并不打算取消那些确实适用的成本。如果客户在不同数据中心的 AWS 或 Azure 上运行自己的 Ball 实例，则无论如何都会存在出站流量组件。

解决方案的当前状态

The Ball 在网络级别拥有其授权堆栈。虽然从技术上讲，实例内部流量可以在内部网络内进行控制，但从逻辑上讲，这会使事情变得复杂，我认为这个问题应该通过出站网络接口(interface)级别控制来解决。如果有一个很好的类似引用的答案(或者我们在这个链中组成一个答案)，它应该适用于所有必须对网络出站流量进行成本优化的分布式架构案例。

我发现的当前解决方案围绕根据 IP 地址检测数据中心特定流量进行循环，基于如下列表: http://msdn.microsoft.com/en-us/library/windowsazure/dn175718.aspx

虽然这些类型的列表在技术上是可以使用的，但它充其量只是与“不造成成本”的松散耦合信任。

Techwise the Ball 采用 .NET 4.5 和最新的 Azure SDK for .NET 构建。对于 devops 自动化，Powershell 已规划在路线图上，因此任何 Azure 管理级别配置也可以应用于该解决方案。

我附加了一些架构图像来阐明单个 Ball 内以及分布式 Ball 实例网络的架构设计。

Answer 1

我刚刚收到 MSFT 消息来源的回复，截至今天(2014 年 2 月 13 日)，Azure 平台尚未公开所需的功能。

因此，回答如何获取“平台支持”的信息是:不可能。

我认为涉及基于 IP 地址的逻辑(不太可信)或添加外部注册表的解决方法已经很少了，可以为将在某些数据中心内调用的已知各方手动检查/更新这些注册表。虽然变通办法(希望)足以满足某些情况，但它们并不符合“只要您在我们的数据中心内，我们就公开共享此数据”的解决方案。

我不会将此标记为已接受的答案，因为它甚至不包括解决方法规范。我稍后会亲自回来填写我们是如何解决的。