SpringCloud內建Ribbon
Ribbon 是一個基于 HTTP 和 TCP 的 客服端負載均衡工具，它是基于 Netflix Ribbon 實作的。
說的明白點就是一個或者多個消費者去調用生産者的方法，但是哪個消費者去調用哪個生産者這個是根據算法來确定的，Ribbon就類似于這個算法。
Ribbon有很多的負載均衡算法，輪詢政策（預設）、權重輪詢政策、随機政策、最少并發數政策、重試政策、可用性敏感政策、區域敏感性政策。很多算法看名字就知道意思，這裡算法不是本次讨論的重點，也不再累述，後面有機會了解一下。
Ribbon是內建于用戶端的，業内也有兩種主流的負載均衡的方案。1.集中式負載均衡（伺服器負載均衡），通過一個單獨的子產品來實作負載均衡。2.程序内負載均衡（用戶端負載均衡），用戶端通過算法去查詢合适的生産者，然後調用。可以顯而易見的看到Ribbon是屬于後者的。
還是老樣子，實際操作一下，後面再說原理的事。成功了才會有興趣去深入。
因為OpenFeign已經內建了Ribbon，是以之前的代碼不需要大的改動。
要實作負載均衡，需要有兩個生産者。這裡直接将一個生産者的檔案夾複制，在修改檔案夾名字，然後IDE導入子產品就可以了。項目結構如下：
第二個生産者子產品需要修改一個端口号，以免兩個生産者啟動沖突。然後啟動兩個生産者子產品即可。可以看到注冊中心頁面如下：
然後使用swagger-ui直接調用消費者的方法，消費者通過OpenFeign調用生産者的方法。會發現兩個生産者的控制台在循環列印資訊，這是因為Ribbon預設使用的輪詢算法。效果如圖：
生産者1:
生産者2:
總共是調用了五次，是以生産者累計列印了五次。
在編寫的過程中才發現，Ribbon更多的是提供了一個思路或者解決辦法，解決的問題就是生産者和消費者之間排程的問題。因為SpringCloud對于這些元件內建的比較好（還是之前說的，這些工具的産生是為了加快開發的速度），是以本次更多的還是了解負載均衡的意義和原理。後面也會對這些源碼進行閱讀，了解深層次的一些東西。
就這樣吧，結束。