曾经风靡一时、估值一度达到2亿美元的Digg&＃xff0c;因为两年前一次失败的改版&＃xff0c;人气大跌&＃xff0c;并失去公众对它的关注&＃xff0c;创始人Kevin Rose也无奈离开。前不久&＃xff0c;更是以50万美元的价格被Betaworks收购剩余资产&＃xff08;Digg实际的收购价格为1600万美元左右&＃xff0c;详见&＃xff09;。
\u0026#xD;\n
Will Larson曾经担任Digg的工程总监&＃xff0c;他在一篇博客中&＃xff0c;回顾了Digg从2010年5月到2012年5月公司的研发团队架构和流程。
\u0026#xD;\n
团队架构
\u0026#xD;\n
\u0026#xD;\n
一开始&＃xff0c;Digg的组织架构很传统&＃xff0c;产品、运维和工程团队各自独立。产品团队只有4名成员&＃xff0c;8个工程师构成运维团队&＃xff0c;QA有6个人&＃xff0c;研发团队有大约20人。
\u0026#xD;\n
研发团队本身分为4个水平团队&＃xff1a;前端、API、平台和基础设施&＃xff0c;两个垂直团队&＃xff1a;广告、分析。产品团队在功能上掌控垂直团队&＃xff0c;与多个水平研发团队协调。
\u0026#xD;\n
\u0026#xD;\n
此后&＃xff0c;由于人员流失&＃xff0c;组织结构变得更为简单。运维团队只有3个人&＃xff0c;工程团队7个人&＃xff0c;广告工程团队4个人。
\u0026#xD;\n
代码评审和持续部署等实践
\u0026#xD;\n
Digg的核心开发实践让他们的开发人员一度达到40个人&＃xff0c;后来降到14个人。
\u0026#xD;\n
\u0026#xD;\n
他们使用Git管理源代码&＃xff0c;Gerrit做代码评审。所有的代码都要得到同事的评审和通过&＃xff0c;并通过所有的单元测试。
\u0026#xD;\n
有代码补丁提交到Gerrit等待评审时&＃xff0c;Jenkins会自动运行单元测试&＃xff0c;并将测试结果更新到Gerrit中&＃xff0c;也就是说评审代码的人不会浪费时间去看失败的补丁代码&＃xff0c;这样的代码也无法进入Git代码库中。
\u0026#xD;\n
一旦Gerrit中补丁代码通过测试和评审&＃xff0c;它们就会被合并如Git的master分支&＃xff0c;Puppet会将其自动部署到alpha环境中&＃xff0c;在其中成功通过集成测试后&＃xff0c;这些新的补丁代码会合并到Git的生产环境&＃xff08;production&＃xff09;分支。
\u0026#xD;\n
向生产环境的部署是手工构建Jenkins方式完成的&＃xff0c;接下来会使用Puppet一起部署更新代码。
\u0026#xD;\n
开始时&＃xff0c;他们使用了持续部署的方式向生产环境部署&＃xff0c;但是出现一系列问题后&＃xff0c;他们决定还是先让人工方式参与进来。
\u0026#xD;\n
Will这样说道&＃xff1a;
\u0026#xD;\n
\u0026#xD;\n如果我们当时坚持使用持续部署&＃xff0c;我们最终会改善我们的测试&＃xff0c;使得错误代码很难通过&＃xff0c;但在当时&＃xff0c;我们觉得投入那么多时间做这个并不值得。
\u0026#xD;\n
\u0026#xD;\n
Will认为这个评审、测试和部署系统是Digg当时最重要、最成功的开发流程系统&＃xff0c;足以让40个人的团队开发出高质量和一致性的代码&＃xff0c;也不会让14个人的团队被流程拖慢效率。
\u0026#xD;\n
在不断的实践中&＃xff0c;Digg慢慢涌现出一些新的实践&＃xff0c;虽然未经详细研究&＃xff0c;但它们确实来自日常实践。
\u0026#xD;\n
刚开始&＃xff0c;他们的单元测试覆盖率非常高&＃xff0c;随着团队人员所见&＃xff0c;他们写的单元测试就非常少了。虽然没有人明说&＃xff0c;但是他们相信&＃xff1a;单元测试并不能减少他们遇到的绝大部分问题&＃xff1a;在高负载下&＃xff0c;生产环境多个组件出现问题&＃xff0c;最终导致系统故障&＃xff1b;前端呈现问题。此后几年中&＃xff0c;单元测试还一直可以提供价值&＃xff0c;但是Selenium测试在没有人主动维护之后&＃xff0c;很快就过时了&＃xff0c;而且很快退出舞台。
\u0026#xD;\n
他们使用Thrift定义前端和平台团队之间的接口&＃xff0c;因此团队之间的沟通和协调非常直接。
\u0026#xD;\n
他们很少变更已有Thrift接口的行为&＃xff0c;如果需要新功能&＃xff0c;他们会推出新的接口&＃xff0c;更新客户端来使用这些功能&＃xff0c;然后移除旧的接口。虽然这个流程貌似奇怪&＃xff0c;但是由于他们的前端和后端代码各自独立部署&＃xff08;部署所有的前端或后端服务器只要几分钟&＃xff09;&＃xff0c;这种做法理智、安全。
\u0026#xD;\n
新的前端变更只会推送给一部分用户&＃xff0c;如果有问题就会禁用。虽然他们一开始想用这种方法来完成新功能的A/B测试&＃xff0c;但是其最大的价值在于管理版本发布&＃xff0c;并从一小部分可信用户那里获得反馈。
\u0026#xD;\n
在发布可能会影响性能或负载的后端功能时&＃xff0c;他们都使用不宕机的方式。
\u0026#xD;\n
康威定律下的“架构”
\u0026#xD;\n
在Will看来&＃xff0c;对比下他们的v4版本架构和他们设计这个版本时的组织架构&＃xff0c;这基本上就是康威定律&＃xff08;Conway&＃39;s Law【注】&＃xff09;的直接表现。
\u0026#xD;\n
\u0026#xD;\n
他们当时的构成是&＃xff1a;一个API团队和一台API服务器、一个前端团队和一台前端服务器、一个平台团队和一台后端服务器、一个广告团队和一台广告服务器、由基础设施团队管理的一大堆数据存储&＃xff0c;以及一个分析团队使用的Hadoop集群。前端团队使用无状态的PHP、HTML和Javascript开发&＃xff0c;状态和存储由后端服务器管理&＃xff0c;消息队列用来处理长时间运行和非事务处理。
\u0026#xD;\n
他们最不一般的做法&＃xff0c;是用基于gevent的Thrift服务器作为后端服务器&＃xff0c;因此在gevent和开发gevent安全的客户端池上耗费了很多时间。
\u0026#xD;\n
我可能再也不会用Thrift作为Python服务器了&＃xff0c;因为再也不想维护一个类似的服务器。
\u0026#xD;\n
他们同时使用Tonardo、Apache&＃43;mod_wsgi&＃43;Pylons、gevent服务器作为后端服务&＃xff0c;虽然让Will有点不爽&＃xff0c;但是在实际工作中&＃xff0c;整个团队并没有多大困扰&＃xff0c;主要原因是使用了Jenkins和Puppet来部署系统。
\u0026#xD;\n
在总结中&＃xff0c;Will认为&＃xff1a;
\u0026#xD;\n
我们的流程和结构还是比较合理的&＃xff0c;而且也很有效。如果今天重头来过&＃xff0c;我们当然会有不一样的方式&＃xff0c;或者要是我们的团队没有那么快减员&＃xff0c;或者要是我们没有同时应对那么多技术债务&＃xff0c;包括遗留系统、API和代码契约等等。
\u0026#xD;\n
Will还想再谈谈Digg的数据库和技术方面的不断扩展&＃xff0c;他们用过的技术包括&＃xff1a;Cassandra、MySQL、Redis、Memcache、HDFS、Hive、Hadoop、Tornado、Thrift服务器、PHP、Python、Pylons、Gevent等等。请关注InfoQ中文站的后续报道。
\u0026#xD;\n
注&＃xff1a;
\u0026#xD;\n
康威定律&＃xff1a;Conway&＃39;s Law&＃xff0c;由计算机科学家Melvin Conway在1968年提出&＃xff0c;其内容是&＃xff1a;设计系统的组织&＃xff0c;最终产生的设计等同于组织之内、之间的沟通结构。
京公网安备 11010802041100号