客戶端直接訪問各子服務：
微服務剛剛誕生的時候，人們將服務進行拆分，實現服務之間的松耦合，並且每個服務有專門的團隊維護，然後客戶端直接和各個子服務進行互動。比如，訂單，商品，會員服務。
這種客戶端直接和後端服務互動的方式會有什麼問題呢？
1、客戶端需要知道每個服務的位址（如果有閘道器，分布式部署的話這樣可以統一api的ip位址，再由閘道器去分發，可以通過註冊中心獲取你需要的服務節點列表，然後給你分配你呼叫那個節點去呼叫）
2、每個後端服務都需要實現認證、限流、日誌、監控、快取等功能，重複造輪子大大降低了開發效率，而這些公共業務邏輯完全可以拆分出來。而且會造成的**複雜度和維護難度上公升。
3、假如後端某些服務由之前的http/https呼叫變成rpc呼叫，或者某些引數發生改變，則客戶端需要做很大調整。
這裡我覺得還有必要補一篇rpc遠端呼叫和restful請求的區別，這裡簡單科普一下：
rpc一般用於內部微服務之間的呼叫，restful請求也就是http請求一般是請求外部服務；
rpc可以像呼叫本地方法一樣去呼叫其它微服務（在不同的伺服器）的方法，原理是一般是cp/ip協議+動態**。這裡就減少了向外暴露的服務。而http請求是基於http協議的，需要暴露給外部，而且需要自己封裝請求提和請求引數。rpc只是一種概念，有多種實現方式。
引入閘道器可以怎麼解決這些問題呢？
1、閘道器作為邊界，分割了內部應用和外部呼叫。
不同於外部api一般使用http或rest，內部微服務可以從使用不用通訊協議中收穫益處。這些協議可以是protobuf或amqp，甚至是諸如soap，json-rpc或者xml-rpc這樣的系統整合協議。api閘道器可以對這些協議提供統一的外部rest介面，這就允許開發團隊挑選一款最適合於內部架構的協議。
2、閘道器實現了安全層，降低了各子微服務的複雜度
api閘道器通過提供額外的安全層幫助阻止大規模攻擊。這些攻擊包括sql注入，xml解析漏洞和dos攻擊。
微服務中有一些常見的要點，諸如使用api令牌進行授權，訪問控制和呼叫頻次限制。這每個點都需要每個服務區增加額外的時間去實現它們。api閘道器將這些要點從你的**中提取出來，允許你的服務只關注於它們需要關注的任務。同時可以作為統一收集微服務日誌的地方，方便了問題的定位。
3、微服務方便了服務的管理，提供了外部請求的統一入口，實現了路由**，同時降低了對外暴露的服務
如果乙個業務功能，呼叫了n個外部微服務，那邊管理和維護起來簡直是噩夢，二微服務萬貫基於統一的網域名稱和上下文去訪問，管理起來更加方便。同時閘道器還可以實現路由**和負載均衡的功能，但是並不是最佳的選擇，因為有其它開源元件比它更nb，那就是nginx。
你可以理解為基於效能問題。
讓我們來看看乙個同時有閘道器和服務發現註冊中心的請求路徑是怎樣的？
乙個請求過來了，根據閘道器根據路由規則分析出是請求的哪個服務，然後跟註冊中心說：這個xx服務有木有？沒有？那404！有？服務下有幾個例項，都告訴我我自己找乙個或者你告訴我乙個能用的。然後把請求往某個服務的某個例項上傳送，得到返回值後丟給客戶端。 這樣就不會出現，某個服務一直被調而一直在等待響應最終造成伺服器掛掉的風險。閘道器保障的是微服務之間的安全和解耦，註冊中心是保障微服務的高可用和可靠。但是閘道器的配置最好更高一點，不然也是一種風險。或者在閘道器前面掛乙個nginx**，多幾套閘道器例項也行。
go kit微服務，服務註冊與發現，負載均衡（二）
負載均衡 consul 是 hashicorp 公司推出的開源工具，用於實現分布式系統的服務發現與配置。與其他分布式服務註冊與發現的方案，consul的方案更 一站式 內建了服務註冊與發現框 架 具有以下性質 分布一致性協議實現 健康檢查 key value儲存 多資料中心方案，不再需要依賴其他工具...
Docker Swarm服務發現和負載均衡原理
docker swarm服務發現和負載均衡原理 docker使用的是linux核心iptables和ipvs的功能來實現服務發現和負載均衡。iptables是linux核心中可用的包過濾技術，可根據資料報的內容進行分類 修改和 決策。ipvs是linux核心中可用的傳輸級負載均衡。本地建立乙個集群環...
基於Docker的負載均衡和服務發現
核心空間 lvs ipvs 使用者空間 nginx 使用者空間 haproxy 自定義路由服務 作為乙個可選的容器，實現跟簡單路由服務類似，解決如下需求 slb路由服務 將slb繫結到某個服務上面，後端隨服務的啟停動態配置。主要解決如下需求 layers s n ingress 入口通訊 e w p...