我有這種情況，我有一個外部.net核心API網關，我的移動設備與之通話，然後網關調用許多單獨的內部「微型」服務。從一個API調用到另一個API時的延遲
我的問題是在本地服務器上和Azure上的IIS/Kestrel（因爲我的開發設置在Azure中，但在個人服務器上生產）。
問題是如果在這兩種情況下調用內部API的開箱即用盡可能小的延遲潛力？或者我可以做些什麼來「連接」外部和內部的API來獲得更少的延遲？
我真的不能在這個上找到任何好的數據，所以我想我沒有這個問題的正確術語。
希望你能幫我解釋一下。
簡短回答：在調用遠程服務時，在.NET代碼中使用async/await pattern。儘可能地將服務和服務器放在一起，以減少網絡開銷。
如果你的代碼調用通過HTTPS一些其他的服務，總是會有事情等相關的一些延遲：
前兩個是最小值我不能對他們做太多的事情。數據包在兩個物理位置之間所需的時間可能在5ms到200ms（或更多）之間變化，這就是將服務放置在同一地理區域或數據中心的原因。
就你的代碼而言，只要你使用的是async/await pattern，你的代碼已經以最快的網絡速度運行。如果延遲時間不符合您的要求，則需要更快地創建服務器，或者將它們靠得更近。
公平的警告：我不是網絡工程師，這是一個非常高層次的概述。我建議在Server Fault處詢問技術網絡問題。
好吧，這樣說我有相同的IIS相鄰的外部和內部服務（我不這樣做，只是假設）它會總是隻用較短的包路由時間擊中你的子彈點？我希望對於天藍，例如，如果你願意的話，我可以告訴外部API使用內部的API，就像服務層一樣。謝謝你的回答，你的推薦文章在SF上發佈。 – Sturla
如果您調用的是同一臺機器上的服務，則基本上不存在網絡和路由延遲。我不太清楚我是否按照你的問題，對不起！ –
這可能只是我需要感謝的答案。當在同一臺服務器上運行或在網絡上運行時，延遲會非常小，對我而言可能無關緊要。我可以在代碼中找到其他的東西，並使其更快。關於Azure設置，我認爲我已將所有服務歸入同一「資源」，因此它們的行爲與它們位於同一臺服務器上（至少在同一個關閉網絡中）相同。但是我會問一些Azure專家。 – Sturla