性能优化/稳定性之多机房部署

背景

全球化的业务发展到一定阶段后，就会有多机房部署的需求，可以让用户就近访问，提升性能。并且也能为单一机房，减轻负载压力。关键时候，也能作为容灾的手段（比如A机房出了问题，还能有B机房兜底，让A机房区域的用户还能正常访问）

如何实现？

步骤：

1. 前端部分：

   1. 代码内加入环境变量，区分不同机房下请求的对应资源

      1. 比如：

         1. sg机房，请求的是 xxxcdn-sg.com 的域名
         2. va机房，请求的是 xxxcdn-va.com 的域名

      2. 去动态生成webpack的publicPath（映射到对应机房的CDN）

         

      3. 公司内部平台打包时，分机房打包。注入对应机房的环境变量，可以打出对应机房的包。并上传静态资源到对应机房的CDN

      4. 不同机房的实例内，部署代码时，需要注入对应的机房环境变量（不过大概率对应机房会有已经准备好的环境变量）

         1. 在实例里面起服务时（比如 npm run start），带上环境变量，这时代码侧就知道去取哪个机房的CDN了

1. 部署：（以部署VA机房为例）

   1. 申请VA机房资源，设置好环境变量，并部署

1. 分流

   1. 注意：测试阶段，只能以白名单的方式分流到VA，否则影响线上VA的用户

   2. 让公司内部的CDN oncall 以白名单的形式，分流到VA机房

      1. 白名单的策略有几种，可以让CDN oncall提供

1. 最终上线

   1. 确保新机房的各个下游能正常访问，并且所有功能都正常时，可以让CDN开启 根据用户ip自动分流到对应机房

需要注意的坑

1. 在对应打包平台和部署实例的平台内，要确保注入了有效的环境变量，并且和前端是能串起来的

2. 确保静态资源 准确的上传到了对应机房的CDN

3. 确认所有下游（SSR项目）

   1. 找对应的下游负责人一一确认：是否有VA机房部署

   2. 如果下游（走服务发现的rpc调用）没有VA部署，则需要跨机房调用（HTTP请求不受机房限制，但访问就近机房会更快。 rpc接口则需要配置跨机房调用，否则调不通，除非有对应机房的rpc部署）

多机房部署带来的挑(ma)战(fan)

其实多机房部署会增加后续的维护成本，比如：

1. 配置的监控告警，需要多增加一份

2. 服务的实例管理，也增多了一份

3. 服务稳定性看板（内存、cpu、访问流量，时延、状态码的错误率，上下游错误率），也多了一份需要关注和管理

4. nginx层的配置，也会多一份

5. 一些下游在对应机房没有部署话，需要跨机房调用，速度会变慢...

---

码字不易，点赞鼓励