呼叫服務一般是在customer裡寫個介面，介面裡寫上producer中controller裡的方法（注意路徑也要與controller中的一致），然後讓其他類通過這個介面呼叫另乙個服務的方法。
但這裡有個問題：如果呼叫服務者要用到被呼叫服務者的實體類怎麼辦？比如我寫了個操作日誌資料庫的服務（稱為producer），然後在訂單服務（稱為customer）中需要寫個***獲取這個對訂單操作的日誌，然後呼叫producer服務來存入資料庫中。
總結為三個問題是：（1）customer將獲取到的日誌資訊要進行set到producer實體類中的屬性裡，但是又不能在customer裡寫個producer實體類，否則太冗餘了。（2）在customer的介面裡再寫一遍producer中的方法名和路徑很麻煩，還容易出錯。（3）這樣還暴露了producer中的方法實現。
將producer和customer都用到的實體類寫在commonapi裡，並且將producer中的controller類的介面（這樣的話controller類就是這個介面的實現類了）也寫在commonapi裡，路徑也是寫在這個介面裡，然後將這個介面打成jar包，producer和customer分別引入這個jar包。producer中的controller去實現這個介面（這樣controller裡不用寫路徑了），customer裡的介面去繼承這個介面即可。如下：
然後其他方法要用時，注入就行了：
微服務學習筆記 追蹤微服務呼叫
微服務系統追蹤微服務呼叫，跟蹤記錄一次使用者請求經過哪些呼叫，經過哪些服務處理，並且記錄每一次呼叫所設計的服務的詳細資訊。如果發生呼叫失敗，可以根據日誌快速定位出現問題的環節。一 作用 1.優化系統瓶頸 通過記錄呼叫經過的每一條鏈路上的耗時，快速定位系統中的瓶頸點。2.優化鏈路呼叫 通過服務追鍾可以...
微服務學習筆記 如何監控微服務呼叫
錯誤率一段時間內呼叫失敗的次數佔呼叫總次數的比率來衡量，比 如對於介面的錯誤率一般用介面返回錯誤碼為 503 的比率來表示。1 資料採集 考慮的問題就是取樣率，也就是採集資料的頻率。取樣率決定了監控的實時性與精確度，一般來說，取樣率越高，監控的實時性就越高，精確度也越高。但取樣對系統本身的效能也會有...
模擬springcloud微服務呼叫
分布式服務框架目前市面上用的最多的估計就是上面兩個框架,dubbo與springcloud關於這兩個框架的對比 我個人跟認為 dubbo是遠端服務呼叫框架 springcloud更是微服務框架 從效能上來說 dubbo效能更好 但是本身的功能有限 springcloud 是提供了一整套微服務的框架 ...