我正在為我的公司做一個舊專案，我發現了一個奇怪的代碼實踐。
我們有多個 API：
Account/CostumerInformations => Should return all information
Acount/CostumerName => Return just name
Acount/CostumerPhone => return just phone
在函式 CostumerInformations() 的代碼中，他們正在呼叫同一服務的其他 API（微服務正在呼叫自身）（Acount/CostumerName，Acount/CostumerPhone），我覺得這很奇怪，因為我認為這不是一個好習慣. 問了 Architect 后，他給出的理由是，這是通過負載均衡器，使呼叫更快的唯一理由。
我認為我們應該呼叫一個任務來完成這項作業，而不是呼叫微服務本身。
在這種情況下，最佳做法是什么？
uj5u.com熱心網友回復：
據我了解，目前不將事物保留在內部的原因是為了減輕潛在的性能問題。如果過去確實存在性能問題，那么將事情保留在內部可能不是可行的方法，并且實際上可能會導致服務性能下降。
您可以選擇將 CostumerInformations 拆分為它自己的微服務，這實際上將以幾乎相同的方式拆分對 CostumerName 和 CostumerPhone 的呼叫，但無需呼叫“自身”。
uj5u.com熱心網友回復：
這似乎是不費吹灰之力。該 pull-all 函式需要重構以一次性從資料庫中提取所有資料，如果需要，使用分頁，而不是將其卸載到同一函式中的其他端點。每次該服務呼叫自己時，它都會浪費時間在您的網路路徑中旅行，增加延遲并增加成本。如果你的架構師認為“通過負載均衡器”會使其更快，那他就是個白癡——這會讓懶惰而不是正確地實作這一點變得更容易
uj5u.com熱心網友回復：
表結構是什么樣的？如果所有資訊都駐留在同一個表中，那么使用內部 API 可能會很好。可能缺少一些資訊，您可能想檢查是否有某種方法可以引入 LocalOptimization 或代碼中已經存在，這些方法可以巧妙地識別是呼叫內部 API 還是呼叫外部 API。只是假設，但小代碼重構應該在這里有所幫助。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/418646.html
標籤：