基于OpenResty的單機10萬TPS網關在物流業務中的應用
引言
OpenResty® 是一個基于 Nginx 與 Lua 的高性能 Web 平臺，其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數的依賴項。用于方便地搭建能夠處理超高并發、擴展性極高的動態 Web 應用、Web 服務和動態網關。
物流網關就是基于OpenResty構建的，今天就跟大家聊聊 OpenResty 在物流網關的故事。
為什么選擇OpenResty
物流網關在建設之初就重點關注性能、穩定性、擴展性以及可持續性。
在技術選型階段重點關注三個方面：
- 在網絡 I/O 模型方面，出于性能的考慮，需要非阻塞的 I/O 模型;
- 由于物流網關對外提供的是 Http/s 協議，所以需要成熟的支持 Http/s 協議的技術;
- 這個世界變化很快，只有擁抱好的生態才能促進持續發展。
綜合這三方面的需求，發現 OpenResty 是一個很好地選擇。
首先，OpenResty 利用協程實現了同步非阻塞的 cosocket，利用 cosocket 既可以享受同步編程的簡單，又可以享受非阻塞IO的性能優勢。
其次，Nginx 處理 Http/s 請求，目前在業界無人能出其右，性能和穩定性有目共睹。
同時，期望利用插件機制擴展功能。這方面 Kong 這個網關項目(這個項目基于 OpenResty)給出了優秀的參考方案。
插件化擴展方法
物流網關的功能紛繁復雜，核心的組件有安防、認證、限流、協議轉換、日志，網關的這些核心功能***都是插件化的，這些插件能夠根據不同的商家動態加載和卸載，這樣才能滿足不同商家的需求。
物流網關的插件機制依賴于 Nginx 處理請求的生命周期模型，安防、認證、限流這三個插件在 Rewrite / Access 階段動態加載執行，協議轉換、負載均衡在 Content 階段動態加載執行，而日志在 Log 階段異步處理。
每一個請求都需要根據業務配置動態加載，這些配置存儲在 MySQL 數據庫中，在高并發場景下，如果每次請求都要訪問 MySQL 數據庫，那 MySQL 數據庫一定會成為瓶頸直至宕機，因此引入多級緩存。
緩存的設計
物流網關采用了多級緩存，首先是利用 ngx.shared.DICT 實現的本地緩存，集中式緩存使用的是 Redis，物流網關并不直接訪問數據庫，而是通過調用 RPC 服務來訪問數據庫。
Redis 中的緩存是長期有效的，Redis 和 MySQL 之間的數據同步依賴雙寫機制，本地緩存和 Redis 的同步同時采用了兩種方法，一種是利用Redis實現了一個簡單MQ，網關集群節點訂閱元數據變更的消息，當有變更時，清空相關的本地緩存;為了容錯，本地緩存設置了失效期，這樣能夠保證數據總是有機會同步到本地緩存。
負載均衡器的設計
物流網關自研了支持 RPC 協議的 Lua 客戶端，功能與 Java 版的客戶端類似，值得一提的是負載均衡器的設計更加智能，在壓測階段發現，同樣規格的 Docker，性能差異非常大，這個差異很可能和宿主機的網絡、CPU 負載、內存使用率有關，這個影響因素是動態變化的，因此靜態的負載均衡配置(例如輪訓、隨機、權重等負載均衡策略)難以滿足需求，理想的負載均衡器應該能夠根據 RPC 服務負載來動態調整流量分發。
物流網關的調度算法選用的是最小連接數調度算法，類似于大家去超市排隊結賬，總是選取長度最少的隊伍。連接數的計算是這樣的：發送請求的時候連接數+1，響應返回或者異常的時候連接數-1。
json 跨語言的坑
Json 作為一種成熟的序列化方案，已經存在很久了，但是在跨語言方面 Json 并不成熟，A == json.decode(A).encode 在跨語言的時候并不是總能成立。例如對于二進制的序列化，在 Java 里都是將它轉換成 base64 的字符串，例如 0X3F 會被序列化成”/”，OpenResty 自帶的 cjson 會把“/”反序列化成字符串“/”，至此都沒有問題，但是 cjson 序列化字符串“/”時，得到的卻是“\/”，因為按照 json 規范“/”是需要被轉義的。最終結果就是網關的輸入是“/”輸出卻是“\/”。
所以物流網關自研了無損的 json 序列化組件，完全在字符串基本上操作 json，這樣就避免了類型轉換帶來的問題。下圖是一個 json 字符的解析過程。
性能優化
OpenResty 提供了優秀的性能分析工具，可以在運行時對系統采樣，并生成火焰圖，通過火焰圖可以快速定位性能瓶頸出現在哪行代碼。物流網關在單機全鏈路壓測中 TPS 能夠到達10萬，將硬件性能發揮到了***。
總結
目前，物流網關作為京東物流開放技術平臺的核心服務，支撐了所有 Http/s 協議的開放業務，已經平穩度過2018年的618全球年中購物節以及11.11全球好物節。借助 Lua 優秀的表達能力，以及插件化機制，物流網關近一年實現了功能的快速演進，真正做到了快速響應業務發展。
【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】
