一加Ace2 Pro真機揭曉 鈦空灰配色質感拉滿
終于，在經過了幾波預熱之后，一加Ace2 Pro的外觀真機圖在網上出現了。還是博主數碼閑聊站曝光的，這次的外觀設計還是延續了一加11的方案，只是細節上有了調整，例如新加入了鈦空灰
大家好，我是冰河~~
“這特么到底是哪里出了問題，我感覺沒啥問題啊，為什么我統計出來的數據就是和運維統計出來的數據對不上呢？為啥運維統計出來的結果是正確的呢？我覺得自己的代碼沒毛病啊？”——此時的小菜已經糾結好久了，幾乎到精神崩潰的邊緣。
事情是這樣的，小菜是一名剛從學校畢業的大學生，幾乎沒啥工作經驗，憑借著在學校的傳奇經歷，順利進入了某頭部互聯網大廠實習，剛來沒幾天，就被分到了一個統計線上調用商品詳情接口次數的任務。說起來不就是統計一個接口的訪問次數嗎？這個需求小菜很懂，也很明白，沒一會兒就搞定了，可是發布到測試環境測試時，卻發生了各種詭異的問題。
時間過的真快，小菜不只不覺來公司實習快一周了，這幾天基本都是學習公司技術資料和項目業務，平時自己寫寫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，這樣不斷累計接口的訪問次數。表面上看起來邏輯是沒毛病的。
老王對小菜說：“這個類實現的有問題，這樣實現根本就不能統計出正確的結果”。
“不對呀，我排查和調試半天了，沒問題呀，結果跟我自己預想的一樣呀”，小菜確實不知道哪里有問題，也并沒有發現這個類的不妥之處。
正好此時到了下班的點，老王今天還要早點回去接孩子放學，于是就對小菜說：“這樣吧，你先回去想想，查查資料看看哪里有問題，我今天要早點回去接孩子放學，明天到公司了，我給你講講哪里有問題”。
“好的”，小菜回答到。
就這樣，看起來一個很簡單的問題，小菜前前后后花了一天的時間，也沒搞定，心里確實有點郁悶：“明明是很簡單的功能啊，這特么到底是哪里不對呢？”。
他又回到了座位上。。。
本章，主要以場景故事線的方式講述了小菜來公司幾天后，接到第一個統計訪問商品詳情接口的項目任務，本以為很簡單的功能，三下五除二做完，提交測試環境后，被測試打回，反復排查和調試代碼，也沒發現問題的過程。此時的小菜心里有點郁悶，明明很簡單的功能，這特么到底是哪里不對？
好在明天到公司了，老王會給小菜講清楚到底是哪里的問題（再次感嘆：老王是真特么的好啊！）
最后，可以在評論區寫下你學完本章節的收獲，祝大家都能學有所成，我們一起搞定高并發設計模式。
本文鏈接：http://www.tebozhan.com/showinfo-26-11245-0.html不可變模式篇：非常抓狂，這特么到底是哪里不對？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 理解Kafka offset
下一篇： Go 語言史詩級更新-循環Bug修復
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號