一、背景
1. 业务上云带来性能收益
公司从去年全面推动业务上云，而以往 IDC 架构部署上，接入层采用典型的 4 层 LVS 多机房容灾架构，在业务高峰时期，扩容困难（受限于物理机资源和 LVS 内网网段的网络规划），且抵挡不住 HTTPS 卸载引发的高 CPU 占用。
而经过压力测试发现，使用腾讯云 7 层 CLB 负载均衡进行 HTTPS 卸载，性能得到极大提升。测试数据也表明，IDC 旧架构中，启用 HTTPS 会带来 90% 以上的性能损耗。
2. 架构调整引发多次故障
引入腾讯云 7 层 CLB 负载均衡产品，带了了巨大的性能提升，却也给业务带来了痛苦，主要核心问题是获取客户端的真实 IP 上。
当前现状是业务语言异构（PHP + Go），多数业务已经历服务化改造，但缺乏服务发现机制，服务与服务之间的调用依赖域名和 DNS 解析，大部分都是 HTTP 服务。
在架构调整后，由于未能 100% 覆盖测试，导致漏测的服务经常拿到错误的客户端 IP 地址，造成的后果是损失大量的用户。这些用户会因为短信验证码发送限制、IP 登录频次过高而无法登录、充值，给公司带来巨大损失。
3. 未来的路应该怎么走？
更进一步讲，当前业务如何抵挡外界的 DDoS 攻击、请求机器人、SQL 注入等等，最简单的是接入高防 IP、WAF 应用防火墙，而请求经过多轮转发，同样也有获取客户端真实 IP 的问题。
再者，业务也在逐步容器化，享受 Kubernetes 弹性扩容的便利，怎么平滑迁移也是非常值得深思的。
假设有一天某个同学，不小心配置有误——应用层拿到的，很有可能是高防 IP 或者 WAF 的 IP，业务绝对无法忍受。
显然，确定一个业务无感知的方案并成功落地迫在眉睫。
然而翻遍整个互联网，几乎没有文章能把这些看起来很简单的事情捋清楚、讲明白，更不用说最佳实践。
大多数人都是抄抄配置，潦潦草草上线，方案并没有普适性。
这篇文章也是我在这段时间的研究中总结出来的宝贵经验，希望对读者能有些许帮助。文章篇幅较长，难免有错误之处，还请各位看官斧正，感激不尽：）
