方永、南天紫雲

最近用 rust 的 Rocket web框架做了一套api接口，记录一下遇到的问题。

一個年底活動的項目，前後端分離，後端以json api的形式與前端交互。

後端也就幾張表，幾個前端接口，但是接入了 5 類接口，且有3類在內網，2類使用java生態的協議，dubbo和hessian，項目時間很緊張， 沒時間去分析實現這倆協議，用java做了轉接。

數據庫是oracle db，rust的oracle驅動crate倒是有幾個，最後用了mimir，這個基於odpi的庫除了調試信息不多，沒guide文檔外， 其它還算好，也封裝了odpi的連接池，但文檔裏沒說明這個不是線程安全的，將pool作爲rocket的guard，編譯沒有問題，運行時經常 get_connection失敗，用wrk加點壓力，然後隨機coredump，好吧，換用單鏈接吧。由於只是驅動，所以操作都是拼sql語句，做了 個trait，復用從一個查詢裏取結果並查詢每列的結果等等這些瑣碎的操作吧。

然後上準生產，操作系統是redhat6，本機編譯的二進制glibc太老，跑不起來，編譯新版本的glibc並加載，運行時coredump，在這臺服務器編譯， 報一堆錯誤，看到由一個名爲ring的crate引起，這個庫被cookie依賴，cookie被rocket依賴，在Cargo.toml裏patch cookie，ring的 依賴並沒有去除，分支rocket並patch rocket，生效。吐槽一下ring，一是鎖定rustc版本，一是鎖定gcc版本，大家寫代碼是要上生產的，不是 玩兒的，ring的作者你太任性了！去除了ring的依賴，順利編譯完成。

但是，運行時又會有moved的報錯，一看原來準生產redis是集羣，crate redis並不支持集羣方式，找到redis-cluster，用之，建立連接時有錯， 分析並patch，第二天前端反應接口超慢，一開始以爲oracle調整了，各種排查，到下午打日志，看到redis的get請求居然有幾十秒，WTF，換用 td_rredis，世界清靜了。

然後上生產，老是auth required，redis的password是配置了的，於是忍受着堡壘機後面的生產服務器的龜速，打日志，好吧，三主三從，只給三主 配了密碼，其它的還得加。終於上線了，happy。

領導看了，提出意見，改，再上線。

上線時，居然實例一直超時，有很多請求，但也不至於啊。。。 使用openresty將前端的index代理了，ok了。 再看統計數據一天十來萬的注冊量，還行，qps應該不低，那就得找找index的原因了。

而這一切，都發生在幾天的時間裏。尤其是ring的問題，程序都寫好了，跑不起來，都可以讓人懷疑人生了。

總結一下，時間是一個致命點，太短的時間，太多的問題，這個劑量的壓力足以搞死一頭牛。 rust的crate是另一個坑，去crates.io想給ring和redis-cluster差評，無奈並沒有這個功能。那麼應該會有人前赴後繼地掉坑吧。

2017年博客只寫了一篇水文，這篇本來也不想寫的，怕2018一篇都沒有，聊充個數吧。