大型公司开发软件的流程是怎样的?

关注者
2472
被浏览
196311

34 个回答

这是一个悲伤的故事:

// actually this should be a singleton, anyway I've made it global
Boss theBoss; 

Game* MakeAGame(Manager theProducer, 
                std::list<Designer>& designers, 
                std::list<Programmer>& programmers)
{
	if (designers.empty())
		return NULL;
	if (programmers.empty())
		return NULL;

	Game* theGame = new (nothrow) Game(theBoss.GetALotOfMoney());
	if (!theGame)
		return NULL;
		
	// do the initializing work
	theGame->SetPlatform(theBoss.currentPhone.Platform);
	theGame->SetGameType(FindMostProfitableGameType());
	foreach (Designer designer : designers)
	{
		theGame->AddDesignDocuments(designer.docsFromElsewhere);
	}
	theGame->bugCount = 0;
	
	// the main loop (each iteration is a release cycle)
	while (true)
	{
		auto thisRelease = scoped_ptr<Milestone>(new Milestone());
		
		int intensity = theProducer.Push(designers, programmers);

		foreach (Designer designer : designers)
 		{
			designer.Press("Ctrl", "C");
			designer.Press("Ctrl", "V");
		}
		
		foreach (Programer programmer : programmers)
		{
			programmer.Hack(thisRelease, intensity);
		}
			
		theGame->bugCount += thisRelease->bugCount;
		if (theGame->IsPlayableWithoutCrash())
		{
			theProducer.Broadcast("Let's ship it!!!");
			break;
		}

		theProducer.CallForDelay();		
	}
	
	return theGame;
}
如果上边的故事太长的话,这是一个化简版:

-----------

v 1.04 修复 @蛋丁 同学提到的内存泄漏
v 1.03 @程睿 同学说参数太多,嗯嗯,俺虚心接受,想了想,把 theBoss 改成全局的了。
v 1.02 把传值的 std::list 改成std::list&,本来想传常引用的,不过想想还是算了。这个捏其实也是照顾广大还没用上 C++11 的同学的习惯,C++11 通常是 std::move 进来就可以了。
v 1.01 修复了 @阿峰 同学报的 bug,Hack() 传入 thisRelease 应该就好了吧 :)

有关阿里集团在打造支撑百万用户的分布式代码托管平台,这里分享一篇阿里技术协会的内部文章,本文主要介绍了阿里巴巴集团代码服务团队,在过去一年基于GitLab进行的代码托管分布式改造,希望与大家进行分享与探讨,为云上开发者提供更好的代码托管服务。

一、背景介绍

毋庸置疑,代码是DevOps流程的起点,是所有研发流程的基础;代码托管为代码“保驾护航”,确保代码的安全性、可用性,同时提供围绕代码的一些基础服务,如MRIssue等等。

阿里巴巴集团GitLab是基于GitLab社区版8.3版本开发,目前支撑全集团数万规模的研发团队,累计创建数十万项目,日请求量千万级别,存储TB级别,早已超过了GitLab社区版承诺的单机上限能力,且增长速度迅猛。

面对这种情况,顺理成章的做法就是——扩容。然而非常不幸,GitLab的设计没有遵守Heroku推崇的“The Twelve-Factor App”的第四条:“把后端服务当作附加资源”(即对应用程序而言,不管是数据库、消息队列还是缓存等,都应该是附加资源,通过一个url或是其他存储在配置中的服务定位来获取数据;部署应可以按需加载或卸载资源),具体体现是:

  • Git仓库数据存储于服务器本地的文件系统之上
  • GitLab所依赖的三个重要组件:libgit2、git、grit也都是直接操作在文件系统上GitLab

所以GitLab社区版是基于“单机”模式设计,当存储容量和单机负载出现瓶颈时,难以扩容!

二、面对挑战

2015年初,阿里巴巴集团GitLab的单机负载开始呈现居高不下的情况,当时的应对方案是同步所有仓库信息到多台机器,将请求合理分配到几台机器上面从而降低单机的负载。然而这个方法治标不治本:

  • 系统运行过程中的数据同步消耗资源和时间,不可能无限制扩充机器
  • 这种方案暂时缓解了单机负载的问题,但对于单机存储上限的问题束手无策

