首先解決問題：
問題：微服務之間的api呼叫出現為服務方提供引數傳值的時候出現了傳值丟失的問題，
排查：在服務方的api介面寫的時候引數值沒有新增引數型別註解導致傳值丟失。
如：服務b裡面的api介面，
沒有新增@requestparam(name = "benefitid")
@apioperation("列表")
benefitproprietorvo getbenefitpropinfo(long benefitid);
則在服務a裡面呼叫的話是以http請求的url方式去請求呼叫的，這樣的形式在呼叫方那邊就呼叫的是http.../v1/getbenefitpropinfo
沒有識別到有引數則這邊便會預設這個方法是沒有引數的，所以即使你把值傳過去，也是無效的。服務方在http請求裡面無法查詢到相關的引數；
加了 @requestparam(name = "benefitid")
則是為方法提供了一定的引數識別，即告訴那邊說你需要的引數是什麼，呼叫方才會把引數加入請求的url上面
所以本次問題的解決方案是把@requestparam(name = "benefitid") 加上就能正常接收引數了。
順便長點見識：
問題總是試著試著就弄好了，但是其中緣由卻沒能理解透徹，也不知為什麼這樣就能處理就可以那樣也不可以。
總之所有的問題都是你的姿勢不對造成的，你的姿勢決定你的bug數目，我是在看另外乙個問題的時候想起了這個問題的原因，其實這個服務方那邊無法接收引數也是有一定出入的。
其中主要涉及了乙個@requestparam加與不加的區別，明白了這個區別以及其中呼叫原理便能明白其中的問題。
一般編寫controller層的時候都是預設帶上 @requestparam 編寫api也是，但是其實不加@requestparam 也能接收到引數
加與不加的區別主要如下
這裡有兩種寫法
第一種必須帶有引數,你直接輸入localhost:8080/list 會報錯 不會執行方法 只能輸入localhost:8080/list?parentid=? 才能執行相應的方法
設定 @requestparam 裡面的required為false(預設為true 代表必須帶引數) 這樣就跟第二種是一樣的了@requestparam(required=false)
可以設定裡面的defaultvalue的屬性
如下: @requestparam(defaultvalue="0")
這樣在位址裡面也可以不帶引數，如果帶了引數會接收，不帶引數會預設為0
第二種 不加 @requestparam，可帶引數也可不帶引數 你輸入 localhost:8080/list 以及 localhost:8080/list?parentid=? 方法都能執行
但是這種寫法是有一定的風險的，大佬給我講解的其中原理是，這裡面的引數定義在編譯的時候是容易被擦除掉的，在請求的時候他需要值就會去header裡面找或者到body裡面找，但是找到的不一定會是對應的引數，也有可能是一些亂七八糟的東西，如果前端傳過來的引數是帶了？parentid=?的這邊就會預設獲取？號後面的第乙個就會出現資料不對應等問題，乙個的話還可以，但是如果是多個引數的話就容易報錯，
所以還是加上@requestparam避免會出現很多奇奇怪怪的問題。
微服務API閘道器
微服務api閘道器 api閘道器是乙個伺服器，是系統的唯一入口。從物件導向設計的角度看，它與外觀模式類似。api閘道器封裝了系統內部架構，為每個客戶端提供乙個定製的api。它可能還具有其它職責，如身份驗證 監控 負載均衡 快取 請求分片與管理 靜態響應處理。api閘道器方式的核心要點是，所有的客戶端...
微服務學習筆記 追蹤微服務呼叫
微服務系統追蹤微服務呼叫，跟蹤記錄一次使用者請求經過哪些呼叫，經過哪些服務處理，並且記錄每一次呼叫所設計的服務的詳細資訊。如果發生呼叫失敗，可以根據日誌快速定位出現問題的環節。一 作用 1.優化系統瓶頸 通過記錄呼叫經過的每一條鏈路上的耗時，快速定位系統中的瓶頸點。2.優化鏈路呼叫 通過服務追鍾可以...
微服務 API閘道器 限流
我們在api閘道器中已經介紹了，限流是保護閘道器的手段之一，和身份認證以及鑑權一起組成安全防禦大閘。其目的是對併發請求進行限速或限制乙個時間視窗內請求的數量，一旦達到閾值就排隊等待或降級甚至拒絕服務。根據上面列出的原因，我們自然知道限流該怎麼限制法，但是具體要怎麼實現呢？也就是該怎麼設計演算法來實現...