Skype 故障带给我们的经验与教训

在 1600 GMT 时间 12 月 22 日，Skype 服务开始无法访问，一开始是一小部分用户无法访问，后来受影响的用户越来越多，最后网络在 24 小时内干脆就无法访问了。一周后，Skype CIO Lars Rabbe 谈到了这背后的原因。

Skype 的核心依赖于第三代的 P2P 网络，它拥有大量的对等节点和超级节点，一个超级节点对应于成百上千个节点。由于 Skype 并没有中央目录来支持彼此通信的两个或多个节点之间的路由，因此虚拟网络将超级节点作为目录。当某个客户端连接到 Skype 后，它会将自身注册到一个超级节点上，超级节点会为该客户端分配一个 IP 地址，，这样想要与其建立连接的其他客户端就能找到它了。当某个用户想要启动 IM 或是向另一个客户端发起音频 / 视频会话后就会询问超级节点，然后就会获得目标 IP，这样就会建立起这两个客户端之间直接的通信链接。超级节点是 Skype 网络的重要元素。

Skype 还运行着大量的支撑服务器，他们负责发送离线消息。由于突然有大量未发送的消息，因此这些服务器会延迟发送这些消息。Window 版本的 Skype v5.0.0.152 有一个 Bug，它会导致应用在接收这些延迟发送的消息时崩溃。最新的 Skype v5.0.0.156 和 Windows 下的其他版本以及非 Windows 系统的所有其他版本则不受该 Bug 影响，但问题在于有 50% 的用户在使用这个有 Bug 的版本，而它正是 Skype 5 的首个发布版。大约 40% 的 Skype 用户都是在线崩溃的，这影响到 30% 左右的超级节点。

客户端还需要继续运行，重启应用的客户端会导致网络继续搜索仍旧运行着的超级节点，这导致了超级节点的过载。由于 Skype 在超级节点过载时会启动保护措施，因此这并不会消耗客户端系统过多的资源，超级节点会一个接一个地自动关闭，这会导致整个网络出现故障。

没有超级节点，Skype 就将无法运作，因此公司一开始启动了上百个，然后是上千个超级节点，希望能够恢复服务。他们并没有指明使用了哪些系统，或许是他们自己的，也可能是 Amazon EC2 上的。网络开始基于这些超级节点来构建自身，服务在 24 小时后恢复了。他们说停止了大多数超级节点，留下了一些来处理各种突发状况，因为圣诞节 Skype 的使用量会很大。

我们从中学到的经验则是：除非必要，很多用户并不会更新自己的软件。Skype 已经有更新的版本了，但如果没有遇到 Bug，大多数用户是不会更新的。Skype 打算重新检查自动更新过程，或许像 Google Chrome 那样做：

我们会重新检查向用户提供的“自动”更新过程，这样我们就能让每个人都使用最新版的 Skype 了。我们相信这些举措会降低这类故障发生的概率。

另一个问题是我们应该尽最大努力来保证软件是经过充分测试过的，Skype 决定重新检查“测试过程来确定更好的检测手段以避免会影响到系统的 Bug 出现”。

最后要说的就是 Skype 服务器支撑网络的能力，比如用于处理离线 IM 的服务器，Rabbe 说他们“会经常性地检查支持 Skype 用户的核心系统的能力，并继续在这些系统的能力和弹性上投入”。

根据 Skype 博客发布者 Peter Parkes 所述， Skype Connect 企业版并没有受到此次故障的影响。

查看英文原文： Lessons Learned from Skype’s Outage