Akamai NetStorage与Akamai的边缘服务

（对不起，这个问题已经发布了一段时间，但希望这个信息对OP和/或未来的访问者有用…）

上面的假设通常是正确的。 NetStorage是Akamai云中托pipe来源服务的骨干。

重新成本，我相信NetStorage是一个免费的select，至less有一定的服务水平，但你需要问他们确定。

我工作的公司每天为我们的静态物体获得约400万的请求，我们使用Akamai。 我们现在正在切换到NetStorage，并且我们已经在他们的分级networking上进行了大量的测量和testing，以预期切换。 对我们来说，基本的考虑是：

边缘到原点的速度和caching命中率 – 这实际上是stream量的一个function。 根据（1）Akamai的边缘服务器能够以多快的速度到达您的出处，以及（2）每个边缘服务器获得您的对象的请求的频率，用户体验的差异可能很大或者可以忽略不计。

• 如果边缘服务器必须从您的原点请求一个对象，那么您的原点可以响应的速度有多快。 NetStorage几乎总是比您的原始服务器响应得更快，因为NetStorage位于Akamai的networking上，并针对这一点进行了优化。

• 和/但：你的对象被caching在边缘服务器上的越多，它的起源（或他们的）对这些边缘服务器的请求的响应速度就越慢。 因此，如果您的对象获得大量stream量（和/或您的来源位于快速服务器上，并且与Akamai的边缘networking连接速度非常快），则可能没有多大区别。 但是，如果你是一个中小型的交通网站，而Akamai的边缘服务器经常从caching中清除你的对象，为其他对象腾出空间，那么这可能会产生很大的影响。 确实，Akamai拥有大量的边缘服务器，并且有时可以从邻近的边缘服务器获取caching的对象，但是如果您的对象不在邻居的caching中，您仍然可能会在起源。

• 作为参考，我们对大多数对象都有一个非常积极的浏览器caching策略，但是我们的来源仍然会从Akamai的边缘服务器获得每天4M +请求的25％-30％的请求。

pipe理员。 没有NetStorage，你显然需要托pipe（或安排托pipe）你自己的原始服务器，这意味着configuration，维护，监控，预算等NetStorage基本上是免费托pipe。 根据你的演出，这在某些方面可能是一个巨大的胜利。 但是…

其他pipe理员。 NetStorage有自己的麻烦和一些限制。 例如：

• 如果您关心的URL不区分大小写，但是具有混合大小写的文件名和文件path，那么只要您上传它们，就需要将它们转换为全下或全部。

• NetStorage文件pipe理留下了很多希望。 没有脚本可以说， 你可以上传和下载，但删除任何大的文件需要永远。

• 文件夹大小基本上限制为每个文件夹10,000个文件（尽pipe文档说明限制为50,000）。

另一件你可能想知道的事情是“ Midgress ”选项。 如果您不想使用NetStorage，并且需要更高的caching命中率和更less的命中，则可以为在边缘服务器和原始端之间插入的中间层caching服务器额外付费。 这实际上保证了较低的往返时间（边缘服务器请求更多本地中间服务器，而不是直接访问您的原始服务器）和高caching命中率。 我们尝试过一次，效果很好，但是成本比我们想要支付的要多。

干杯，

亚伦

你的假设是正确的。 除了一个地方，我认为他们不会在全球范围内分配networking存储内容。 从逻辑上讲，它应该是需要的。

其次，performance明智，你不应该看到两者之间的差异。 如果你设置了正确的caching标题，那么你的静态内容就会被caching在边缘服务器上。 两者之间的唯一区别是，如果您使用netstorage，那么您将卸载静态内容的剩余数量非常less的HTTP请求到akamai。 如果源服务器closures，Netstorage可以提供帮助。

总之，Akamai或多或less是一个反向代理。

一些定义，如果他们帮助。

Origin服务器是您的服务器。

边缘服务器是akamai服务器。

Apache <—-> |边缘服务器 – Akamai_Network —>边缘服务器<—-> |客户

netstorage的成本将取决于你可以谈判的东西:)

有些事情要澄清… NetStorage实际上是在全球范围内默认复制内容。 这不是一个按需服务，它是自动处理的。 NetStorage平台与内容caching基础架构是分开的networking覆盖。

您可以将业务逻辑configuration为忽略所请求对象的区分大小写。 或者，您可以让NetStorage在上传时转换对象的名称。