微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务，同时服务提供方一般以集群方式提供服务，也就引入了负载均衡和健康检查等问题。以下列举了服务注册发现机制的需求：
1. 服务注册
对于提供服务的每一个实例，要能够识别当前环境和存储相关信息。存储的信息本身通常采用键/值对的格式。由于服务发现经常用于分布式系统，所以要求这些信息可伸缩、支持容错。服务提供方提供的服务包括WebServer、NFS服务、FTP服务、mysql服务等。
2. 服务发现
服务发现背后最基本的思想是，所有对服务注册阶段存储信息感兴趣的各方，可以找到最起码诸如服务IP地址和端口这样的信息，用于它们之间的相互通讯，这些数据还经常扩展到其它类型的信息。服务发现工具要提供提供某种形式的API，用于服务自身的注册以及服务信息的查找。
3. 负载均衡
可以制定服务分配规则，例如带某些标签的client请求服务时，被分配特定的服务端等。
4. 健康检查
可以制定服务失效判断规则，例如，服务不可连接；服务未上报健康状态；服务不返回200；服务所在宿主机内存大于90%等。
5. 自动恢复
服务被认定失效后，当其恢复时，应能够感知到服务上线，并及时分配给客户端。
6. 服务重载
某些服务依赖静态配置文件，当配置信息变更是，能够及时感知到变更，并主动加载配置，重载服务。
7. 去中心节点部署
服务的注册与发现均能够向任一个活着的节点发起。
8. 数据的强一致性
分布式部署时，各个节点上注册的信息应该时刻保证一致，即某个服务信息只有复制到全部的活着的节点之后，才会被提供给client使用。
9. 基础的keyvalue存储
供应用额外使用，例如系统层面的一些配置。
10. 可视化的管理界面
未完待续……
参考：http://dockone.io/article/667