• 本章難度：★★☆☆☆
• 本章重點：以場景故事的形式講述小菜到公司幾天后，接到第一個統計調用商品詳情接口次數的任務，在梳理了業務流程后，快速實現了功能，但測試結果與預期差距很大，排查和調試了一天也沒定位到問題的過程。

大家好，我是冰河~~

“這特么到底是哪里出了問題，我感覺沒啥問題啊，為什么我統計出來的數據就是和運維統計出來的數據對不上呢？為啥運維統計出來的結果是正確的呢？我覺得自己的代碼沒毛病啊？”——此時的小菜已經糾結好久了，幾乎到精神崩潰的邊緣。

一、需求背景

事情是這樣的，小菜是一名剛從學校畢業的大學生，幾乎沒啥工作經驗，憑借著在學校的傳奇經歷，順利進入了某頭部互聯網大廠實習，剛來沒幾天，就被分到了一個統計線上調用商品詳情接口次數的任務。說起來不就是統計一個接口的訪問次數嗎？這個需求小菜很懂，也很明白，沒一會兒就搞定了，可是發布到測試環境測試時，卻發生了各種詭異的問題。

二、接手任務

時間過的真快，小菜不只不覺來公司實習快一周了，這幾天基本都是學習公司技術資料和項目業務，平時自己寫寫demo，還沒有真正寫項目功能。

這不，這天小菜剛到公司，把自己厚重的電腦包往辦公位一放，就看到產品經理屁顛屁顛的走過來了，不過不是找小菜的，而是徑直走到了小菜的直屬領導——老王的身邊。

“王工，咱的社區電商項目不是剛上線嗎？現在運營有個需求，要統計下訪問調用商品詳情接口的次數。”

“好，什么時候需要。”

“下周發布上線就行。”

“好的。”

老王把調用商品詳情的接口梳理了下，這個需求確實比較簡單。老王考慮到小菜來公司好幾天了，學習了幾天公司的技術資料和項目業務。心里就想著把這個簡單的需求，交給小菜做。

“小菜，你過來下，給你個簡單的任務”，老王說道。

于是小菜起身來到老王的身邊，老王開始巴拉巴拉的為小菜講解任務需求和對應的接口情況。

雖說小菜沒啥工作經驗吧，但是這個需求聽起來確實比較簡單，小菜聽完老王的講解后，說道：“沒問題，我盡快完成”。

于是小菜回到工位，開始認真分析代碼，并在本子上畫實現的流程。

三、梳理任務

雖說小菜沒啥工作經驗吧，但是他確實是懂得在搞清楚任務需求和實現流程之前，不會輕易干代碼的。這也是他剛來公司的時候，老王跟他說的，說起老王，特么確實是個大好人，新人剛來公司的第一天，就會將自己的一些踩坑經驗巴拉巴拉的分享給這些新人（我剛參加工作那會兒怎么就遇不見像老王這樣的大好人呢？）。

經過認真的思考和仔細的梳理商品詳情接口后，小菜畫出了下面的這幅圖。

圖片

客戶端在訪問系統接口時，首先會經過網關，由網關將訪問系統的流量路由到后端微服務。在網關的設計和實現上，總體上會分為網關核心組件和網關控制臺，網關的一些規則，比如接口統計、UV統計、PV統計，鑒權規則，其他規則等等，都是在網關控制臺進行配置，并且在網關控制臺的配置會及時生效。

網關采用責任鏈設計模式實現了一系列的攔截器鏈，比如風控攔截器、接口攔截器、鑒權攔截器、其他攔截器等，每個攔截器專注實現某種特定邏輯的校驗規則，例如風控攔截器會調用風控系統檢測請求是否存在風險，接口攔截器主要是統計接口層面的一些請求信息，鑒權攔截器主要是檢測與鑒權相關的邏輯等等。到達網關的請求只有通過所有攔截器的校驗后，才會被路由到后端服務。

梳理完請求的流程和網關的攔截器邏輯后，小菜拿著本子走到了老王的面前。

“老大，業務流程我梳理清楚了，你看看對嗎？”

“好，我看看”。

大神就是大神，只見老王接過小菜的本子后，只是看了一眼，說道：“可以這樣實現，沒問題，實現的過程中遇到自己解決不了的問題，可以再問我。”

“好的”。

小菜回到了工位上。

四、實現任務

要不說這個任務很簡單呢？小菜梳理清楚業務流程，向老王確認可以這樣實現后，回到工位，啪啦啪啦就翹起了鍵盤，沒一會就完成了代碼開發。

