服务发现——你是我的眼！

在Eureka的圈子混，做什么都要仰仗着注册中心，前面我们说到注册中心的一大作用就是收集所有节点的注册信息，那么大家思考一个问题，注册中心收集这么多服务节点的信息做什么用呢？难道三天两头主动去找人家麻烦？NoNoNo，服务发现的故事还要从一部电影说起

你是我的眼

大家想必都看过《黑客帝国》三部曲。影片的主角是一个年轻的黑客尼奥，他发现了整个现实世界是由一个名为“矩阵”的计算机人工智能系统控制的，在这个黑暗的世界中有一个大反派“史密斯”尼奥见到了黑客组织的首领墨菲斯，在墨菲斯的带领下找到史密斯，走上了抗争的一生。

在这个故事里尼奥，墨菲斯，史密斯三人都有一个共同的特征，那就是戴着墨镜。但是不同的地方是，只有尼奥是真的瞎了。。。瞎子尼奥啥也看不见，要想靠自己去找到大反派史密斯那简直就是不可能完成的任务，他必须借助墨菲斯这位黑客组织大头目的帮助，才能完成找到史密斯的任务。Eureka里 的服务发现也是这么个道理。

• 史密斯集群网络中的服务提供者，来无影去无踪，上线下线无所不能。
• 带头大哥墨菲斯注册中心，时刻掌握史密斯的方位
• 尼奥双目失明的服务消费者，必须依靠墨菲斯的帮忙才能找到服务节点

谁去打史密斯?

话说条条大路通罗马，虽然现在知道了怎么去找史密斯，但是谁去找史密斯却成了个问题。

Eureka的服务发现也得做这么一个抉择，是让尼奥自己去找呢?还是让大哥墨菲斯或者找一个中间人来做这件事?

基于客户端的服务发现

在这个服务发现模型中，只有三个角色(尼奥，墨菲斯，史密斯)这时瞎子尼奥依然是-个勤快的小伙，他打算自己去送人头。

史密斯集群(网络服务节点)通过服务注册功能，将自己的服务信息以及IP地址发给了注册中心，调用方尼奥则从注册中心获取所有的可用服务列表，然后从中挑选一个史密斯实例， 自己上门找打。看到这里有的同学可能会问，尼奥手里有这么多史密斯，他怎么知道该找哪个?这就要说到“负载均衡”这个听起来很高大上的名词，这个知识点将在下一节Ribbon课程中深入了解。这里你可以把调用方看成一个内置了负载均衡策略的服务发起者，他会选择一个合适的节点进行服务调用。

基于服务端的服务发现

前面尼奥自己总是自己上门找揍，被打的那叫一个鼻青脸肿，所以他干脆想了一个办法，只发号施令，找打的事儿得换个人来。

这个模式下多了一个Router的概念，注册中心依然获取了所有的节点信息。每当尼奥想要教训一下史密斯的时候，他会发送一个指令给一个服务端的代理Router，这个Router既可以是服务端负载均衡器，也可以是网关层，而负载均衡策略则从发起调用的消费者一端，移到了服务端。总之，我尼奥不再自己送人头了。

论挨揍的效率

现在问题来了，上]挨揍哪家强？请看对比

	客户端模式	服务端模式
性能	块。网络转发量少，客户端直接参与负载均衡	慢，网络转发请求量大
负载均衡策略	尼奥 do care	尼奥 doedn’t care
运维成本	低，没有额外网络组件，交互模型简单	高，需要借助额外组件实现Router+负载均衡
应用	Eureka定时拉取，Dubbo订阅模式	k8s代理，AWS ELB， Consul Template + Nginx

从上面的比较可以看出，客户端模式似乎是更加轻量且效率的做法但是对于客户端来说，就要承载额外的负载均衡处理。但是显而易见的是，负载均衡无论是在客户端或者服务端，总归得是有的(大型互联网应用通常是客户端+网关层都会部署负载均衡)，所以如果采用客户端负载均衡模式的话，对SpringCloud来说则是省 了-个部署组件，这又说明了SpringCloud-切从简的原则。

本文已收录至我的个人网站：程序员波特，主要记录Java相关技术系列教程，共享电子书、Java学习路线、视频教程、简历模板和面试题等学习资源，让想要学习的你，不再迷茫。