这篇文章是开源大会上关于CODE平台介绍的完整版，其实早应该放在官方博客上的。里面详细讲述了我们平台选型过程和系统架构，希望能给对CODE结构有兴趣的朋友一些参考。
CODE系统架构
CODE平台在初期经过一番调研后，我们锁定了几个Git服务的开源项目：Gitorious，Gitlabhq，Gitblit。其中Gitblit是java实现，具备核心功能，性能上有优势，但整体上不太成熟。 Gitorious和Gitlabhq都是比较成熟的实现，并且和Github一样，都是基于RoR实现，可以共享很多开源资源。我们仔细比较了 Gitorious和Gitlabhq，整体上来说软件架构很像，都使用Grit访问Git仓库，都是用RoR。虽然Gitorious的功能更加完整，但Gitlabhq很好的使用了各种开源Rails插件，如，用Devise实现登录，用SIX实现权限管理，用Grack实现Git over Smart HTTP，Bootstrap作为前端框架等，代码整洁易懂。代码好维护是软件工程中太重要的一个衡量指标了，虽然当时Gitlabhq4.2还使用 Gitolite作为Git仓库管理，是个必须改造的累赘，经过权衡，我们还是选择了Gitlabhq作为我们基础来实现。
系统架构如下：
作为Git服务，功能上就是要实现Git仓的Web访问和比较常用的三个协议：SSH， Git， Smart HTTP。Web访问就不用说了，就是Git仓的WEB展现。SSH因为其安全性，基本上是使用Git开发者进行pull/push最常用的协议。 Git协议只支持Clone，因为其效率最高，深受喜爱。Smart HTTP则最方便，而且使用最通用的80端口，不会被公司防火墙屏蔽。功能上来讲，实现起来问题不大。仔细考虑一下，就会发现其中最大的难题，在于解决大规模部署，数据安全，动态扩展等平台维护功能上。
作为Git公众服务，不可避免的Repos会非常的庞大，并且随着用户量的增加需要动态的扩展。对此，常规的有两种方案：
方案1：使用分布式文件系统：
系统由多个Server和一个分布式文件系统组成， 由负载均衡器负责随机分发用户的各种请求给每个Server。每个server实现所有的Git服务(WEB， SSH Listener, Git Listener, Smart HTTP Listener)，所有的server可以共享一个分布式文件系统。通过Posix挂接到Server的特定路径。DFS可以根据需要动态的扩展，也负责数据容灾和高可靠性。
方案2：使用分布式后端：
系统由前端(FE)和后端(BE)组成。后端保存所有Git仓库，负载均衡把用户请求平均分配给前端，前端根据请求类型，分别通过远程调用、透明代理访问后端的Git仓库。
分布式文件系统实现起来比较简单，但考虑到目前分布式文件系统都只适合于大文件的存储，而Git恰恰都是大量的小文件操作，性能以及存储利用率都非常成问题。所以我们选择了分布式后端的方案。分布式后端充分的使用了所有后端机器的计算能力，需要实现Grit库的远程调用以及SSH， Git的代理，后端路由表，而且为了实现高可靠性，每个后端都必须是一对，提供服务的高可靠性以及保证数据安全。
到此，我们可以逐个功能分析一下工作原理：
1. Web访问。用户提交请求， 首先会到达负载均衡。负载均衡会把用户请求发送到任意一个前端，前端运行Web服务器，我们的Rails应用会处理用户的请求，根据用户请求的Git仓库， 查询到仓库所在的后端。通过Grit远程调用访问后端数据，然后变为HTML展现给用户。
2. SSH访问。 Git over SSH通过publickey鉴权，用户执行git命令后，Git客户端会把相应的Git命令，用户的publickey，以及访问的Git仓库名发送给服务器。请求首先会到达负载均衡。负载均衡会把请求发送到任意一个前端，前端有一个经过我们改造的OpenSSH的服务，首先会根据请求中的 publickey，仓库名以及git命令到数据库中查询权限，如果允许，前端则通过路由查询到Git仓所在的后端，并且把SSH连接代理到相应的后端，后端SSH listener完成数据读取，通过前端的SSH代理传给用户。
3. Git 访问。Git协议用来 Clone公开的仓库。同样用户执行git命令后，Git客户端会把相应的Git命令，访问的Git仓库发送给服务器。请求首先会到达负载均衡。负载均衡会把请求发送到任意一个前端，前端有一个我们的Git Daemon服务，该服务首先检查所访问的仓库是否是公开仓库，若是，则把把请求代理到相应的后端执行。
4. Smart HTTP访问。 HTTP协议的代理和负载均衡都比较成熟，同理可以很容易的实现Smart HTTP的处理。
不难分析出搭建系统的一些要点：
• 负载均衡需要支持HTTP， SSH， Git等协议。我们在选择了LVS后，惊喜的发现，阿里云的LBS完全能够满足以上协议，使用之。
• 需要改造OpenSSH，使它能够支持大量的用户使用Git的功能。主要是存储Publickey采用数据库，和Git系统的结合接口。我们通过改造OpenSSH完成。
• 需要实现Git Daemon，因为Gitlabhq没有支持Git协议，Git自带的Git Daemon性能不适合于大并发，我们自己用GO语言实现了一个Git Daemon。GO语言作为能够处理高并发的高级语言，其开发效率和Ruby可以媲美。我们已经开源了此项目： https://code.csdn.net/CSDN_Code/code_git_daemon ，欢迎大家一起完善。
• 需要实现SSH 和Git Proxy，完成前端到后端的透明代理。
• Grit 远程调用，完成前端WEB应用对后端Git仓库的访问。
• Grit库的优化以及中文支持。在实现过程中，我们发现Grit库对中文支持不够好，中文文件名，中文Branch以及Tag等都存在问题。如果使用Gollum，会发现wiki页面也不支持中文名。我们都对此专门进行了修改。同时Grit在有些方面性能也有很大的瓶颈。我们也在Github上对我们所做的修改推送给了原项目，如果Grit库的维护者接受了我们的修改，大家就能看到一个全面支持中文的系统了
CODE安全架构
作为代码托管服务，系统的安全性是需要特别着重考虑的因素之一。其中最为重要的，莫过于用户数据的健壮性，我们在此方面上了三道保险：
图：CODE平台安全架构
在基础平台安全层面，我们从物理安全，网络安全，系统安全三方面给予CODE平台最牢靠保障。首先，CODE采用阿里云的存储，保证数据同时有三份，定期备份同步用户数据到备份服务器，在某些灾难情况下也可以恢复用户的数据。其次，CODE采用具备负载均衡及双机热备功能的设备持续提供网络服务，其强劲的网络防护设置能有效防护各类网络攻击，并实时网络状态监控。再次，CODE 拥有持续的端口入侵扫描，挂马扫描，漏洞扫描防护，保证系统最新补丁持续及时更新，实时的系统状态监控，有效防止过载及溢出错误。
在中间应用安全层面，CODE提供多种安全传输协议,对各应用均进行特定的安全加固，实行实时应用服务状态监控，以最大限度的保障应用安全。每日的数据都有多份备份副本，并实施安全的数据访问控制，各用户数据相互独立，实时用户数据操作记录以保障数据安全。口令安全方面，CODE采用统一的网站登录方式，存储及登录时均使用加密操作，并提供用户对SSH协议key的自行管理。
在管理安全层面，CODE使用了堡垒机机制，具备完整的安全管理操作策略及手册、完备的应急恢复策略和详尽的日志审计，保证所有的操作人员的操作权限明确，并且都有纪录可查。全站使用了HTTPS协议，保证各协议接口都安全可靠。
我们正在奋力打造一个具备完美功能的代码托管平台，现在代码片、组织等功能已经上线，代码搜索、客户端还有一些我们认为适合中国开发者的功能，也会逐步和大家见面。
接下来还希望大家多多鼓励，多多帮助，可以给我们开issue，也可以在论坛发表意见。 当然还可以通过派生我们的项目加入我们的开发。让大家一起努力打造中国良好的生态环境!
