趁热记录下，给未来的自己

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

网络上，关于解决github访问慢的方案一大把：

• 修改host
• nginx反向代理
• 等等

这些方法，要么不好使，要么或多或少的不满足我们的业务场景。

但是，方法肯定是比困难要多的。我们的解决方案，也经历了几次迭代，最终演化出目前一个比较稳定的版本。

版本1：

将github三方登录这部分功能单独剥离出来形成一个应用（我们称之为：shuttlebee），然后将shuttlebee 部署在有条件访问github的网络环境中，通过shuttlebee实现github数据的中转。

于是，第一个版本的shuttlebee，是放在实验室的网络环境里，如下图：

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

版本2：

为了解决实验室网络环境不稳定的缺点，于是，将shuttlebee迁移到境外的公用云上，比如阿里云香港的ECS上。

这个版本也有一个小问题，就是境外的独立IP，有可能会被国内墙掉。。。虽然是小概率的随机事件，但是出现了，就会是一次生产的故障。

版本3：

直到上次开s集群验收的会议，无意中知晓，s集群可以通过代理的方式走实验室网络出口。那么，我们在国内公有云上的服务是不是也可以走实验室的代理呢？经过和IT协商，获得了实验室的代理IP和端口。我们只需要将对应的shuttlebee服务加上实验室的代理，就可以在国内公有云的网络环境里，自由的访问github了。

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

1. 通过dockerfile

...
ENV HTTP_PROXY http://IP:PORT
ENV HTTPS_PROXY http://IP:PORT
...

2. 通过kube配置文件

kind: Deployment
spec:
  template:
    spec:
      container:
      - env:
        - name: HTTP_PROXY
          value: http://IP:PORT
        - name: HTTPS_PROXY
          value: http://IP:PORT

验证：在shuttlebee容器内 curl api.github.com/zen

以上