云原生微服务（2）：服务发现和负载均衡

1. 服务发现

服务发现的作用：在微服务架构众多的微服务中，自动化地发现和识别程序中的实例，使得服务之间可以正常进行通信和协作。

两种模式：客户端发现模式和服务端发现模式。

注册中心：通过注册中心管理所有的服务信息。由服务发现维护一个可用的注册清单，微服务把注册中心当成一个数据库使用了。注册中心的作用：服务注册、服务查询、服务健康检查。注册中心需要注意的问题：数据的一致性，需要使用一些一致性协议来保证。 

服务发现的实现方案：

Apache Zookeeper：它是JAVA技术栈中非常重要的服务了。 像Hadoop，Hbase，kafka，ElasticSearch等大型分布式系统都会内置Zookeeper。 Zookeeper 提供一组高性能的、保证 FIFO的、基于事件驱动的非阻塞 API。使用类似文件系统的目录树方式对数据进行组织。 同时也是一个自洽的容错系统，使用 Zab 原子广播协议保证高可用和一致性。

Etcd： 是受到 Zookeeper 启发而催生的项目。Etcd最被大家所关注的原因，还是因为，它是K8S集群中的核心组件。

file ：就是以文件的形式实现服务发现，这是一个比较简单的方案。 需要服务提供者把IP：端口写入文件中， 然后服务消费者加载这个文件，获取服务提供者的信息，再进行访问。 优点是：实现简单，去中心化 缺点是：需要定时推送到服务消费者，如果推送失败了，就会造成访问异常现象。 所以，大型的分布式系统中，还是不太会直接使用文件作为服务发现的方案。

2. 负载均衡

因为是分布式系统架构，后端会有很多实例，需要负载均衡。负载均衡最理想的状况，就是把所有请求合理的分配到每一个服务实例上。

负载均衡的常用算法：

1）轮训算法/加权轮训算法：负载均衡器维护一个指针，每当有一个新的请求到达时，指针就会指向下一个服务器，直到指针指向最后一个服务器，然后再从头开始。优点是实现简单，不需要过多的计算和配置，可以轻松地进行水平扩展。缺点是，平均分配，可能会出现某些服务器负载过高或不可用的情况，取决于服务器的自身条件如网络带宽或存储容量，较小就可能会导致它们的负载过高。

2）随机算法/加权随机算法：通过随机函数决定分配，优缺点同上。

最小连接算法：优先调用连接数最少的服务实例。这种方法需要对每一个服务实例当前的连接数进行管理，有新的连接就要递增，当连接结束就要递减。优点是可以根据服务器的实际负载情况动态地调整负载，缺点大量请求涌入会导致某些服务器的连接数快速增加，（因为如果某个服务器的处理能力比其他服务器强，或者某个服务器的网络带宽或存储容量较大，就可能会导致它处理更多的请求）而其他服务器的连接数却没有明显变化，这可能会导致负载不均衡的问题。同时要记录连接数带来的开销。

3）散列算法（哈希算法）：它通过对请求的某些信息（如请求的IP地址、URL等）进行散列计算，然后根据计算结果选择一个后端服务器来处理请求，从而实现请求的均衡分配。优点：是可以保证同一请求始终被分配到同一台服务器上，避免了负载不均衡的问题。缺点：例如，如果请求的信息相同，生成的散列值也相同，这可能会导致请求集中在某些服务器上，从而导致负载不均衡的问题。此外，散列算法需要对请求的信息进行散列计算，可能会影响负载均衡器的性能。

负载均衡的实现方案

1）客户端服务发现模式。 负载均衡的实现在客户端完成。 客户端也就是调用方，它拿到服务的全部实例列表，然后在本地实现负载均衡算法，直接请求具体的服务实例。 这种方案的灵活性和效率是最高的。

2）DNS。 我们上网都会用到域名，而域名解析服务也实现了负载均衡。 在域名管理的地方，我们可以给某一个域名设置多个IP地址。 普遍的情况下，域名解析每次会轮询的从多个IP地址中返回一个IP。 如果是智能DNS，还可以根据客户端IP智能解析返回一个最近的IP地址，这就是实现了来源哈希算法。

3）LVS/Nginx这类作为网关或者接入层的服务。

除了上面讲过的3个方案，还有很多其他的方案。 比如：各种中间件组件，像数据库代理，缓存代理等。