图为 HDC 大会余承东先生公布鸿蒙开源代码地址

风风火火的鸿蒙开源的事情已经过去4天了，此刻我的心情才稍微平缓了过来，作为近期被针对的目标之一，华为可以说在很久很久之前就做了准备，不得不佩服任老的视野和远见，美国的禁令来的如此迅速，华为的应对也非常及时。早在2019年，老大红薯就开始频繁给我打预防针，鸿蒙可能会在2020年开源，我们需要做足准备，来应对可能来的大量的访问压力。所以年初由于疫情的原因在家远程的时候，我们就开始了这一块的准备，与其它抢购等场景一样，主要会涉及到3各层面：

1. 高防防护（如果被D了该怎么办？
2. 带宽（大量的开发者涌入下载，带宽不够怎么办？
3. 系统负载（大量的下载操作，IO顶不住怎么办？

简单分三个层面来总结一下

1、高防防护

Gitee 从2015年就开始遭受各式各样的攻击：DDOS、CC攻击、撞库等等，其中最让人头疼的莫过于DDOS流量攻击，这种类型的攻击可以说是非常流氓了。

举个简单的例子，咱们开了家便利店，提供各种商品的售卖服务，正常情况下，顾客来店里面看看挑挑，买完就走，但这个时候有人看你不爽，找了一大堆枪手，一拥而上堵住了我们的门口，让那些想要买东西的正常顾客根本无法进入，这就是DDOS，黑客使用大量的肉鸡，频繁的往你的IP发送包（最常见的是UDPFLOOD攻击）导致带宽被占用，正常的用户访问卡顿甚至无法访问。更坏的情况是，警察发现便利店门口聚集了大量的人，可能会导致整个街道出现混乱，于是便选择强制关闭了便利店，所以这就是运营商为了保证同线路其它客户的正常访问采取的封禁措施，一般是1个小时，如果1个小时内无后续攻击，则会自动解封。

为了解决这种问题，最原始的方式是拼IP资源池，因为带宽我们无法拼过，我们通过DNS解析的形式切换IP，来使新IP生效，而旧IP失效，但是这种方式有个弊端，DNS解析的切换是有时效的，而且不同的运营商又有DNS缓存，尤其是像鹏博士、方大等小运营商。

所以市面上就出现了DDOS高防防护服务，简单来说就是利用手里庞大的带宽资源来进行抵御，通过对流量的清洗，使得正常流量进入，而异常流量则被黑洞。用上述的例子来说就是，我们在便利店门口设置一个门槛，这个门槛可以容纳非常非常多的客户，并且有保安对每一个客户进行调查，如果是正常用户就放行，反之则丢弃。

所以在鸿蒙开源这件事情上，我们依旧采用了腾讯大禹防护来为我们抵挡可能到来的攻击，前期我们跟大禹团队进行了非常紧密的沟通，将各种场景罗列，并采取对应的措施来为鸿蒙的开源保驾护航。

当然，虽然有大禹产品的防护，但是由于鸿蒙的特殊性，还是免不了更大流量的攻击的可能性，我们在想，如果大禹都撑不住该怎么办，我们也准备了PlanB，如果流量拼不过，如前面所说，只能采用最原始的方法，拼IP资源，所以我们准备了上百个IP，结合DNSPOD的负载均衡功能，来做最后的救命稻草。

2、带宽

带宽主要还是下载量的问题，为了避免可能带来的带宽压力，我们跟安畅以及腾讯都做了非常深入的沟通，带宽主要体现在两方面：

1. 机房的业务带宽
2. 高防的回源带宽

这两部分带宽为了不成为瓶颈，也是沟通了好一段时间，最后非常感谢两个供应商能够统一按照我提的95计费原则进行统一结算，用多少算多少，这也算是给公司省了好一大笔钱。

3、系统负载

最能体现 Gitee 团队技术能力的应该就是这块了，这块所面临的压力主要是以下两方面：

1. 用户访问页面查看代码、提交、差异、PR等
2. 用户通过https、ssh进行代码的下载

整个鸿蒙OS的代码是通过repo工具进行下载的，repo 工具是一个批量管理 Git 工程的工具，它是 Google 为了管理 Android 项目所开发的结合 Gerrit 的一个工具，可以通过 repo 工具批量下载包含成百上千个 Git 仓库的源代码，而且可以指定并发数，这无疑会对 Gitee 带来不小的压力，所以此刻我们自己的分布式架构中的 Rime 模块就派上了用场，Rime 是一个可扩展的读写分离的设计模块，用来管理 Git 仓库的状态以及同步，并且管理机器的状态。

一般情况下，我们使用一台机器就可以顶住所有的访问以及拉取请求，但是对于一些热门仓库或者企业高频使用的仓库来说，可能是不够的，上面我们说了主要是读操作，所以我们只需要将读操作分发到不同机器进行处理即可，主要有以下两个问题：

1. 如何保证分发的 Slave 机器仓库版本与 Master 机器仓库版本一致
2. 如何保证某一台 Slave 机器挂了，请求不会被分发

如果我们单纯的使用rsync或者结合iNotify，这两个问题都不能保证，所以我们需要有一个机制来统一管理这些仓库和机器的状态，那么 Rime 就是来做这个事情的，Rime 就是一个状态管理机，可以用来管理 Git 仓库以及机器的状态，通过 Rime 的管理，我们可以很轻松的将读的压力分散到各个 Slave 中去，并且可以对异常的 Git 仓库状态以及异常的机器进行剔除，保证请求能够分发到正常的机器。

图为架构示意图，整个架构可以无限的横向扩展，我们为鸿蒙提供了N台机器来负载可能到来的IO压力，并且前期也经过了充分的压力测试。这里需要注意的一个坑就是，如果内网网卡是千兆网卡，需要考虑分流（如果是万兆网卡可以忽略）。

架构的细节不在这里细说了，后续我准备写一个《Gitee 架构回忆录》系列，来展开说一下 Gitee 在7年来架构上的发展的瓶瓶罐罐。

总结

鸿蒙开源是 Gitee 成立七年来的一次大考，开源前的一周基本没怎么睡好，就我个人而言压力还是非常大的，毕竟是一个无法预知的量级，我能做的就是做好一切准备工作，投入一切可使用的资源，做好一切可调度的资源预案。其实开源前做了非常多的自问自答，如果出现了什么情况，该怎么处理，其实就如上学的时候备考，能做的题型都做一遍，想象可能出现的各个知识点结合的可能，有备无患，剩下的就是临场发挥，考验应急能力的时候了，准备的越充足，越不容易乱阵脚，好在鸿蒙开源当日，一切顺利，并没有出现太大的问题，资源的准备也满足需要，一颗悬着多日的心终于放了下来，终于不负信誓旦旦在华为开源作战室那句「放心吧，没问题的！」

最后用余老师的一句话：

没有人能够熄灭满天星光，每一位开发者都是华为要汇聚的星星之火，星星之火可以燎原！