微服务架构火了之后，伴随而来的一个问题就是如何做服务注册和发现（Service Register and Discovery）。
为什么需要服务注册与发现
对于微服务架构来说，每个服务都可以单独地管理和部署。比如把服务部署在多个节点上，前端请求过来之后采用负载均衡策略把流量打到具体的机器上。如果某个节点宕机（比如最常见的原因Out of Memory），这时候用户的请求达到了宕机的机器上就会造成很不好的用户体验。又比如说横向扩展的时候，手动添加配置也很繁杂。
服务注册与发现就是用来解决这些问题的。所有服务的IP地址以及端口都存放在一个强一致性的数据中心。对于服务宕机以及添加能够自动发现，不再需要人工干预。
服务注册中心
服务注册中心是一个高可用强一致性的服务发现存储仓库，主要用来存储服务的api和地址对应关系。为了高可用，服务注册中心一般为一个集群，并且能够保证分布式一致性。目前常用的有ZooKeeper（ZooKeeper除了存储还有其他功能）, Etcd等，这两者的区别主要在于ZooKeeper使用Paxos来保证强一致性，而etcd使用Raft协议。相比于Paxos，Raft实现起来要更容易一点。而相比ZooKeeper，etcd要轻量很多，目前使用的也比较多，特别是现在和docker一起使用。
服务注册的策略
服务注册的一般做法是注册中心提供一个RESTful API，这样服务就可以访问这个API来实现服务注册了。当然也可以使用其他方式，比如consul可以通过配置文件的形式来实现新服务的注册（前提是service的节点上运行着consul agent）。如果要强行将服务注册分类的话，可以分为主动注册和被动注册，前面提到的注册中心提供API的方式就是服务的主动注册，被动注册一般是通过第三方组件监控服务状态（或者事件监控）来实现。可以用下面两张图来简单表示。
服务发现的策略
服务发现的策略主要有两种：Client端和Server端发现策略。
客户端服务发现
客户端服务发现就是客户端（通过SDK）自己去发现最终的IP和端口。首先客户端向服务注册中心发请求，得到服务的IP地址和端口，然后使用负载均衡算法选择一个节点。流程可以用下图所示。在服务启动的时候，它的地址会存放在服务注册中心。之后注册中心负责更新或摘除节点（节点宕机）。这种策略在某些App上应用的比较多。
服务端发现策略
服务端发现策略也就是说服务端负责服务的定位。大部分情况下客户端通过负载均衡器向服务发送请求。负载均衡器然后向服务注册中心请求。
总结
这里先简单介绍一下，后面会分别讨论Etcd和Consul等。