服务发现：基于客户端和服务端的实现

This nginx article described it well.

基于客户端的服务发现

客户端先访问一个service register服务，拿到一个list。然后客户端可以基于这个服务列表，用Load balance的方式访问服务。
Netflix Eureka和Ribbon是很好的例子。

Netflix Eureka是一个service register服务，serviceInstance和client上都有Eureka client，这样好进行各种有关服务注册，query等。
Eureka也可以被Etcd，Consul和Apache Zookeeper替代。

Netflix Ribbon是一个Router/LB服务, 它与Eureka集成，ribbon-eureka组件会返回一个服务的列表。
客户端的Load balance服务有几种rule：（1）Round robin，（2）基于response time weighted，和（3）random。也可以扩展。
Ribbon有容错功能，它会通过IPing interface，按照用户指定的方式来“Ping”这些服务，如果不在了，就会跳掉。
注意这个List里面的服务是等价的。
这也是一个基于web的无状态服务常常采用的策略。

Ribbon也可以和ELB结合，request被发往ELB，做简单的LB，然后进到所谓的“API edge server”。这些API edge server上有Ribbon的服务，它再进一步通过和Eureka联系，找到列表，进一步把服务分发到服务的server。你可以把这种结构认为是ELB高级功能的内部实现。

参见Ribbon Wiki

基于服务器的服务发现

客户端没有服务列表，它向一个服务ELB提交请求，在ELB的内部，它会和Service register联系，找到服务的instance地址。然后这些请求被发往这些instance。

一个例子是AWS ELB。用户只需要朝一个Domain name发服务，然后内部ELB会把服务发送到一系列注册的instance上。这里ELB内部可能也有容错功能，来IPing注册的服务，这里可能和Ribbon是一样的。

ELB也可能和上一章的Ribbon一样，分为两层，内部先是发往API Edge Server（比如通过定义listener），然后再LB到服务。

REF:
Jimmy Song的kubernetes handbook文章