轉眼間，距離Jerry最近一篇文章推送已經過去了一個多月的時間了。

公眾號更新的頻率降低，不是因為Jerry偷懶，而是由于從春節過后，我所在的SAP成都研究院數字創新空間整個團隊，一直在忙一個5月份需要交付的項目上。

Jerry每天的工作量像下面這張圖這樣：

這個項目里Jerry負責的是后臺開發工作，我用nodejs開發了若干微服務，每個微服務實現一個特定的業務邏輯。這些微服務由Jerry另外開發的一個編排器(Orchestra)統一調度。整套后臺實現部署在亞馬遜云平臺(Amazon?Web?Service，以下簡稱AWS)上。

離交付日期越來越近了，我們的功能也趕得差不多了。本地測試運行得很好的場景，部署到AWS上運行后出現了一些bug。比如昨天就遇到一個棘手的bug，因此有了今天這篇文章。

2014年五一節的前一天，當時Jerry還在SAP?CRM開發團隊工作，負責處理SAP?CRM中間件的一個bug。這個bug和代碼執行時序有關，每執行一次只有40%的幾率能重現，花了我整整一天(8個小時)的時間調試。因為重現bug的場景太復雜，需要調試的ABAP代碼量太大，所以讓我印象深刻。那個bug處理完之后，我也對自己花了8小時才搞定該bug的效率很不滿意，因此寫了一篇博客總結這次排錯的經驗教訓：

My Tips about how to handle complex and tricky issues

https://blogs.sap.com/2014/05/01/my-tips-about-how-to-handle-complex-and-tricky-issues/

回到昨天我遇到的在AWS上出現的bug，根據問題的表象，一開始我和負責前端開發的同事，連這個問題出在前端還是后端都沒辦法判斷。當微服務部署在本地并進行測試時一切正常，只有部署在AWS上進行集成測試時才會暴露，而運行在AWS上的nodejs應用，我昨天還不知道如何調試，因此只好采用我大二剛學C語言編程時用過的最笨的排查辦法：打日志。

2001年，在結束了一年的計算機專業基礎課學習后，Jerry開始了Unix環境下C語言編程的學習。當時我對gdb這種以命令提示行方式進行的調試風格很不適應，大多數時候的排錯采用的還是在代碼里添加printf語句打印變量內容的方式來進行，被寢室的同學鄙視了好久。

于是昨天我繼續采用了這種自己18年前就曾經用過的排錯方式：

1. 在可能引起bug的相關代碼處逐一加上日志輸出語句

2. 執行會出現bug的用戶操作

3. 閱讀AWS上生成的日志語句

上述三個步驟是一個不斷迭代的過程。最開始我加了若干日志輸出語句，執行操作后閱讀生成的日志，發現沒有任何異常。于是不斷地增加新的日志打印代碼，最后導致了執行一次操作，會生成1200行的日志輸出。

我和負責前端開發的同事兩人坐在顯示器前，一行行檢查這海量的日志輸出。由于問題是用戶第二次操作后才會暴露，每次操作會生成不同的會話，我們被迫不斷的上下滑動屏幕來比較這兩次會話的uuid和相關的WebSocket?uuid等變量。Jerry很快發現，眼睛一眨不眨地盯著顯示器逐條檢查日志，時間一長眼睛就痛得受不了。無奈之下，只得把這些日志用打印機打印出來，用不同顏色的筆標注出兩個會話對應的各種變量，在紙上來回比對。于是就有了下面這些紙張：

雖然最后用這種辦法，成功排除了后臺出錯的可能性，使我們得以把精力花在前臺代碼的審查上，但是像我一個同事評價的，“這種方式太不環保了”，并且我自己也覺得，效率太低了。

后來好幾位熱心的同事告訴Jerry，就算運行在SAP?Cloud?Platform或者AWS這些云平臺上的nodejs應用，也是可以單步調試的，Jerry?Google了一下，發現遠程調試確實很簡單，就兩條命令而已。

Jerry用我們創新空間團隊另外一位同事Haytham開發并部署在AWS上的一個nodejs應用為例來嘗試如何在我的本地電腦上對其進行調試。

Haytham雖然是一個大四本科生，但是已經在SAP成都研究院Jerry所在團隊實習將近十個月的時間了，最近三個月一直在SAP德國總部參與一個項目的開發。

等Haytham回到成都后，會將自己這十個月的工作感悟，從一個SAP新人的視角給大家分享出來，敬請期待。

Haytham之前寫過的文章：

SAP成都研究院許聚龍：Hello,?Coresystems！

Haytham寫的這個nodejs應用實際上是Github?Webhook的一部分。我們在本地進行微服務nodejs開發，本地git客戶端推送代碼到遠端github倉庫。然后需要在AWS上手動git?pull把最新的代碼拉下來，再用一個開源工具pm2進行微服務部署。Haytham寫的這個nodejs應用，能實現本地git推送完畢后一切后續流程的完全自動化，節省了我們大量的部署時間。

下面就來對Haytham這個運行在AWS上的nodejs應用進行遠程調試。

1.?用node?--inspect-brk在AWS上以調試模式啟動應用。

之后控制臺上的輸出表明有一個nodejs進程以WebSocket協議在127.0.0.1:9229這個地址上監聽調試客戶端的連接。

2.?我在我的本地電腦上，用如下命令行將我本地電腦的端口9221映射到AWS調試進程監聽的9229端口上：

ssh?-i?C:\Users\i042416.ssh\KOI.pem?-L?9221:localhost:9229?ubuntu@ec2-us-east-2.compute.amazonaws.com

現在，本地電腦上Chrome瀏覽器地址欄chrome://inspect里指定監聽地址為localhost:9221,

通過第二步建立的SSH tunnel，

我就可以用本地電腦連接到AWS上的nodejs應用并進行調試了。

現在終于可以在Chrome開發者工具里進行愉快的調試了：

因為我平時本地做nodejs開發和調試時，更喜歡用Visual?Studio?Code，所以下一步我準備試試用Visual?Studio?Code進行遠程調試。

說到Visual?Studio?Code，Jerry突然想起今天在網上看到的一個關于這個IDE的有意思的擴展，名為"超越鼓勵師"。

Jerry試著在自己的Visual?Studio?Code擴展安裝欄里搜索了一下，這個擴展還真的可以下載。不過擴展里出現的"楊超越"，Jerry又孤陋寡聞了，咨詢了老婆后才知道她是誰。

至于實際效果如何，Jerry不做評價，歡迎Visual?Studio?Code愛好者自行下載體驗。

最后，祝各位程序猿/程序媛們每天即使沒有程序員鼓勵師的陪伴，仍然可以愉快地編程。感謝閱讀。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的如何提高后台服务应用问题的排查效率？日志 VS 远程调试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。