“這個功能確實是簡單啊，我也只是花了沒多少時間就完成了，看來公司的項目其實也挺簡單的，哈哈哈”——小菜心里暗暗自喜。于是乎，小菜并沒有在自己本地對寫完的代碼進行單元測試，他覺得這個功能太簡單了，沒必要測試。所以，小菜將代碼合并到了測試分支，由 CI/CD 平臺自動構建并發布到了測試環境。

此時的小菜向測試提交了一份文檔，詳細的描述了自己這次實現的業務功能，交付測試。不一會兒，測試便將測試結果反饋給了小菜。

小菜拿到結果一看，瞬間懵逼了：“臥槽，不是吧，期望值10000，實際值7596？差距這么大嗎？不可能吧？這功能很簡單啊！就是計數啊！是不是測試搞錯了？（應該大部分程序員首先會覺得是別人的問題吧，哈哈哈哈）”。

于是乎，小菜重新打開開發環境，一遍遍排查自己寫的代碼，也在自己本地一遍遍調試著自己的代碼。

過了很久，小菜得出一個結論：沒毛病啊，結果是對的啊！于是小菜去問測試：”你是怎么測試的呢？“。

“我就是按照正常流程測試的啊，你寫的代碼肯定有問題”。

“沒問題啊，我自己調試半天了，結果是對的”。

于是，測試給小菜發了一份運維從測試服務器上統計的結果數據，敲好與測試的結果一致。

小菜看到數據后，說了句：“好吧，我再看看吧”。

小菜回到工位，又開始了排查代碼和調試代碼，

就這樣，小菜從上午一直排查、調試到快下班了，得出的結論是：沒毛病啊，哪里除了問題呢？

此時的小菜已經失去了剛做完這個功能時的自豪感，心情也越來越煩躁。“到底哪里有問題啊？我看代碼沒毛病啊！怎么就不對呢？”

五、求助老王

實在是沒招了，小菜起身走到老王身邊：“老大，上午寫的那個功能，發布到測試環境，測試說我統計的結果數據不對，運維那邊從服務器上統計的結果是正確的，我排查了很久都沒發現問題。”

“是嗎？我看看你寫的代碼。”

于是老王將測試分支的代碼拉取到本地，找到小菜的提交記錄，僅僅看了一眼代碼，就發現了問題所在。

原來在小菜寫的代碼里定義了一個接口訪問計數器。

源碼詳見：concurrent-design-patterns-immutable工程下的io.binghe.concurrent.design.wrong.WrongCounter。

public class WrongCounter {

    private int visitCount;

    public void accessVisit(){
        visitCount++;
    }

    public int getVisitCount() {
        return visitCount;
    }
}

這個類中定義了一個int類型的成員變量visitCount，用來統計接口的訪問次數，每次訪問接口時，在網關的接口攔截器里都會調用一次accessVisit()方法，將visitCount的值加1，這樣不斷累計接口的訪問次數。表面上看起來邏輯是沒毛病的。

老王對小菜說：“這個類實現的有問題，這樣實現根本就不能統計出正確的結果”。

“不對呀，我排查和調試半天了，沒問題呀，結果跟我自己預想的一樣呀”，小菜確實不知道哪里有問題，也并沒有發現這個類的不妥之處。

正好此時到了下班的點，老王今天還要早點回去接孩子放學，于是就對小菜說：“這樣吧，你先回去想想，查查資料看看哪里有問題，我今天要早點回去接孩子放學，明天到公司了，我給你講講哪里有問題”。

“好的”，小菜回答到。

就這樣，看起來一個很簡單的問題，小菜前前后后花了一天的時間，也沒搞定，心里確實有點郁悶：“明明是很簡單的功能啊，這特么到底是哪里不對呢？”。

他又回到了座位上。。。

六、本章總結

本章，主要以場景故事線的方式講述了小菜來公司幾天后，接到第一個統計訪問商品詳情接口的項目任務，本以為很簡單的功能，三下五除二做完，提交測試環境后，被測試打回，反復排查和調試代碼，也沒發現問題的過程。此時的小菜心里有點郁悶，明明很簡單的功能，這特么到底是哪里不對？

好在明天到公司了，老王會給小菜講清楚到底是哪里的問題（再次感嘆：老王是真特么的好啊！）

最后，可以在評論區寫下你學完本章節的收獲，祝大家都能學有所成，我們一起搞定高并發設計模式。