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

阅读数:2861 2011 年 1 月 3 日

话题:测试架构

在 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