文件访问频率的分布规律CDN成本构成确定业务参数确定业务模型-拟合zipf曲线通过zipf建立CDN边缘容量和回源率的关系确定IT设施单位成本7200TB * e * 1元/TB/天20Gbps * b * 600元/Gbps/天找出最优配置
现在所有的模型，场景和数据都准备好了， 最后我们把它们放在一起得到最终结论: 成本对边缘容量的变化:
选择不同的边缘容量e的值((图1)橘黄色部分的宽度)，
根据公式(2)计算对应的回源率b((图1)蓝色部分积分/蓝色黄色部分积分)，
再结合单位成本，得出每个e对应的总成本，
最后我们得到如下一个边缘容量e决定回源率b和成本的表格:
我们看到，在这个业务场景中，边缘容量取到6%时，总成本会达到最低: 1419.6 元/天。
把e变化作为x轴，画出边缘存储成本和回源带宽成本随e变化的曲线如下图， 趋势看起来就更清楚了:
我们看到总成本(红色曲线)在这个图上有一个极小值，大概在e=6%的位置。
而如果边缘机房的容量配置不在6%这个位置，譬如达到10%， 一个边缘机房每天就会多花掉1507-1419= 88 元， 如果整个CDN系统有100个边缘机房，一年多花的钱就是320万 (88 * 100 * 365)。
当然，在实际运营一个CDN这种庞大的系统的时候，还有很多因素需要考虑:
如边缘机房的存储容量带来的性能提升，
低回源率带来的整体延迟降低等。
因此我们的结论尚不能作为优化的标准，而只能作为优化的参考:
知道理论上限在哪，
不做无效的尝试，
制定有依据的目标，
了解运营策略调整的成本等等。
总结
算完了，休息一下。
互联网的各种服务之间都是相互关联的。虽然目前看来，源站和CDN之间的协作还是单方面的，一方去适应另一方， 或一方服务另一方的模式。其实源站和边缘之间，本应是一个整体，但市场的划分导致了技术和设施层面上的分离， 让这个本应完整的框架分离成了2个或多个部分。
这里我们看到的源站和边缘之间的关系， 还只是开始，这些只不过是数学结论上的互相了解， 源站和边缘之间应该有比这更大的的协作空间。
试想一下，边缘和源站之间如果能在单向数据下载的基础上建立双向数据通讯， 在中心源站数据发生变化要通知边缘缓存的基础上， 如果边缘发生的事情能很快推送到中心， 才是真正的互联网模式。
市场一直在变化， 每次在这些变化背后， 一定是有一个什么新的东西出现，是让用户使用到了更方便或更高效的东西， 才让技术的格局发生了变化(google之于yahoo，微信之于邮箱，twitter之于博客)。
出色的支持和适配可以产生优质的产品，但我相信协作和互通更能带来质的变化。作为一个技术从业人员，发现这些改变的可能，实现这些改变，并把这种改变服务于可受益的人， 也许就是最开心的事情了: Discover, Design, Distribute…
文中链接：
[1] http://openacid.github.io/post-res/cache-hit/file-access-count.txt
[2] http://openacid.github.io/post-res/cache-hit/find-zipf.py
高可用架构
改变互联网的构建方式
閱讀更多 高可用架構 的文章