2015年中,团队正式启动了第一次改造尝试,当时的思路是去掉对本地文件系统的依赖,使用网络共享存储,具体思考和方案可以参见RailsConf 2016 - 我们如何为三万人的公司横向伸缩 GitLab

然而由于本地缓存等问题的限制,网络共享存储的方案在性能上出现较明显性能问题,且大都为基于C/C++的底层改动,改造成本出现不收敛情况。而当时集团GitLab服务器在高峰期CPU屡屡突破**95%**甚至更高的警戒值,而高负载也导致了错误请求占比居高不下,无论是对上游应用的稳定性还是对用户体验都提出了严峻挑战。

2016年8月起新一轮改造开始。

三、改造方案

既然共享存储的方案暂时行不通(后续如果网络存储的读写性能有质的提升,未尝不是好的方式),首先明确了唯有分布式或者切片才能解决问题的基本思路。 我们注意到,GitLab一个仓库的特征性名称是"namespace_path/repo_path",而且几乎每个请求的URL中都包含着个部分(或者包含ID信息)。那么我们可以通过这个名称作分片的依据,将不同名称的仓库路由到不同的机器上面,同时将对于该仓库的相关请求也路由到对应机器上,这样服务就可以做到水平扩展。

下面通过一幅图介绍一下目前集团GitLab在单个机房内的架构。



3.1 各个组件的功能主要是:

  1. Sharding-Proxy-Api用于记录仓库与目标机器之间的对应关系,可以看作切片的大脑
  2. Proxy负责对请求做统一处理,通过Sharding-Proxy-Api获取信息,从而将请求路由到正确的目标机器
  3. Git Cluster由多组节点构成,每组节点内有三台机器,分别为master,mirror和backup。其中master主要负责处理写(POST/PUT/DELETE)请求,mirror主要负责读(GET)请求,backup作为该节点内的热备机器

说明

  • master在处理完写请求后,会同步更新此次变更到mirror和backup机器,以确保读请求的正确性和热备机器的数据准确
  • 之所以没有采用双master的模式,是不想造成在脏数据情况下,由于双向同步而造成的相互覆盖

3.2 保证方案可用

  • 如何确保切片信息准确 Sharding-Proxy-Api基于martini架构开发,实时接收来自**GitLab**的通知以动态更新仓库信息,确保在namespace或project增删改,以及namespace_path变更、仓库transfer等情况下数据的准确性。 备注:这样的场景下,等于每次请求多了一次甚至多次与Sharding-Proxy-Api的交互,最初我们曾担心会影响性能。事实上,由于逻辑较为简单以及golang在高并发下的出色表现,目前Sharding-Proxy-Api的rt大约在5ms以内。
  • 如何做到切片合理性 海量数据的情况下,完全可以根据namespace_path的首字母等作为切片依据进行哈希,然而由于某些名称的特殊性,导致存在热点库的情况(即某些namespace存储量巨大或者相应请求量巨大),为此我们为存储量和请求量分配相应的权重,根据加权后的结果进行了分片。目前来看,三个节点在负载和存储资源占用等方面都比较均衡。
  • 如何处理需要跨切片的请求 GitLab除了对单namespace及project的操作外,还有很多跨namespace及project的操作,比如transfer project,fork project以及跨project的merge request等,而我们无法保证这些操作所需的namespace或project信息都存储在同一台机器上。 为此,我们修改了这些场景下的GitLab代码,当请求落到一台机器同时需要另一台机器上的某个namespace或project信息时,采用ssh或者http请求的方式来获取这些信息。 最终的目标是采用rpc调用的方式来满足这些场景,目前已经在逐步开展。

3.3 提升性能

  • ssh协议的替换 目前阿里巴巴集团GitLab提供ssh协议和http协议两种方式,供用户对代码库进行fetch和push操作。其中,原生的ssh协议是基于操作系统的sshd服务实现,在GitLab高并发ssh请求的场景下,出现了诸如这样的bug:

