單體應用的情況下，很簡單，客戶端只需要發起一次服務請求，就可以獲取多個需要的服務結果。
而在微服務的情況下，顯示在產品頁面的數據可能分佈在不同的爲微服務上，例如：
購物車服務——購物車中的件數
●訂單服務——歷史訂單
●目錄服務——商品基本信息，如名稱、圖片和價格
●評論服務——客戶的評論
●庫存服務——低庫存預警
●送貨服務——送貨選項、期限和費用，這些信息單獨從送貨方 API 獲取
●推薦服務——推薦商品
我們加載一個商品頁面時，客戶端要向至少7個微服務發送請求，並接收返回結果。
在微服務架構下，客戶端直接與服務器進行的方式很少在實際中使用。我們就需要一個前置服務，即網關，來解決上面的問題。
網關：封裝了應用程序的內部結構，客戶端只需關心與網關交互。具有服務請求路由、服務請求組合、協議轉換等功能。
缺點是：是增加了一個必須開發、部署和維護的高可用組件，然後每次開發微服務新模塊或更新端點，都需要更新API網關。
spring cloud的網關，Zuul，一個提供了動態路由、監控、彈性負載和安全功能的網關組件。
Zuul是Netflix的基於JVM的路由器和服務器端的負載均衡器。Zuul中的所有請求都在Hystrix Command中執行。所以當斷路器打開時，代理將不會重試連接後端服務。
uul中，所有路由默認的Hystrix的隔離模式爲SEMAPHORE，可以使用“zuul.ribbonIsolationStrategy”參數改爲其他的隔離策略（如THREAD）。
回顧：
THREAD(線程隔離）：使用該方式，HystrixCommand將會在單獨的線程上執行，併發請求受線程池中線程數量的限制。
SEMAPHORE（信號量隔離）：使用該方式，HystrixCommand將會在調用線程上執行，開銷相對較小，併發請求受到信號量個數的限制。
啓動註解“@EnableCircuitBreaker”，Zuul中的所有請求都在Hystrix Command中執行。
@EnableCircuitBreaker
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(ZuulProxyMarkerConfiguration.class)
public @interface EnableZuulProxy {
}
可以看到是有Hystrix的啓動註解“