# 協議無痛升級 使用度最高的通訊協議，一定是`HTTP`了。優點有多少，相信大家肯定有切身體會。我相信每家公司對`HTTP`的使用都有自己的規則，甚至偏好。這東西沒有誰對誰錯，符合業務需求、量體裁衣是王道。這里我們想通過親身體會，告訴大家利用好`OpenResty`的一些特性，會給我們帶來驚喜。 在產品初期，由于產品初期存在極大不確定性、不穩定性，所以要暴露給開發團隊、測試團隊完全透明的傳輸協議，所以我們1.0版本就是一個沒有任何處理的明文版本`HTTP+JSON`。但隨著產品功能的豐富，質量的逐步提高，具備一定的交付能力，這時候通訊協議必須要升級了。 為了更好的安全、效率控制，我們需要支持壓縮、防篡改、防重復、簡單加密等特性，為此我們設計了全新2.0通訊協議。如何讓這個協議升級無感知、改動少，并且簡單呢？ > 1.0明文協議配置 ~~~ location ~ ^/api/([-_a-zA-Z0-9/]+).json { content_by_lua_file /path/to/lua/api/$1.lua; } ~~~ > 1.0明文協議引用示例： ~~~ # curl http://ip:port/api/hearbeat.json?key=value -d '...' ~~~ > 2.0密文協議引用示例： ~~~ # curl http://ip:port/api/hearbeat.json?key=value&ver=2.0 -d '...' ~~~ 從引用示例中看到，我們的密文協議主要都是在請求`body`中做的處理。最生硬的辦法就是我們在每個業務入口、出口分別做協議的解析、編碼處理。如果你只有幾個API接口，那么直來直去的修改所有API接口源碼，最為直接，容易理解。但如果你需要修改幾十個API入口，那就要靜下來考慮一下，修改的代價是否完全可控。 最后我們使用了`OpenResty`階段的概念完成協議的轉換。 ~~~ location ~ ^/api/([-_a-zA-Z0-9/]+).json { access_by_lua_file /path/to/lua/api/protocal_decode.lua; content_by_lua_file /path/to/lua/api/$1.lua; body_filter_by_lua_file /path/to/lua/api/protocal_encode.lua; } ~~~ > 內部處理流程說明 - `Nginx`中這三個階段的執行順序：access --> content --> body_filter； - access_by_lua_file：獲取協議版本 --> 獲取body數據 --> 協議解碼 --> 設置body數據； - content_by_lua_file：正常業務邏輯處理，零修改； - body_filter_by_lua_file：判斷協議版本 --> 協議編碼。 剛好前些日子春哥公開了一篇`Github`中引入了`OpenResty`解決SSL證書的問題，他們的解決思路和我們差不多。都是利用access階段做一些非標準HTTP(S)上的自定義修改，但對于已有業務是不需要任何感知的。 我們這個通訊協議的無痛升級，實際上是有很多玩法可以實現，如果我們的業務從一開始有個相對穩定的框架，可能完全不需要操這個心。沒有引入框架，一來是現在沒有哪個框架比較成熟，而來是從基礎開始更容易摸到細節。對于目前`OpenResty`可參考資料少的情況下，我們更傾向于從最小工作集開始，減少不確定性、復雜度。 也許在后面，我們會推出我們的開發框架，用來統一規避現在碰到的問題，提供完整、可靠、高效的解決方法，我們正在努力ing，請大家拭目以待。