負載均衡策略在消費端配置的缺點

   在上面的例子中，ribbon的負載均衡是在消費端完成的。流程是這樣的：提供者服務A叢集，啟動2個程序A1，A2，都註冊到eureka,app消費端根據api服務者名稱獲取到A1,A2的具體連線地址，ribbon就對A1,A2進行負載均衡。

   缺點：

    1） 如果所有的app消費端的配置策略不好，導致絕大部分的請求都到A1，那A1的壓力就大了。也就是說負載策略不是有api提供者所控制的了（這裡就不說A1,A2所在的伺服器哪個效能更好了，因為如果app/api都是在Docker中執行，k8s負責資源調配的話，可以認為每個服務的程序所在的docker配置是一樣的，比如A服務對應的A1,A2系統環境是一致的，B服務對應的B1,B2,B3系統環境是一致的，只是所對應的宿主機伺服器估計不一樣而已）。

   2）如果api提供者需要開放給第三方公司的時候，總不能把A1,A2告訴第三方吧，說我們這A服務叢集了，有A1,A2,你隨意吧。

    我們實際專案中的做法，都是每個提供者服務都有自己的nginx管理自己的叢集，然後把nginx的域名提供給app消費者即可。之所以每個服務提供者都有自己的nginx，是因為docker被k8s管控的時候，ip都是變化的，需要更新到nginx中。如果A,B都共用一個nginx，那A重構建部署的時候，A1,A2的ip變化了，需要更新到nginx中去，那如果導致nginx出現問題了，豈不是影響到B的使用了，所以A,B都有自己的nginx。那spring cloud沒有解決方案了嗎？有。spring cloud集成了zuul,zuul服務閘道器，不但提供了和nginx一樣的反向代理功能，還提供了負載均衡、監控、過濾等功能，在後面學習zuul的時候，我們再學習。

   docker+k8s實現的devOps平臺（paas平臺），構建好映象後，部署的時候，k8s負責調控資源，將docker分配到不同的節點伺服器，同時將docker的ip相關資訊更新到nginx。這是自動化的，不需要開發人員手動操作docker，nginx配置。