趁热录下来，送给未来的自己。 　　

　　在我们平台的登录系统中，有一个基于github的oauth2.0三方登录的业务场景。由于国内的网络环境，github会很慢甚至无法访问。 　　

　　在互联网上，有很多解决github访问速度慢的方案： 　　

　　这些方法，比如修改hostnginx的反向代理，要么效果不好，要么或多或少不能满足我们的业务场景。 　　

　　但是，方法肯定比困难多。我们的解决方案也经历了几次迭代，最后演变成了一个相对稳定的版本。 　　

　　版本1: 　　

　　将github的三方登录功能分离出来形成一个应用(我们称之为shuttlebee)，然后在有条件访问github的网络环境中部署shuttlebee，通过shuttlebee传输github数据。 　　

　　因此，shuttlebee的第一个版本被放置在实验室的网络环境中，如下所示： 　　

　　但是这个版本有一个比较不稳定的因素：实验室偶尔会断电，断电后电脑无法自动启动。如果有周末或节假日，shuttlebee的服务无法快速恢复。 　　

　　版本2: 　　

　　为了解决实验室网络环境不稳定的问题，shuttlebee被搬到了海外公有云，比如阿里云香港的ECS。 　　

　　这个版本还有一个小问题，就是境外的独立IP可能会被国内的墙打破。虽然是小概率随机事件，但如果发生，就是生产失败。 　　

　　版本3: 　　

　　直到上一次S-cluster验收的会议，无意中知道S-cluster可以代理走实验室网络出口。那么，我们在国内公有云上的服务是否也可以由实验室来代理呢？经过与其协商，获得了实验室的代理IP和端口。我们只需要给实验室代理添加相应的shuttlebee服务，就可以在国内公有云网环境下自由访问github。 　　

　　给shuttlebee服务加代理（http_proxy和http_proxy）有两种方式： 　　

　　使用dockerfile.env http _ proxy http://IP 3360 port env https _ proxy 3358 IP 3360 port.使用kube配置文件with kube部署规格3360模板3360规格3360容器。ner :-env 3360-name : http _ proxy值3360 3358 IP : port-name 3360 https _ proxy值3360 3358 IP 3360端口验证：shuttlebee容器中的curl api.github.com/zen 　　

　　超过