部署 Azure CDN 的血泪经历
Cloudflare 的问题
想要使用 Cloudflare 必须要修改域名的 Name Server。Cloudflare 的 DNS 系统在界面和功能都堪称业界一流，就单说 CNAME Flattening 就非常的好用，支持这个功能的 DNS Provider 也没几家。还有就是解析速度快的飞起，修改解析记录后，本地网络几乎都是秒级响应。
最大的问题是在于中国境内复杂的网络环境下，Cloudflare 的优势荡然无存。无论从连接的稳定性还是速度都很差，往往不如直接访问源主机更快。
Cloudflare 适合以下的情况使用：
- 访客群体在中国大陆以外
- 网站经常经受高强度 DDos 攻击
满足以上任意一条，Cloudflare 都是很好的选择。其他情况下几乎都不是好的选择。
Google Cloud CDN 的问题
Google 的 CDN 只能给自己云上的实例使用，不支持外部源。这点让自己处于二线选手。
Windows Azure
Windows Azure 的优势和劣势也很明显。优势是他家的 CDN 部署后，在中国的访问速度非常快；劣势就是烦人的后台操作以及感人的价格。
就单 Azure 的操作界面来讲，功能和布局算是合理的。后台之所以烦人，是因为几乎所有的操作都需要等待时间。当你点击了任意的按钮，右上角的 Notifications 就开始转了起来。接下来你可以去上个厕所回来再喝个咖啡，然后它可能还在转。我一点也没有夸张。
想要在 Windows Azure CDN 中使用 APEX/ROOT 域名是一个高难度的操作。 我用了几天的时间才琢磨出来解决方法，期间一度想要放弃。
基本思路如下：
- 域名使用 Azure 的 DNS 服务
- @ 绑定 Azure resource，选择你的 CDN Endpoint
- 在 CDN Endpoint 中添加自定义域名，绑定 APEX
- 在 CDN Endpoint 中添加外部购买的自定义 SSL
以上是思路，而不是操作。如果你按照上边步骤去执行，会发现每一步操作可能都会遇到问题。
Endpoint 建立
关于 Endpoint，一定要选择 S1 Standard Verizon，而不是 S3。S1 是外部的 Verizon 供应商，S3 是微软自己的。在使用中发现，S1 功能比 S3 更多，对缓存规则能做更多的控制。使用 S3 后，Mastodon 系统出现了 401 Invalid Token 的错误。切换到 S1 则无此问题。考虑到两者目前是相同价格，强烈推荐不要使用 S1。
]
在 CDN 的 Caching rules 中，必须要设定 Bypass caching for query strings，否则 mastodon 无法登录。对复杂交互的动态网站的缓存还是要尽可能的少，否则很容易遇到 WebSocket 和 token 方面的问题。
购买 SSL 时注意点
添加自定义 SSL，首先要去买一个 Azure 支持的 SSL 证书。虽然文档里有列出来支持哪些，但是坑爹的是对方写的是一些技术参数。当你去购买 SSL 证书的时候，你无法知道证书内部的细节，比如我们欣慰的看到了列表中包含了 Godaddy 的以下证书：
- Go Daddy Root Certificate Authority – G2
- Go Daddy Secure Certificate Authority – G2
当你兴冲冲的去了 Godaddy 官网时，发现情况完全不对。几乎所有销售 SSL 的网站都不会列出来技术细节。你无法知道你选择的证书是否满足 Azure 变态的要求。
]
把证书导入到 Key vault 中
在 Key vault – Certificates 下，选择 Generate/Import，然后你可能悲哀地发现自己下载的 SSL 证书文件竟然无法导入。因为格式不对，Azure 只支持 .Pem 和 .Pfx 格式。只好再去复习一遍 SSL 证书各种格式的区别。
另外需要注意这里上传的证书文件，需要包含 Private Key 信息。
我购买的 Rapid SSL 供应商签发的证书文件中有 P7B 格式，使用了这个 SSL 格式转换网站 可以把 P7B 文件 + 证书链文件 + Private Key 文件转化为一个 Pfx 文件。
成功导入以后并没有万事大吉。你发现还需要为 CDN 添加刚才的 Key Valt 访问权限 。吃惊的是，这一切竟然无法在 Azure 界面完成，你需要下载 Powershell，然后敲一堆命令行（过程也并非一帆风顺会遇到隐含的设置）。如果不去搜索并翻看相关文档，你可能永远无法成功添加一个自定义 SSL。
我曾经想过去联系他们的客服，但是点击 Help 会引导你订购他们的 Basic Support。每月 29 刀会有 24 小时以内响应的 Email 支持。到这里我只能说 Azure 真的太高级了，设计之初就并不是给所有人使用的。
CDN 等待时间
当你验证 CNAME 记录时候，可能需要 30 分钟左右。当你上传并设置好 SSL 以后，部署到 CDN 最高要 30 个小时。总之，在 Azure 中进行某一操作以后，往往不会立即生效。给我隐隐的感觉就好像他们会把每一步操作拿去给领导签字一样，确认以后才放行。这还是云计算服务吗？每当页面转圈圈的时候，就非常怀念 AWS。
截至目前，SSL 状态依然是 Deploying certificate to CDN POPs。使用云计算尤其是 Azure CDN，真的要保持好心态不能急躁。
== 部署成功 5 个小时以后更新
本来以为成功部署了就没问题了。截至现在还是遇到 SSL 证书错误问题。Azure 并没有把我的自定义域名放到 CDN 上，目前证书还是 sni.msft.default.wpc.edgecastcdn.net 这里的。我看到了<<有同样的人遇到此问题>>，有的是部署成功后几小时内才成功的，有的是部署5天后还是错误。这里只能拼人品了……
== 部署成功 15 个小时以后更新
大约昨日凌晨 4:00 am 左右提交证书，早上 10:00 ~12:00 am 点之间 Azure 后台显示部署成功。但是实际证书变得可用还得十多个小时。在晚上 8:00 pm 左右微软的 edge 浏览器开始认出来了自定义的证书，再往后到了 11:00 pm 查看的时候各浏览器中 SSL 证书已经完全正常了。
从提交证书到正常使用，前前后后需要将近 20 个小时！我推断这 20 个小时中必然会有一些人工审批的过程，否则按照计算机系统处理速度和国际互联网传输速度，不可能在同步到个节点的过程中花费如此长的时间。微软成功的把大公司的官僚作风带入了自家的云计算中。相比 AWS，部分新注册用户或者敏感服务比如 SES 会有明确的提示，告诉你需要填表申请并且人工审核，你自己可以对完成的时间做到心里有数。Azure 则不会告诉你哪些操作有隐形的审核步骤，只会告诉你一个大概时间，但是实际需要的时间往往比他们预估时间要更久。
这次的经历告诉我们：如果要在生产系统上部署 Azure CDN 并且使用 SSL，一定要慎重考虑如何做好过度，否则等待 SSL 生效的时候流量强行中断，老板可能已经把你炒鱿鱼了。