中国领先的IT技术网站
|
|

Travis CI:最小的分布式系统(下)

大约1年之前,我们发现当时的架构有些不合理了。尤其是Hub,它上面承担了太多的任务。Hub要接收新的处理请求,处理并推动构建日志,它要同步用户信息到Github,它要通知用户构建是否成功。它跟一大群外部API打交道,全部都是在一个进程中处理。

作者:金斌来源:伯乐在线|2013-12-20 09:43

开发者大赛路演 | 12月16日,技术创新,北京不见不散


大约1年之前,我们发现当时的架构有些不合理了。尤其是Hub,它上面承担了太多的任务。Hub要接收新的处理请求,处理并推动构建日志,它要同步用户信息到Github,它要通知用户构建是否成功。它跟一大群外部API打交道,全部都是在一个进程中处理。

Hub需要继续演化,但它却不太可能自由扩展。Hub只能以单进程的方式运行,也因此成为我们最有可能发生的单点错误。

Github API是一个有趣的例子。我们是Github API的重度用户,依靠这些API我们的构建任务才能执行。无论是获取构建配置信息,更新构建状态,还是同步用户数据,都离不开这些API。

回顾历史,当这些API中的某一个不可用,hub就会停止当天正在处理的任务,而转移到下一个任务上。所以,当Github API不可用时,我们的很多构建都会失败。

travis-1

我们对这些API赋予了很多信任,当然现在也一样,但是说到底,这些是我们不能掌控的资源。这些资源不是我们自己来维护,而是由另外的一个团队,在另外的网络系统中,有他们自身的弱点。

我们过去没有这样想。过去我们总是把这些资源当做我们可以信赖的朋友,以为他们随时都会响应我们的请求。

我们错了。

一年之前,这些API无声无息的对某个功能做了修改。这个一个虽然没有文档说明,但是我们非常依赖的功能。这个功能就是这么消无声息的被修改了,于是导致了我们这边的问题。

结果,我们的系统完全乱套了。原因很简单,我们把Github API当做了自己的朋友,我们耐心的等待这些API回应我们的请求。每一次新的提交,我们都等了很长的时间,每次都有几分钟。

我们的超时设置太宽松了。因为这个原因,当对Github API的请求最终超时时,我们的系统也已经发生错误。那天晚上我们花了很长的时间处理这个问题。

即便是小问题,当某个时刻凑到一块了,也能够破坏一个系统。

travis-2

我们开始隔离这些API请求,设置更短的超时时间。为了保证我们不会因为Github方面的中断而导致构建失败,我们同样加了重试机制。为了保证我们能够更好的处理外部的异常,我们的每一次重试都会依次延长过期时间。

你应该接受那些在你控制之外的外部API随时可能失败的现实。如果你不能将这些失败完全隔离,你就有必要考虑如果去处理他们。

如何去处理每一个单点错误场景是基于商业上的考虑。我们可以承受一个构建出异常吗?当然,这不是世界末日。如果因为外部系统的问题,我们能够让数百个构建出现异常嘛?我们不能,因为无论什么原因,这些构建异常够影响到了我们的客户。

Travis CI最初是一个好心的家伙。它总是很乐观地认为每一件事情总会正确的工作。

很不幸,那不是事实。每一件事在任何时刻都可能导致混乱,但是我们的代码却从来没考虑过这一点。我们做过很多努力,现在我们仍然在努力,去改变这种情况,去提高我们的代码处理外部API或者系统内部异常的能力。

travis-

回到我们的系统,hub承担的任务很容易导致异常,所以我们将其分割成很多的小应用。每个小应用都有其自身的目的和承担的任务。

做好任务隔离,这样我们就能更轻松的扩展系统。大部分任务都是直接的从上到下运行的。

现在我们有了三个进程;处理新的提交,处理构建通知,和处理构建日志。

突然之间,我们有了新的问题。

虽然我们的应用已经分割开了,但是他们都依赖一个叫做travis-core的核心。核心包括数量很多的Travis CI所有部分的商业逻辑。这可真是一个big ball of mud。

travis-4

对核心的依赖意味着核心代码的改动可能影响到所有应用。我们的应用是按照各自的任务进行划分,但是我们的代码不是。

我们现在还在为最早的架构设计而支付学费。如果你增加功能,或是修改代码,对公用部分的一点点改变都可能带来问题。

为了保证所有应用的代码都可以正常工作,当travis-core做了修改,我们需要部署所有应用去验证。

任务并不仅仅意味着你必须从代码的角度将其分隔。任务本身也同样需要物理分隔。

