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

Travis CI 一开始仅仅是个想法,在当时甚至还有些理想化。在这个项目启动之前,开源社区还没有一个可用的持续集成系统。

随着作为开源协作平台的Github越来越被人认可,Github也非常需要可以持续对贡献代码进行测试的服务,来保证一个开源项目始终处于稳定健康的状态。

Travis CI开始于2011年初,而且很快得到了一些试用客户。到了2011年夏天,我们每天进行700次构建。所有这些构建都是在一台构建服务器上进行的。Travis CI跟Github完美集成,目前Github还是Travis CI的主要平台。

Travis CI在持续集成领域并没有惊天动地的大动作,但它的确重新定义了一些原有的概念,并增加了一些新的想法。其中一个就是你可以在你的测试运行过程中,接近实时的看这个项目的构建日志流。

最重要的一点,Travis CI允许你通过源码里的文件(.travis.yml)来对构建过程进行配置,而不是复杂的用户界面。

The_Smallest_Distributed_System_01

Travis CI一开始的架构很简单。通过Web组件可以让项目和它的构建过程可见,同时,只要一个新的commit提交到了项目,Travis CI就可以接收到来自Github的消息,从而触发构建。

另外一个叫做hub的组件,是负责处理新的提交,将他们转化成一次构建,并且处理构建任务运行和结束时产生的结果数据。

这两个组件都是跟PostgreSQL数据库打交道。

第三部分就是用来控制构建任务本身的线程集合,它们可以用来在虚拟机实例上执行一系列的命令。

The_Smallest_Distributed_System_02

 

本质上,hub会显得比其他部分稍微复杂一些。当hub处理构建日志时,它需要与RabbitMQ进行消息传递。日志会以chunks流的形式从控制构建任务的线程中得到。

Hub更新数据库中的日志和构建结果信息,并且hub推送他们到Pusher。通过Pusher,Travis CI可以在构建开始或结束的时候更新用户界面。

这样的架构一直维持到了2012年,当时我们每天进行7000个构建任务。我们欣喜的看到Travis CI在开源社区越来越广泛的使用,并且开始支持11种语言,包括PHP,Python,Perl,Java 和 Erlang。

随着越来越多的使用,Travis CI越来越像是一个开源项目的必备服务了。但是不幸的是,这个系统从一开始构建的时候就没有考虑过监控。

The_Smallest_Distributed_System_03

过去,总是来自社区的用户通知我们系统没有正常运行,构建任务遇到异常,或是任务信息没有被处理好。

那可真是令人尴尬。我们的第一个挑战就是给系统增加监控,数据指标和日志,让Travis CI从一个业务爱好的项目转变为一个重要的商业平台。我们准备发布Travis CI的正式生产版本。

被用户告知系统没有正常运行直到今天仍然是我最大的噩梦,我们不得不努力工作建设好数据监控,以使系统能够在出现问题的一开始就及时通知。

如果没有任何数据记录或者良好的日志,我们根本不可能去搞清我们这个小分布式系统到底发生了什么。无论是从哪个方面看,Travis CI都已经是一个分布式系统了。

加入监控指标和日志是一次循序渐进的学习过程,但是最终,它们让我们可以了解这个系统正在做什么,无论是通过图表还是日志。

这对我们而言是一个巨大的提升。可见性对于运行一个分布式系统是非常重要的。

当你写一个系统时,考虑好如何监控它。

做好监控会有助于你的系统更好的在生产环境运行,而不仅仅是通过测试。

关键是,更多的监控不仅仅是让你可以对系统更了解,你也会发现那些你以前未曾想到或见到的问题。系统更高的可见性带来更多的责任感。现在我们需要去面对这样的事实:我们对系统的错误有了更多的了解,所以我们必须更有效的工作来减少这些错误所带来的影响。

1 收藏 评论

关于作者:金斌

(新浪微博:@金斌_jinbin) 个人主页 · 我的文章

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部