协议无痛升级

在产品开发初期，由于其存在极大的不确定性、不稳定性，所以要暴露给开发团队、测试团队完全透明的传输协议，所以我们 1.0 版本就是一个没有任何安全处理的明文版本： HTTP + JSON。但随着产品功能的丰富，质量的逐步提高，具备了一定的交付能力，这时候通讯协议就必须要升级了。

为了更好的安全、效率控制，我们需要支持压缩、防篡改、防重复、简单加密等特性，为此我们设计了全新 2.0 通讯协议。如何让这个协议升级无感知、改动少，并且简单呢？

从引用示例中看到，我们的密文协议主要都是在请求 中做的处理。最生硬的办法就是我们在每个业务入口、出口分别做协议的解析、编码处理。如果你只有几个 API 接口，那么直来直去的修改所有 API 接口源码，最为直接，容易理解。但如果你需要修改几十个 API 入口，那就要静下来考虑一下，修改的代价是否完全可控。

最后我们使用了 OpenResty 阶段的概念完成协议的转换。

刚好前些日子春哥公开了一篇 GitHub 通过引入 OpenResty 解决了 SSL 证书的问题，他们的解决思路和我们差不多。都是利用 access 阶段做一些非标准 HTTP(S)上的自定义修改，但对于已有业务是不需要任何感知的。

我们这个通讯协议的无痛升级，实际上是有很多玩法可以实现，如果我们的业务从一开始有个相对稳定的框架，可能完全不需要操这个心。没有引入框架的原因，一来是现在没有哪个框架比较成熟，二来是从基础开始更容易摸到细节。对于目前 OpenResty 可参考资料少的情况下，我们更倾向于从最小工作集开始，减少不确定性、降低复杂度。

也许在后面，我们会推出自有的开发框架，用来统一规避现在碰到的问题，提供完整、可靠、高效的解决方案，我们正在努力ing，请大家拭目以待。