电商网站HTTPS实践之路——灰度上线篇

Posted 2023-03-01 皖南笑笑生

对于电商而言，不能因为技术的升级就轻易影响了线上业务，毕竟最宝贵的是用户流量。当我们一鼓作气完成了系统的HTTPS改造和优化后，上线过程则是小心翼翼逐步完成的，毕竟这么大的调整动作牵一发而动全身。从HTTP过渡到全站HTTPS，没有发生一次严重事故，究其原因是我们始终遵守三个原则，即降级原则、灰度原则和开闭原则。

• 1. 灰度发布
• 2. 开关控制
• 3. 性能监控

1. 灰度发布

即通过灰度发布的方式，实现HTTP到全站HTTPS的平滑过渡。可以针对不同粒度和维度，按需求进行灰度，比如根据域名、城市运营商、App版本、会员级别等等。通过灰度，同步对比数据分析，逐步放开HTTPS的使用。
对于浏览器的业务，我们在接入层配置HTTP->HTTPS的301跳转，同时开启HSTS。为什么使用301跳转而不使用302？主要是出于搜索引擎SEO的考量。
301 Moved Permanently表示永久性跳转，表示本页面网址永久性转移到另一个地址上。搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。
302 Moved Temporarily表示暂时性转移，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。当一个网页经历过短期的URL的变化时适合使用302使用。
因为我们最终是要实现全站HTTPS，因此自然更适合采用永久性的301跳转。
对于移动端App的业务，可以配置客户端开关，每次加载App前先获取开关值。通过版本号+域名清单的方式，控制请求的HTTPS/HTTP切换。比如：

"api":"mts.switch.config",
"code":"0",
"data":
    "switchname1":"1", //为1时，对list中的版本除去黑名单外开启HTTPS；为0时，保持客户端默认配置
    "4.1":"domain.com",   //版本号及其对应的黑名单，黑名单是指这些域名的请求加载走客户端默认配置，不强制转换成HTTPS
    "4.2":"domain.com"
    ,
"msg":"",
"v":"1.0"

2. 开关控制

当灰度发生问题时，要能及时切回HTTP，即是降级原则。HTTPS上线后，肯定会遇到一些意想不到的问题，比如部分地区Dns劫持，又比如302跳转HTTPS与其他规则相冲突。降级生效的越快，用户受到的影响越小。根据墨菲定律，系统一定是会出问题的，我们要提前计划好止损措施。
因此，我们做了各种开关限制。

1. 客户端开关我们上文说过。
2. 内容管理平台开关，电商平台都应该有自己的内容管理平台，提供给运营日常维护静态促销页面。其开关定义可参考：

close.https: HTTPS降级到HTTP总开关
https.whitelist: 支持HTTPS的域名白名单
https.On: 修改为相对协议的总开关
https.channel.On: 修改为相对协议的的频道开关

close.https优先级最高
默认close.https=false，逻辑关闭状态；
close.https=true，在出口所有链接统一替换为http://再输出

https.On
默认https.On=true，对匹配https.whitelist的域名，所有链接在出口时替换为相对协议再输出；
https.On=false，逻辑关闭状态

https.channel.On
默认https.channel.On，对匹配https.whitelist的域名，频道内链接在出口时替换为相对协议再输出；
https.channel.On，逻辑关闭状态

3.接入层开关：关闭接入层的301跳转配置。

3. 性能监控

所有的架构设计应该遵循开闭原则。即对扩展开放，对修改关闭，这是可复用设计的基石。全站HTTPS网络架构设计需要大数据分析来说明其稳定性及合理性。从CDN到HTTPS接入层再到应用服务器，每一层的损耗和响应性能是多少，要有明确的数据指标考核。这样未来所有的系统都可以遵循这套架构的基础上扩展，而不需要修改架构。
举个例子，比如我们遇到过这样的系统，不是通过443端口而是2448端口与厂家进行加密通信，这时我们只需要开通接入层的2448端口，并做一些安全策略，而不需要去设计另一种架构来实现。
做好性能监控，完善的数据分析，是检验三大原则的唯一标准。对全站HTTPS实施的监控应该至少覆盖：
1. 服务器性能监控：这个不用多说，结合zabbix和系统实时日志。

2. 主动拨测监控：通过各地的IDC机房和用户Lastmiles，发起模拟用户的请求，并记录下数据供分析（可参考开源框架http://www.webpagetest.org/）。

3. App性能监控日志：通过Sdk的方式，采集客户端App的接口日志，上传供分析。
4. 浏览器性能监控日志：通过页面埋点脚本的方式，采集用户真实的浏览器行为数据和性能数据，上传供分析。

举个例子，在切换HTTPS之前，通过主动拨测，我们监测到某些地区存在严重的Dns劫持情况。在联系运营商解决的同时，我们的跳转规则就绕开了这些区域，既保证HTTPS上线又避免对该地区用户造成影响。

到这里，全站HTTPS实施完整的过程已经全部写完。也是我近一年工作的一个回顾和总结。然而这并不是终点，恰恰是一个新的起点。互联网时代，充满了机遇。大浪淘沙，有更多学习与创造的机会。