请参考:http://blog.smarx.com/posts/custom-domain-names-in-windows-azure
本文是对这篇文章部分解释和补充。
并请记住，此博客总是能给你在Windows Azure的开发中带来帮助。
域名解析机制浅析
域名解析，本是个很简单的事情：我们如若想将我们的域名指向某个网站提供的二级域名，只要设置cname记录；如果我们知道服务器的ip，直接设置A记录即可。在Azure的使用中，却总是有些人有点疑惑。
这里我们首先要弄清楚DNS解析域名的过程，记住，只要是通过域名解析设置的（不是通过页面重定向技术实现的），不管中间经历多少域名的转换，从用户在浏览其中输入域名地址，DNS返回给浏览器的一定是最终服务器的IP地址，中间所有域名解析对于浏览器来说不可见。
事实上，请求者不需要知道这些细节，DNS的作用在于你给我一个域名，我尽其所能找到这台服务器的IP地址。因为，互联网本是基于IP的，但是为了好记忆才添加了一个DNS应用层，在用户看来，一个域名始终指向一个IP，一个IP可能被多个域名指向。
并且对于开发者而言，除了重定向外，通过DNS发过来的请求，其HTTP请求的Host部分，一定是最初用户输入的地址，不管中间经历什么其他的域名。
所以，这样提示我们开发者，应该根据Host来区分用户输入的域名地址，以及做相关的导航控制，不应该依赖于某个绝对路径。
几种均衡负载方式
Azure的域名解析问题可能主要来自多个Instance，每个instance是一个虚拟服务器，那这样IP地址怎么确定？
这里我们首先来分析，均衡负载有几种方式，可以参阅《构建高性能网站》，最简单的莫过于重定向，但是这样会改变浏览器中用户输入的域名，可能给里面的内容导航带来混乱；其次可以通过DNS来设置，可以为一个域名配置几个IP，这样DNS可以根据一定的算法分配到不同的IP地址；第三种方法是通过硬件来实现，市场上也有许多相关的产品，其实思路很简单，由交换机内部实现将处理分配至不同的内部服务器或者应用程序，这样每个内部服务器不需要分配固定IP，这样的方式，服务对外而言，始终拥有固定的IP。
Hosted Service的IP实验
注意，本部分是根据笔者实验推断，有部分可能不是真实情况，仅仅作为参考！
Windows Azure的均衡负载通过硬件来实现，所有请求和虚拟服务器都由Fabric集中管理，所以每一个Hosted Service，不管里面真正的应用程序或者数据存储在那个虚拟服务器或者有多少个instance来均衡负载，每一个Role对外都只有一个IP，并且Azure为每一个处于Production状态的Role提供一个二级域名，如:http://egyee.cloudapp.net。
但是注意这里的IP，不是固定IP，因为一个Role重新部署之后会分配不同的IP，所以应该绑定其提供的二级域名，而不应该对其IP有任何打算。很简答，Azure不认识任何Role，每一次部署都会分配IP，不可能帮你记住某个Role上一次分配的IP，看下面截图：
由上图可知，我在同一个Hosted Service中两次部署同一Role，得到的IP分别是：111.221.92.83和111.221.92.89。虽然两者都对应二级域名http://egy.cloudapp.net，但是两次部署却分配两个不同的IP。
Windows Azure保留IP的分配权，及同一Hosted Service会分配不同的IP地址，所以，其在上提供了一个二级域名，使用户在使用的时候，针对同一个Hosted Service有相同的访问路径，因此，在Windows Azure中，我们只能相信二级域名，而不能依赖IP地址。
Windows Azure保留动态的域名还使得应用程序存放和执行位置的更改变得容易，比如，你指定应用程序只在亚洲的数据中心执行，那么IP地址是分配到亚洲某个数据中心的某个交换机，如果你改为在北美洲，那么IP地址则会分配到北美数据中心的IP地址之一。通过这样来使得应用程序执行场所以及数据存放地点离用户最近，以减少网络传输延迟。
值得注意的是，减少网络传输延迟有几种方式，如缓存，CDN，以及将服务器处理靠近用户，这些都是云计算带给开发者的好处，我们自己架设服务器不可能得到这些好处。
同时另外值得注意的是，在一个Role部署之后，如果不做任何修改，比如地点等，IP地址理论上不会发生改变，不过未经验证，总之我们不应该关注IP。
域名解析的配置方法也很简单，只需要在域名管理里增加一个CNAME记录即可。
在多服务器负载情况下的开发注意事项
如果，应用程序可能被不同的域名指向，那么我们的应用程序不应该依赖于任何绝对路径，包括导航。如果你想要在某个导航写上全路径，则Host部分应该取自HTTP请求的Host，而不是自己假设的某个域名，事实上，我们应该始终这样做，不管应用程序被什么域名解析，始终保证不会出现问题。
相反，利用页面重定向的方式实现的均衡负载，前面已经分析，实际上应用程序接收到的Host并不代表用户输入的域名，所以这种情况下，可能会导致某些混乱的情况。
事实上，重定向是服务器向浏览器返回一个3XX的响应代码，根据HTTP协议规则，浏览器应该向新的URI地址发送请求，本来这不会打乱我们上面的原则，但问题是，页面重定向针对Uri设置，所以不能保证一个域名下的所有Uri都被正确重定向，结果导致一个域名下的各个资源路径可能不在同一个域中。而域名的解析式针对一个域名，它能保证所以Uri都处于同一个域。
总之，要小心使用重定向，重定向的页面中可能包含一些相对路径，从而使得这些路径对于原来的请求路径处于不同的域中。
云计算中的数据一般不会存储在本地服务器内，都是通过比如REST的方式读取和修改数据，因此是不依赖于任何服务器的。
在架设分布式服务或者网站或者存储的时候，这些情况都是必须考虑的，一定要准备好相关的方案！
总结：
像我之前的一些文章一样，我不对文章内容负责，因为我写的东西一般都是基于自己思考，不会随便去抄一个MSDN或者什么之类。这样由于笔者水平有限，可能导致某些思想错误，因此，这里的东西都是只能作为理解过程中的参考，千万不能当真！