Azure Web应用程序体系结构的外观如何？
我已经有10到15分钟的几次中断，因为显然微软在他们的存储上有一个“昙花一现”。 他们告诉我，这是因为实例之间共享文件系统（使其成为单点故障？）
我不明白这一点，并问如何涉及文件共享 ，因为我会假设一个非常愚蠢的无状态的IIS应用程序与SQL Azure通信的数据。
我会假设下面的情况：
这是他们对我的问题的回复（我没有包括图纸）
文件共享不一定会让您的networking应用程序与其他资源进行通信，但是它们位于应用程序内容所在的位置。 当我们build议我们的文件服务器上存储不可用时，这就是我们的意思。 为两个实例上的应用程序触发重新启动的原因是因为资源是共享的，所以两个实例的底层存储都是相同的。 这是一个原因，最后也会跟着。 如果您真的想要改进应用程序的可用性，您可以随时使用stream量pipe理器。 但是，即使使用stream量pipe理器，也不能保证应用程序不会closures，但会提高应用程序的整体可用性。 另外，我们最近推出了一个生产更新，理想情况下应该考虑由存储单元引起的重新启动，但是要启用此function，您需要确保在以下情况下有足够的内存可用：这个function需要启动。我们有几个选项可以设置，以避免应用程序意外的重新启动，因为我们的结尾存储blip：
您可以评估是否要移动到更大的实例，以便我们可以有足够的内存来使重叠回收function被踢入。
如果您不想移动到更大的实例，则可以使用本文早期电子邮件中概述的本地cachingfunction。
由于时间的差异，沟通需要时间。 谁能告诉我我的想法有什么问题？
我唯一想到的是当你启用了两个实例时，它们运行在同一台物理服务器上。 但这对我来说确实没什么意义。
我有两个实例一个核心，1.75 GB的内存 。