由此产生的问题是:

ssh协议登陆服务器变慢

用户通过ssh协议fetch和push代码时速度变慢

为此,我们采用golang重写了基于ssh协议的代码数据传输功能,分别部署在proxy机器以及各组节点的GitLab服务器上。由此带来的好处有:

机器负载明显降低

消除上述bug

在ssh服务发生问题的情况下,仍旧可以通过ssh登陆(使用原生)服务器,以及重启sshd服务不会对服务器本身造成影响

下图是proxy机器采用新sshd服务后的cpu使用情况:


  • 个别请求的优化和重写 对于一些请求量较大的请求,例如鉴权、通过ssh key获取用户信息等接口,我们目前是通过文本转md5,加索引等方式进行性能优化,后期我们希望通过golang或java进行重写。

3.4 确保数据安全

  • 一主多备 如上面提到的,目前阿里集团GitLab的每组分片节点包含有三台机器,也就是相对应的仓库数据一备三,即使某一台甚至两台机器发生磁盘不可恢复的故障,我们仍旧有办法找回数据。
  • 跨机房备份 刚刚过去的三月份,我们完成了阿里巴巴集团GitLab的跨机房切换演习,模拟机房故障时的应对策略。演习过程顺利,在故障发生1min内接到报警,人工干预(DNS切换)后5min内完成机房间流量切换。 多机房容灾的架构如下图所示: pic3.zhimg.com/v2-3716c 保证准实时的仓库数据同步是机房切换的基础,我们的思路按照实际需求,由容灾机房机器主动发起数据同步流程,基本步骤是:
    • 利用GitLab的system hook,在所有变更仓库信息的情景下发出消息(包含事件类型及时间包含数据等)
    • 同机房内部署有hook接收服务,在接收到hook请求后对数据进行格式化处理,并向阿里云MNS(Message Notify Service)的相关主题发送消息
    • 容灾机房内,部署有消息消费服务,会订阅相关的MNS主题以实时获取online机房发送到主题内的消息,获取消息后调用部署在容灾机房GitLab节点机上的rpc服务,主动发起并实现数据同步的逻辑
    • hook接收、消息消费以及**GitLab**节点机上的rpc服务,均由golang实现。其中rpc服务基于grpc-go,采用protobuf来序列化数据。 通过一段时间的运行和演习,已经确定了方案切实可行,在数据校验相关监控的配合下,容灾机房可以准实时同步到online机房的数据,且确保99.9%至99.99%的数据一致性。

3.5 如何提升系统的可用性

  • 日志巡检 面对集团GitLab每天产生的大量日志,我们使用阿里自研的监控工具进行日志监控,对系统产生的5xx请求进行采集和报警,然后定期去排查其中比较集中的错误。经过一段时间的排查和处理,5xx错误日志大致可以分为:
    • 分布式改造带来的跨分片操作的bug
    • GitLab本身的bug
    • 高并发情况下带来的系统偶发性故障
    • 数据库相关的错误等
    • 由于用户量大,场景多,阿里巴巴集团GitLab的使用场景基本覆盖GitLab的所有功能,因此也可以暴露出一些GitLab自有的bug。如Fix bug when system hook for create deploy key(从此,咱也是给GitLab供献过代码的人了)。
  • 服务器监控 无论系统多少健壮,完备的监控是确保系统平稳运行的基础,既可以防患于未然,也可以在问题出现时及早发现,并尽可能减小对用户的影响。目前阿里巴巴集团GitLab的监控主要有:
    • 机器cpu,内存、负载等基本指标的监控
    • ssh、ping等网络检测信息(用于判断是否宕机,后将详述)
    • 服务器各个端口的健康检查(80,90xx,70xx等等)
    • 异步消息队列长度的监控
    • 数据库连接的检查
    • 错误请求的监控
    • Sharding-Proxy-Api与GitLab的数据一致性校验
    • 很自豪的一点是,我们经常可以根据报警信息,先于用户发现问题。
  • 单机故障的自动切换 虽然监控足够完备,但谁也不能保证服务器永远不宕机,因此我们在同一组节点中保有一台backup机器以应对服务器故障。会有专门的client定期通过API轮询监控平台提供的机器监控信息,当确认机器宕机时(ssh和ping同时不通,且持续时间超过2min)自动触发机器角色的互换,包括master与backup互换,mirror与backup互换等。通过演习,我们已经具备了单机故障时5min内全自动实现机器切换的能力。
  • 机房故障时的切换 即前述的跨机房切换。

