有時候執行單個任務時，客戶端可能必須對不同的各個後端服務進行多次調用。因為他們依賴於多個服務，那麽客戶端必須調用不同的服務接口以完成這次請求，這樣就會導致請求過多而浪費很多的資源。當任何新功能或服務添加到應用程序時，從而會進壹步增加資源需求和網絡調用。客戶端和後端之間的這種混亂調用可能會對應用程序的性能和規模產生負面影響。微服務架構使這個問題變得更加普遍，因為圍繞許多小型服務構建的應用程序自然會有更多的跨服務調用。
在下圖中，客戶端向每個服務發送請求（1,2,3）。每個服務處理請求並將響應發送回應用程序（4,5,6）。通常具有高延遲的蜂窩網絡上，以這種方式使用單獨的請求是低效的並且可能導致連接中斷或請求不完整。雖然每個請求可以並行完成，但應用程序必須為每個請求發送，等待和處理數據，所有這些都在不同的連接上，從而增加了失敗的可能性。
使用網關來減少客戶端和服務之間的幹擾。網關接收客戶端請求，將請求分派給各種後端系統，然後聚合結果並將它們發送回請求客戶端。
這種模式可以有效減少應用程序對後端服務的調用請求數，而且在高延遲網絡上的應用程序的性能有大的提升。
在下圖中，應用程序向網關發送請求（1）。該請求包含壹組附加請求。網關分解這些請求並通過將每個請求發送到相關服務來處理每個請求（2）。每個服務都返回對網關的響應（3）。網關聚合每個服務的響應並將響應發送到應用程序（4）。應用程序發出單個請求，並且只從網關接收壹個響應。
1.網關不應該在後端服務中引入服務耦合
2.網關應該和後端服務位置很近，以盡可能減少延遲。
3.網關服務可能須要做ha。確保網關設計合理，以滿足您的應用程序的可用性要求。
4.網關可能是性能瓶頸。確保網關具有足夠的性能來處理負載，並且可以擴展以滿足您的預期增長。
5.對網關執行負載測試，以確保不會導致服務的級聯故障。
6.使用隔板，斷路，重試和超時等技術實現彈性設計。
7.如果壹個或多個服務調用花費的時間太長，則可以接受超時並返回部分數據集。考慮您的應用程序將如何處理此方案。
8.使用異步I / O來提升程序的吞吐量。
9.通過分布式跟蹤對全鏈路進行監控。
10.監控請求指標和響應大小。
11.考慮將緩存數據作為故障轉移策略來處理故障。
12.不要將聚合構建到網關中，而是考慮在網關後面放置聚合服務。請求聚合可能具有與網關中的其他服務不同的資源要求，並且可能影響網關的路由和卸載功能。
1.客戶端需要與多個後端服務通信才能完成操作
2.客戶端可以使用具有明顯延遲的網絡，例如蜂窩網絡。
1.您希望客戶端對單個服務的請求次數（比如獲取10個學生的信息，妳只有壹個單個查詢學生信息的接口）。在這種情況下，最好向服務添加批處理操作。
2.客戶端或應用程序位於後端服務附近，延遲不是壹個重要因素。
以下示例是教妳如何使用Lua創建簡單的網關聚合NGINX服務。