"伤得起"的云计算应用——对云端应用之架构的思考
2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障，导致许多商业网站的服务中断，影响非常严重。作为云计算用户，我们需要思考的是，如何保证即便在云服务不可用的情况，我们的应用架构仍然能够屹立不倒？本文正是站在云计算用户的角度试图探讨这一问题。
文章
该内容已经被标记书签！
标记书签错误，请重试！
为什么我们要放弃Subversion
作者 胡凯 发布于 2009年3月16日
Subversion曾经是我们亲密无间的战友，但自从一年前部分团队成员去了美国，我们和Subversion的关系就开始出现了裂痕，首先是将Subversion服务器架设在美国后，中国开发人员频繁进行的一些操作变得非常缓慢，本来通过追溯代码历史便可找出原因的问题，却因为网速缓慢，导致开发者将大量的时间耗费在等待服务器响应，而不是分析问题上。其次，由于缺乏IT基础设施方面的投资以及完善的备份策略，数次因为网络原因或者服务器宕机，导致团队无法从中国访问版本管理服务器，正常的提交、更新操作都无法进行，最严重的是版本管理服务器曾经在发布之前出现故障，导致服务器上的数据不得不回滚到九天以前，给发布带来了很大的风险。
相关厂商内容
从现象上看，版本管理服务器不在本地是遭遇速度瓶颈的主要原因，本质却是由于版本管理工具不能很好的根据团队的规模和结构伸缩。对我们而言，比较理想的版本管理解决方案是在中美两地架设服务器，加快各个操作的执行速度，服务器之间自动同步来平衡两地对于速度和代码集成的要求。然而采用Subversion 作为版本管理工具，决定了服务器仅能架设在一地。SVK可以解决部分问题，但它的缺陷太多，操作起来非常不便。我们所面临的备份问题则是由于在Subversion的设计中，所有的元数据仅仅保存在服务器上，一旦服务器出现意外，元数据所包含的宝贵信息便无从恢复。之前的教训让我们认识到如果采用Subversion作为版本管理工具，就不能仅仅乐观的假设服务器不会出错，必须有详尽可行的备份计划，通过不断备份来规避风险。
Subversion的这些天生缺陷让我们把目光投向了DVCS（分布式版本管理工具），在这个家族中，比较成熟的产品有Git、Mercurial和Bzr，相比之下，由于Mercurial对Linux，Mac和Windows平台有良好的支持，支持通过Web方式访问代码库，并存在成熟的IntelliJ、Eclipse插件，最终成为了胜出者，时至今日，它已经在我们团队服役超过1年了，从0.9.4到1.1.2，每一次版本的更新，都让我们愈加喜欢这个设计精巧产品。那么较之Subversion，Mercurial究竟胜在哪里？
快速可靠
Mercurial带给团队的第一个体验就是快，原因很简单，由于DVCS的工作目录与中央仓库（Central Repository）别无二致，同样保存了全部的元数据，那么Subversion需要通过网络完成的操作(诸如提交、追溯历史、更新等), Mercurial可以在离线条件下通过操作本地仓库完成（图-1）。
图-1
通过减少与中央仓库的通信, Mercurial加快了操作速度，减小了网络环境对团队的影响，非常符合我们的需求。这种速度和可靠性的提高，对于时刻与版本管理工具打交道的开发者是一种非常愉悦的工作体验。此外，包含了全部元数据的工作目录可以在中央仓库出现问题时（图2-b）成为备用仓库（图2-c），而整个过程只需运行一条命令即可。
图-2
这样，在IS部门修复中央仓库的过程中，开发团队依然可以通过备用仓库交换修订，日常工作在没有中央仓库的情况下依然可以正常开展，中央仓库恢复后，再将宕机期间所有的修订通过备用仓库同步到中央仓库上（图2-d），这套机制可以作为经费和硬件设施有限团队的备份方案。即便中央仓库完全损毁，所造成的损失也非常有限，避免了使用CVCS时将“所有鸡蛋放在一个篮子里”的风险。
便于协同工作
在日常的工作中，我们常常利用Mercurial灵活的分支合并来共享修改，协同工作。几个月前在印度发布产品时，我需要在新的工作站上安装开发环境，由于代码库庞大而且网速缓慢，克隆中央仓库的操作需要花费数小时才能完成（图3-a），Mercurial的灵活性使我可以将工作站指向已经存有代码的笔记本电脑来执行克隆操作（图 3-b），在数分钟后工作站就完成了全部的克隆操作，之后再将它指向中央仓库（图3-c），即可正常提交/更新代码，大大节省了时间，提高了效率。
图-3
在另一个场景中，由于我所在团队使用Linux作为开发环境，在急于验证某些功能是否在Windows平台可以正常工作时，我们会将代码在Linux工作站本地提交，再将Windows工作站的工作目录指向Linux工作站，获取更新（图4-b）。之后，在Windows 平台验证功能，如果功能存在问题，可以修复后再将修订从Windows工作站提交到Linux工作站（图4-c），最终由Linux工作站运行测试并将全部更新同步到中央仓库（图4-d）。Mercurial的分布式特性让开发团队敏捷的分享修订，更有效率的开发。
图-4
对小步前进友好
本地仓库的存在，使Mercurial对小步前进更加友好 。小步前进意味着开发者在不破坏任何现有功能的前提下，每次修改少量代码并提交。这两个需求让使用集中式版本管理工具的开发者常常处于两难的境地，”不破坏现有功能“与“每次修改少量代码并提交”意味着存在便于分析的细粒度需求以及开发人员必须掌握增量式的对象建模、重构，数据库设计、迁移等技术。难于小步前进体现的是团队成员经验和技术的欠缺，然而解决这些问题不是一朝一夕之功，本地仓库的存在给了开发者更大的自由，允许开发者频繁提交而无需顾忌是否每一次提交都不会破坏现有功能，在代码经过若干次提交到达稳定状态时再与中央数据库同步。通过使用Mercurial，使得小步前进这个实践得以在团队开展，在大家体会到实践带来的好处后，再追求高质量的小步前进。
学习曲线低
Mecurial灵活的分支合并策略使我们可以选择与CVCS(集中式版本管理工具如Subversion，CVS等)非常相似的架构（如图-1所示），这样，团队在更换版本管理工具后依然可以工作在相对熟悉的环境中。在(图-1)所示的结构中，开发者需首先架设中央仓库，再从中央仓库克隆出工作目录，在开发过程中，开发者将修订提交到本地仓库，最后，在功能完成后将本地仓库的所有修改同步到中央仓库。除了最后一步，其余步骤和CVCS完全一致，开发者可以很快对Mercurial总体架构建立初步的认识。Mercurial的基本命令与CVS/Subversion非常类似，熟悉CVS/Subversion的团队可以依然工作在熟悉的命令行环境。从结构到命令，Mercurial做到了对CVCS用户友好，降低了学习曲线，让开发者可以相对轻松的跨出从CVCS到DVCS的第一步。如果仅仅想作一下尝试，又或者公司的政策不允许将版本管理工具从Subversion迁移到Mercurial，Mercurial还提供了HgSubversion插件可供选择，它可以将Mercurial作为Subverion的客户端使用，这样，既可以保留Subversion版本管理服务器，又可以在本地采用Mercurial来享受DVCS的种种好处，使开发者可以非常安全过渡到DVCS环境。
总结
毫无疑问Subversion是非常优秀的版本管理工具，但是它有自己的适用范围，并不是银弹。抛弃 Subversion，也不因为我们是新技术的狂热分子，而是它无法伸缩来适应团队的结构变化。对于希望尝试DVCS的团队，我的几个建议是：决策者首先要识别团队的痛点，对问题域有清醒的认识，而不能仅仅追赶技术潮流，其次是使用它、慢慢的接受它，如果团队仅仅止于理论方面的学习，各种方案的论证，是无法掌握DVCS并利用它来提高团队效率的，最后整个团队需要持续学习DVCS背后的设计思想，对于问题域的抽象以及丰富的插件的使用方法。这些知识将直接或间接的帮助团队提高进行代码版本管理的能力，更有效律的管理代码。
感谢
感谢我的同事杨哈达，初悦欣，乔梁和陈金洲在我写作过程中提供的无私的建议和帮助。和杨哈达的讨论让我对于DVCS的理论有了更清楚的认识，初悦欣和我一起重构了插图，乔梁和陈金洲对于文章的结构提出了很多意见和建议。
这篇文章是我在工作中从熟悉的Subversion迁移到Mercurial的经验分享，在这个过程中有不适应，也曾经犯了很多错误并获得了许多经验。希望读者能从这篇文章中有所收获，从DVCS在我们团队的实践了解到DVCS可能带给自己团队的价值，更有信心的进入DVCS领域。
作者简介
胡凯，ThoughtWorks敏捷咨询师，近2年一直从事持续集成工具Cruise以及CruiseControl的设计开发工作。 对于Web开发，敏捷实践，开源与社区活动有浓厚的兴趣，可以访问他的个人博客进行更多的了解。
相关阅读
[ ThoughtWorks实践集锦（1）] 我和敏捷团队的五个约定。
[ ThoughtWorks实践集锦（2）] 如何在敏捷开发中做好数据迁移。
[ ThoughtWorks实践集锦（3）] RichClient/RIA原则与实践（上）、（下）。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
又看到Zee哥的强文了，呵呵
发表人
Dun David
发表于
Re: 又看到Zee哥的强文了，呵呵
发表人
see sai
发表于
Re: 又看到Zee哥的强文了，呵呵
发表人
胡 凯
发表于
画图工具用的是什么呀？
发表人
刘 平平
发表于
Re: 画图工具用的是什么呀？
发表人
shao jim
发表于
branch不尽如人意
发表人
Yang Kenny
发表于
Re: branch不尽如人意
发表人
胡 凯
发表于
Re: branch不尽如人意
发表人
Wu Willie
发表于
本地库不是会越来越大吗
发表人
Zeng SiYuan
发表于
Re: 本地库不是会越来越大吗
发表人
胡 凯
发表于
Git vs SVN
发表人
soft SG
发表于
Re: Git vs SVN
发表人
胡 凯
发表于
Re: Git vs SVN
发表人
Tarzan Wang Tarzan Wang
发表于
收费的版本控制软件Perforce也不错
发表人
Zhong Jove
发表于
SVN加NetBeans本地历史，非常实用。
发表人
Moon Shinson
发表于
请问GIT如何呢
发表人
withyou gakaki
发表于
Re: 请问GIT如何呢
发表人
胡 凯
发表于
Re: 请问GIT如何呢
发表人
Dai Derek
发表于
SVN的一个问题是速度慢
发表人
Wu Gene
发表于
Re: SVN的一个问题是速度慢
发表人
胡 凯
发表于
Re: SVN的一个问题是速度慢
发表人
Peng Arthur
发表于
Re: SVN的一个问题是速度慢
发表人
xuhao pro
发表于
分布式版本管理工具非常适用于分布式开发团队
发表人
Xiao Alex
发表于
偶棉是分布式使用SVN耶～～～
发表人
天色 璎珞
发表于
Re: 偶棉是分布式使用SVN耶～～～
发表人
xu alux
发表于
Re: 偶棉是分布式使用SVN耶～～～
发表人
胡 凯
发表于
权限怎样解决？
发表人
King Steven
发表于
Re: 权限怎样解决？
发表人
Daobing LI
发表于
Re: 权限怎样解决？
发表人
胡 凯
发表于
多个团队异地开发考虑Mercurial，集中开发考虑SVN，毕竟内网速度不会成为问题
发表人
Tarzan Wang Tarzan Wang
发表于
Re: 多个团队异地开发考虑Mercurial，集中开发考虑SVN，毕竟内网速度不会成为问题
发表人
cheng wind
发表于
有道理，但是必要性上有待探讨
发表人
ha lla
发表于
Git呢？
发表人
hack fire
发表于
Re: Git呢？
发表人
茅 盛
发表于
其实作者可能不知道有svn multisite,类似于cc multisite但优于cc multisite
发表人
Jesse Liu
发表于
是否笔误了？
发表人
Zhu Michael
发表于
Re: 是否笔误了？
发表人
han andy
发表于
-
怎么样，Zee，还记得我吗，呵呵
-
p2p技术的？
-
是的，Mercurial可以借助点对点的方式交换修订
-
画图工具用的是什么呀？
图画得还不错哟！！！ -
好像Hg不支持在一个工作目录中开branch
-
office 2007
-
可以用Hg MQ来做到，但确实没有git的支持强大
好像Hg不支持在一个工作目录中开branch
-
那样本地库不是会越来越大吗
-
个人觉得，当程序员的工作主要是离线式的，自由度要求颇高的，且对集中式的，频繁的CodeReview需求不高的，使用Git挺不错，只需熟记几个常用命令就可以，还可以离线工作。
但是对于团队开发，估计还是SVN较为合适。毕竟对于企业内部这种集中式管理环境，SVN的C/S结构天然适合，至少对于分布式版本管理工具而言的优势，对于这种集中开发的公司，就没有优势：
1、速度：内部网的速度问题可以忽略；
2、可靠：企业内部的SVN服务器，基本都是Raid结构，此外，每日增量备份导致出现问题的可能很小； -
你说的对，本地库是会变大，但变大的范围可以接受，我们自己项目的大小约为1.7G，相应的Mercurial本地库大小是450M。对于团队这更多的一种权衡吧，考虑到现在硬盘很便宜，牺牲一些硬盘空间换来稳定性和更好的效率还是比较划算的。
那样本地库不是会越来越大吗
-
>>>速度：内部网的速度问题可以忽略；
如果团队全在一地，速度问题是可以忽略的，但一个公司的团队如果分布在各个国家，特别是中国和美国，中国和印度之间的链接速度还是比较慢的。否则也不会有我在协同工作一节谈到的故事了。
>>>可靠：企业内部的SVN服务器，基本都是Raid结构，此外，每日增量备份导致出现问题的可能很小；
这个还是看企业的资源了吧，不可一概而论。
不过不论是Git还是Mercurial都提供了对svn的支持， gitSvn和hgSvn可以保持集中式的SVN环境的同时，在本地使用DVCS个人觉得，当程序员的工作主要是离线式的，自由度要求颇高的，且对集中式的，频繁的CodeReview需求不高的，使用Git挺不错，只需熟记几个常用命令就可以，还可以离线工作。
但是对于团队开发，估计还是SVN较为合适。毕竟对于企业内部这种集中式管理环境，SVN的C/S结构天然适合，至少对于分布式版本管理工具而言的优势，对于这种集中开发的公司，就没有优势：
1、速度：内部网的速度问题可以忽略；
2、可靠：企业内部的SVN服务器，基本都是Raid结构，此外，每日增量备份导致出现问题的可能很小； -
我们Team用的是这个，可以在各个地区建立服务器，本地程序员只需要连本地的服务器。服务器之间做proxy和备份
perforce的branch功能和revision管理很不错。一张revision graph很清楚的表示这个文件跨越多少分支已经被重构的历史 -
SVN配合NetBeans的本地历史，非常实用。
-
GITHUB的网速国内已经算是蛮快了 我觉得比CODEPLEX 啦 SF.NET google svn都要快
-
如果远程访问，做几次rebase和merge会要人命。
SVN对很多团队来说已经足够了，支持也很丰富。 -
如果rebase操作缓慢，大都是由于网络连接比较缓慢，这样无论用什么版本管理工具都会慢，但DVCS的好处是有良好的离线支持, 减少不必要的网络调用。此外，merge操作在SVN上永远是要人命的。
就基本版本管理功能SVN足够了，然而SVN对于branch这一最普遍的开发实践支持太弱。对于帮助开发者有效率的开发和使用版本管理，SVN还离的很远。如果远程访问，做几次rebase和merge会要人命。
SVN对很多团队来说已经足够了，支持也很丰富。 -
Git也是非常好的版本管理工具，非常快，而且对于branch的支持也非常强大。但是它限制了开发者所使用的平台。
GITHUB的网速国内已经算是蛮快了 我觉得比CODEPLEX 啦 SF.NET google svn都要快
-
我们的情况与作者的描述及其相似，我现在感到十分幸运的是，我的团队在一年多了前也决定使用mercurial。跨地域的网络问题与时差问题是分布式团队时常遇到而又十分头痛的两个主要问题，mercurial极大地减轻了我们在这方面的痛苦。如果你的团队也是一个分布式的开发团队，强烈建议你选择一个类似mercurial的工具；如果你的团队只是本地化的，其实svn也足够用了。
-
蜡果。。如果公司不穷。人员又多。还推荐介个咩？？
偶棉的情况是：
1 北京两百人，杭州三百人，零星人员在美国，各地的人会同时频繁修改同一套代码。
2 最大滴一个库目前26G，统共备份量400G，16万个版本，每天提交400多次。开发环境都在Linux下。
3 代码库需要和Bug库，权限工具，项目管理工具集成。换句话说每个上线，发布，回滚，故障，Bug要和历史代码对应。
4 网络靠VPN，备份靠双机，7天全量，10分钟增量。库后台不是用数据库存储滴。只有当修订版本树的数量超过64位机同一目录下的文件数限制，才会出现传说中的SVN崩溃。
性能嘛，用着还行啊，还行 -
Git can run on Linux, Windows, it's a extreme fast, stable and secure DVCS. I transfered my projects from SVN to Git 6 months ago. In projects with over 18 thousand files, check status or commit just spend only 1 second!
-
DVCS的权限问题一直是软肋。
楼主说到的SVN服务器崩溃，实在令人不解。。。 -
其实这个情况Git应该更适合
-
git 一般每个子项目一个库，所以问题不大
-
这一章对于如何进行权限控制应该说的比较清楚了
hgbook.red-bean.com/hgbookch6.html#x10-1240006.5 -
如果把所有的代码作为一个DVCS库，不说性能，单说硬盘空间可能都吃不消，所以这样的情况，个人觉得Perforce或者Subversion可能会比较合适。
-
不明白说的svn 对branch支持太弱具体指的是什么，svn branch/merge没觉得有什么不方便的
-
去了解一下git吧，再回来用svn就会发现很不方便了。
-
Hg 有許多外掛可以使用，其中內建的 bookmarks 以及 task extension 使用上與 git 的 local branch 相去不遠。
現在 Hg 的開發社群在討論要如何讓 bookmarks 的紀錄也可以經由 push / pull 來傳遞，加上 partial clone 很可能會於 1.4 版整合進來，我是很看好它的。
Git 功能的確很強大，但我覺得 Hg 也不遑多讓就是，各有優缺點。 -
多个团队异地开发考虑Mercurial，集中开发考虑SVN，毕竟内网速度不会成为问题
-
多个团队异地开发考虑Mercurial，集中开发考虑SVN，毕竟内网速度不会成为问题
-
现在团队中，svn服务器放在英国，使用VPN连接，速度确实慢了点，但是考虑到，svn提交后的自动编译和测试服务器，并且由于时差，每天白天这里提交代码，晚上紧接着就是英国，每天都执行分支合并，似乎不现实。
-
对于多个团队异地的情况， 我们用svn mirror解决网速的问题，提交的时候向main server提交(提交的数据量都比较小，所以网速慢点影响不大)，从本地mirror check out。麻烦之处是要自己做main和mirror的switch。而且mirror也起到一个备份的作用。
-
为什么没有选择使用Git呢？
Git也可以在多个平台下运行啊。
Mercurial的优势在哪里呢，能否补充介绍下？ -
Git当然是目前DVCS界最厉害的啦，功能强大，只是Windows下老是MinGW的preview，如果你不在乎用这个+TortoiseGit很不错。
不过我个人更喜欢hg，而且自身的文档也清晰，概念比较少，培训组员蛮容易的。当然我不是说这个比Git强，纯粹是喜好问题。
bzr也不错，那个号称自己的merge是最强的，当然，也有人挑刺过。 -
非常适合跨地域的并行开发，省去了转换新工具的cost。dcvs比较适合个人和小组，在团队协同和企业开发还非常不完备。
-
"即便中央仓库完全损毁，所造成的损失也非常有限，避免了使用CVCS时将“所有鸡蛋放在一个篮子里”的风险。"
此处，CVCS是不是应该换成SVN？ -
"即便中央仓库完全损毁，所造成的损失也非常有限，避免了使用CVCS时将“所有鸡蛋放在一个篮子里”的风险。"
此处，CVCS是不是应该换成SVN？
没错的，svn就是一种CVCS。
37 条回复
关注此讨论 回复