警告：本文仅仅适合初探RPC的小伙伴，对于业界老鸟的话，就不建议吐槽了。。。。
第一篇我们介绍了一个简单的远程调用模型，下面我们深入一点来说说服务注册与发现。
服务注册与发现这个概念我也是理解了一段时间，简单点来说就是，服务段把提供的服务，方法名称，地址，请求参数等信息放到一个第三方信息库中（这里选用zookeeper集群）。客户端从第三方信息库中获得这些信息。这就是我理解的注册和发现。当然具体细节比这个稍微麻烦丢丢，但是这里我们简单点使用，还是比较好理解的。 
（这里先盗用一张图，如有侵权请联系作者删除）
这里服务端即图中服务提供者，客户端即服务消费者，第三方信息库即服务注册中心。假设服务端上现定义一个UserService 接口，有个抽象方法getUserInfo,请求参数是userId 返回类型是UserInfo，同时服务端实现了这个接口。将其注册到服务注册中心，注册名称为userService，数据为该服务端的地址+端口（192.168.3.19：8888）， 这里请求参数等认为是协议好的，不存储在服务注册中心。当zookeeper数据变化时，zookeeper的Watcher（数据变更的通知）会通知客户端，更新客户端上的发现服务缓存获取最新的变更数据。
说完了服务注册与发现，联系第一篇文章中说的远程调用，我们现在有了远程服务的地址，现在可以远程调用这个接口（服务）。这里为什么加个服务注册中心呢，一个远程调用不是已经解决了服务调用的问题么，难到真是给自己找麻烦？显然不是。文章标题早其实已经透露。当一个系统用户量越来越大时，服务端将不在是单一的一个，而是多个，当然客户端也不在是单一的一种，可能会有多种。这里就设计到分布式的感念，一台服务器无法提供如此多计算量，引入多台服务器，分摊计算量。同时每个客户端应该请求哪个服务端呢，这里又涉及到一个新概念，负载均衡策略。负载均衡策略是在客户端上实现的，其中最简单的策略就是随机策略，即客户端随机请求服务端。这个很好理解，我有5个客户端都提供了userService这个服务，客户端随机的去选择一个服务端。当然现实环境当中，可能出现服务器性能不同的情况，说极端点的，发布了userService服务的5台服务器当中有4台服务器性能相同，另外1台服务器的性能是其他服务器的2倍。那么这台服务器获得的请求应该是其他服务器的请求的2倍，请求比例为1：1：1：1：2。这就是加权的概念，实现了这种随机策略的就叫加权随机策略。均衡策略有很多，blackRpc当中就实现了5种策略。随机，加权随机，轮询，加权轮询，一致性HASH。至于实现，大家自己看源码。