3.6 单元化部署

单元化架构是从并行计算领域发展而来。在分布式服务设计领域,一个单元(Cell)就是满足某个分区所有业务操作的自包含的安装。而一个分区(Shard),则是整体数据集的一个子集,如果你用尾号来划分用户,那同样尾号的那部分用户就可以认为是一个分区。单元化就是将一个服务设计改造让其符合单元特征的过程。

为了实现单元化的目标,我们在最初设计时就往这方面考虑。比如跨机房备份中,消息消费应用需要调用**Sharding-Proxy-Api**获取rpc服务的地址时,尽可能做到数据在单机房内闭环。这样在满足单元化要求的同时,也可以在机房故障时,尽量不影响已进入队列的消息在消费时出现数据断流。

现在阿里巴巴集团GitLab在架构上已经基本具备了单元化部署的能力,这样的情况下,无论是后续与阿里云合作对外提供服务,还是当收购海外公司需要单独搭建新服务时,都不会遇到问题。

四、未来的改进

4.1 偶发的cache大量释放

由于GitLab有大量的IO操作,使得系统占用cache的数值巨大,也正是因为cache,系统的性能得到保证。然而成也cache败也cache,为了确保系统不会发生OOM,我们设定了vm.min_free_kbytes,当cache占用过多且需要继续申请大片内存时,会触发cache的释放,势必会影响释放瞬间请求处理能力(通过日志分析得到,此瞬间的处理能力仅为cache存在时的1/2左右),直接后果是该瞬间的请求堵塞,甚至出现部分502。

为此我们咨询了系统部的同学,根据他们的建议修改了部分内核参数(目前仍没有根治),后续会尝试升级内核的方式,也希望遇到过类似问题或对这方面问题有研究的同学,把你的秘籍传给我们。

4.2 自动化运维

目前集团GitLab的发布主要靠手,在分布式架构下,机器势必越来越多,全自动化的发布、扩容机制,是我们需要完善的地方。

4.3 rpc方案的最终落地

如前所述,只有最终实现了全局的rpc替换,才能将web服务所消耗的资源与Git本身消耗的资源进行分离,阿里巴巴集团GitLab的分布式改造才能算最终结束。

后续

监控及日志数据对比显示,过去一年中阿里巴巴集团GitLab请求量增长4倍,项目数增长130%,用户数增长56%,在这样的增速下,系统调用的正确率却从99.5%提升到了99.99%以上,这些数字印证了我们方案的可行性和可用性。

接下来的时间里,小伙伴们会为继续代码服务的创新而努力,“高扩展、分布式、响应式、大文件、按需下载、流控、安全、数据化、单元化”,有些我们做到了,有些是接下来努力的方向。

现在阿里巴巴集团GitLab的架构,已经足够支撑百万规模的用户体量。在经过阿里工程师、开发者的千锤百炼之下,我们有勇气和信心通过阿里云code(阿里云代码开发服务现可免费使用)为更多的开发者提供代码托管服务,共同打造云上的协同研发生态!

本文作者:billy.lb 屹恒

有关:阿里云 code

这是一款从未在外面推广过的代码托管产品,估计很多人还不知道阿里云有这个服务。阿里云code旨在解决部分中小企业选择内部自行搭建 Git或SVN ,势必会遇到搭建、维护成本高,难于扩展和备份,数据安全和可靠性差的问题。

核心优势——阿里云上基于Git的分布式代码托管,高可用、安全、高性能以及无限容量是其核心竞争力,支持svn仓库的便捷迁移。

目前已面向个人或企业免费提供Git及SVN两种协议模式的代码托管服务:点击免费使用

更多几乎干货请移步:我是程序员 - 知乎专栏