基于OpenResty的單機10萬TPS網關在物流業務中的應用

作者：好奇芯 2019-01-25 07:41:29

開發開發工具

OpenResty® 是一個基于 Nginx 與 Lua 的高性能 Web 平臺，物流網關就是基于OpenResty構建的，今天就跟大家聊聊 OpenResty 在物流網關的故事。

引言

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 字符的解析過程。