說起citrix公司的netscaler這款硬體負載均衡器大家可能不熟悉，它的競争對手f5，在運維界可能比較多人了解。硬體負載均衡器通常作為網絡入口流量分流的裝置，例如像淘寶網的流量特别大，可能隻有幾個入口ip，在淘寶網的流量的最前端就會部署像f5或者netscaler這樣的硬體負載均衡器作為分流。
随着雲計算越來越深入人心，像citrix這種硬體裝置商越來越賣不動了，因為絕大部分中小企業都直接跟雲計算公司采購所需的虛拟裝置，這樣的裝置可定制，可按需動态配置設定。citrix也是積極跟雲計算公司，例如aws合作，推廣自己的虛拟版本的netscaler。
容器化大潮和微服務概念的推廣下，系統被拆分成了一個個隻有單一職責的微服務，服務的擴容通過增加容器的數量來解決，服務之間的調用關系越來越複雜，像一張密密麻麻的網。當一個服務啟動，擴容或者縮容之後，需要迅速被依賴它的服務感覺到，即發現，是以發現的過程必須是自動的，且現有大部分的c/s模式的代碼都沒有提供client服務發現的能力，是以服務發現最好是對client來說是透明的。通過負載均衡器配合server端實作服務發現管理的功能正是基于容器的微服務架構特别需要的方案。由上述可見，通過負載均衡器的方式來解決服務發現的問題是微服務架構中一個特别重要的問題，而且該問題目前沒有特别好的解決方案。citrix推出的<code>nitrox</code>正是試圖解決這個問題。總結下citrix推出<code>nitrox</code>的原因：
通過提供<code>netscaler cpx</code>負載均衡軟體進軍容器市場
解決容器架構中容器與容器之間服務發現的問題
<code>nitrox</code>中使用的<code>netscaler cpx</code>與硬體負載均衡裝置的api接口保持一緻，友善其現有使用者從其他架構遷移到容器架構
我們先來看看<code>nitrox</code>的重要部分，即<code>netscaler cpx</code>負載均衡軟體，該軟體是一款收費的軟體。
netscaler的部署模式如下圖所示：
通過硬體裝置netscaler mpx來解決網絡進入容器叢集的入口流量的負載均衡，就是圖中所說的南北的流量（n-s traffic）。
通過軟體裝置netscaler cpx來解決容器叢集内，不通服務之間通信負載均衡的問題，就是圖中所說的東西的流量（w-e traffic）。
通過與編排系統配合（mesos/kubernetes/swarm）來解決自動化服務發現，動态變更負載均衡配置的問題，圖右側底層的支援平台。
nitrox作為一個容器，跑在容器叢集内，同時有偵聽編排系統(mesos/kubernetes/swarm)事件，以及讀取編排系統資訊的能力，當各主機上的容器狀态發生變化時，變化上報到編排系統(mesos/kubernetes/swarm)，編排系統再把事件通知到各個偵聽的用戶端。nitrox作為用戶端接收到事件後，重新擷取目前容器叢集中各個容器的狀态。根據最新的叢集狀态來更新各個容器的路由。除了初始化基本的配置，上面說的負載均衡動态配置，都是通過腳本自動完成的，最終做到了服務的自動發現。
現在我們來總結下docker容器架構通過動态負載均衡來實作服務發現的方法
在容器裡面實作負載均衡通常采用以下思路
負載均衡裝置
4層包括ipvs，各大雲計算廠商的負載均衡裝置，例如aliyun的slb， aws的elb等，以及本文中提到的f5，netscaler
既包含4層又包含7層的負載均衡軟體，目前最流行的包括haproxy，nginx（以及衍生出來的國内的tengine)
通過dns來做負載均衡，問題比較多，例如dns有本地緩存，容易導緻資料不一緻，且對某些client端有要求，某些client端不會每次請求都去dns拿最新的路由資訊，是以一般很少将dns作為負載均衡的方案。
擷取負載均衡資訊的api（從swarm，kubernetes，mesos擷取）或者注冊中心擷取，即registry，包括 zookeeper，etcd，consul等
通過腳本監聽registry或者編排系統的事件，某些事件如果導緻負載均衡發生變化，便将最新的負載均衡資訊更新到負載均衡裝置中
最後，從幾個角度來對比類似負載均衡實作的差異。
對比
nitrox
dockercloud/haproxy
docker1.12内置負載均衡能力
負載均衡能力
4層
主要是7層，兼具4層
4層，實作是ipvs
支援方式
每個節點需要安裝兩個容器
每個節點一個dockercloud/haproxy容器
不需要額外的容器
負載均衡技術實作
未知
使用者态
核心态
支援動态負載能力
是
實作位址
<a href="https://github.com/docker/dockercloud-haproxy">dockercloud-haproxy</a>
<a href="https://github.com/docker/docker">docker 1.12 内置</a>
預測最終docker官方會逐漸推出自己的服務發現完整方案，我們在docker 1.12中應該能看到該方面的迹象，其他公司在解決服務發現方面的提供的産品會是一個很重要的補充。