复杂的依赖影响了部署,同样,它也影响了你交付新代码、新功能的能力。

我们慢慢的将代码的依赖变小,真正的从代码隔离开每个应用间的任务。幸运的是,代码本身已经有很好的隔离程度了,所以这个过程显得容易多了。

有一个应用需要特别关注,因为它是我们做扩展最大的挑战。

travis-5

日志的作用有两个:当构建日志的数据块通过消息队列进来时,更新数据库对应行,然后推送它到Pusher用于实时的用户界面更新。

日志块以流的形式在同一个时间从不同的进程中进来,然后被一个进程处理。这个进程每秒最高可处理100个消息。

travis-6

一般情况下这样处理日志流的方式也相当OK,但是这也意味着我们很难处理某些时刻突然增长的日志消息,因此这个唯一的进程对于我们系统的扩展会成为一个很大的障碍。

问题在于,进程是按照这些消息到达消息队列的先后顺序来进行处理的,而Travis CI中的所有事情都依赖于这些消息。

更新数据库里的一条日志流意味更新包含所有日志的一行数据。更新用户界面的日志当然意味着在DOM树上附加一个新的结点。

为了解决这个棘手的问题,我们需要改很多代码。

但是首先,我们需要理清楚什么才是一个更好的解决方案,好的解决方案应该是能够让我们很方便的扩展日志处理的部分。

我们决定让处理的顺序作为消息本身的一个属性,而不是隐含的依赖于它们被放进消息队列的顺序。

travis-7

这个想法是受到Leslie Lamport于1978年发表的一篇论文《Time, Clocks, and the Ordering of Events in a Distributed System》的启发。

在这篇论文中,Lamport描述了在分布式系统中,使用递增计数器来保留事件发生的顺序的方法。当一个消息被发送,发送者会在消息被接收者接收到之前增加计数器的值。

我们可以简化那个想法,因为在我们的场景中一个日志块只能来自一个发送者。进程只要不断增加计数器的值,就可以让之后的日志收集工作变得简单。

剩下的工作就是根据计数器的值来对日志块进行排列了。

困难之处在于,这样设计之后等同于允许向数据库写入小的日志块,这些小日志块只有在对应任务结束后才会写入到完整的日志中。

但是这会直接影响到用户界面。我们不得不面对消息以无序的方式到来。这个变化的确影响的范围大了些,但它反过来简化了很多部分的代码。

从表面看,这个改动似乎无关紧要。但是依赖于你本不需要依赖的顺序会带来更多潜在的复杂性。

我们现在不用依赖于信息是如何传送的,因为现在我们可以在任何时间得到他们的顺序。

我们修改了不少代码,因为那些代码做了一个假设,任何信息都是顺序过来的,而这个假设是完全错误的。在分布式系统中,事件可以以任何顺序在任何时间到达。我们只需要确保之后我们可以将这些片段重新组装回去。

你可以从我们的博客获取这个问题更详细的说明。

到了2013年,我们每天已经在运行45000次构建。我们还是在为早先的设计付出着代价,但是我们也在慢慢的改进设计。

travis-8

我们现在还有一个麻烦。系统所有的组件还是在共享同一个数据库。如果数据库出现问题,自然的所有组件都会出现问题。这个故障上周我们刚刚遇见一次。

这同样意味着日志写入的数量(目前可以达到每秒300次)影响到了我们API的性能,当用户浏览我们的用户界面时可能会慢一点。

另外,当我们从构建任务的数量上考虑时,我们的下一个挑战就是如何去扩展我们的数据容量。

Travis CI在500台构建服务器上运行,这已经不能再算是一个小的分布式系统了。我们现在正着手解决的问题还是从一个相当小的维度来考虑的,但即便在那个维度上,你也能够遇到很多有趣的挑战。根据我们的经验,简单直接的解决方案总是比那些更复杂的要好。

原文链接:http://www.paperplanes.de/2013/10/18/the-smallest-distributed-system.html

译文链接:http://blog.jobbole.com/53684/

【编辑推荐】

  1. Travis CI: 最小的分布式系统(一)
  2. 无锁编程与分布式编程那个更适合多核CPU?
  3. 多核分布式队列的实现:“偷”与“自私”的运用
  4. 高房价与多核分布式计算
【责任编辑:chensf TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

网管员必读——网络安全(第2版)

本书是在《网管员必读—网络安全》第1版的基础上修改而成的。新版在保留第1版实用内容的基础上增加了大量新的实用内容,同时删除了一些过时...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
× 51CTO学院双十二活动