最近把公司所有的 RPC 服务都加上了服务注册及服务发现，多亏了各位同事的支持才能这么短时间就全部替换完毕并更新上线。

为什么做这件事情呢？公司里的业务服务都是微服务架构，每个 RPC 服务做的事情都很简单，随着业务的不断发展，RPC 服务也越来越多，目前已经有上百个 RPC 服务了。之前调用这些 RPC 服务的地方都是通过配置文件写死具体每个 RPC 服务所在的 ip 和端口，配置文件里充斥着各种服务的 ip 端口信息，想要动态扩容服务机器或者做故障转移也很不方便。而部署 RPC 服务的时候还得到 WIKI 页面上登记该服务所在的 ip 和占用的端口号，调用方也需要到这个页面来查找服务部署信息，对我这种懒人来说也是无法忍受的。为了解决这些问题，决定加上服务注册发现。

服务注册发现有非常多的开源解决方案，作为一个懒人，有现成能用的当然就捡现成的用了。问题是这么多解决方案，怎么挑呢？当时候选列表有 servicex（公司同事作品）、 dubbo（阿里巴巴）、curator（Netflix）、consul（HashiCorp）、etcd（CoreOS），最终我选择了 consul。至于选择 consul 的原因，很简单：设计合理、使用方便、维护轻松、可用性高、符合我的审美 :D

ServiceX: 公司同事个人作品，是他用了几天时间开发的，时间仓促设计不合理，而且公司人手紧缺后续也肯定没有时间精力继续维护，这个首先就被我排除在考虑范围了。

dubbo: 阿里巴巴开源作品，Java API，服务需使用 API 自主注册。github 上该项目还挺多人关注，但注意到该项目最后发布时间是 2014年10月，距今已有一年半时间了，新版本似乎也无疾而终，这个也被我排除掉了。

curator: Netflix 开源作品，目前归到 Apache 基金会下，使用 zookeeper 存储服务信息，Java API，服务需使用 API 自主注册，设计理念及使用方式不符合个人审美，淘汰。

consul: HashiCorp 开源作品，提供 RESTful API 和 DNS API，设计思想和 DNS 非常类似(其实服务注册发现本质上就是 DNS SRV 记录)。服务通过 consul 配置文件注册，无需在现有程序中加任何代码，当然也可利用 RESTful API 进行自主注册。服务只需和本机的 consul 通讯即可完成服务注册及服务发现，本机的 consul agent 会自行与 consul server 通讯以发现其他机器上注册的服务，consul 与 consul 之间通过 gossip 协议自动组成集群。

etcd: CoreOS 提供的 key/value 存储服务，可用于服务注册发现，未详细了解。

总的来说，consul 的设计比较合理，专注做一件事情并把这件事情做好了。