微服务采用服务发现机制，不用负载均衡的原因

《Spring Micorservices in Action》第4章笔记。

微服务通常及基于云平台的，不采用负载均衡的原因有：

1. 单点故障。如果负载均衡器挂了，所有服务都不能被访问。就算负载均衡器是高可用的，它也会成为整个应用的瓶颈。
2. 限制了水平扩展。单节点的负载均衡器能力是有限的。负载均衡器有两点制约： 冗余模型和许可证费用。大部分的负载均衡器采用热交换的冗余模型，只有一台服务器处理负载，另一台只有在主负载均衡器失效的情况下才工作。另外商用负载均衡器也受许可证费用的制约。
3. 静态化管理。大多数传统的负载均衡器使用一个中央数据库保存路由信息，只有通过提供商特殊的API才能添加新的路由规则。不适合快速注册和快速取消注册。
4. 复杂。负载均衡器作为服务的代理，需要将客户发来的请求映射到具体的服务。这需要在负载均衡器上手工定义服务的映射规则。如果有新的服务提供者加入，也需要手工修改负载均衡器添加映射规则。

小规模的情况下，可以使用负载均衡器。另外，负载均衡器还可以集中处理SSL协议。

但是在云平台上，需要处理大量的交易，一个集中式的网络基础设施不能有效的扩展，所以就不合适了。

在基于云的微服务环境中，采用服务发现机制：

1. 高可用， 基于“服务发现集群”
2. 点对点。服务发现集群下的每个节点都共享服务实例的状态。
3. 负载均衡。服务发现也需要负载均衡。采用客户端负载均衡。
4. 弹性。客户端会缓存服务的信息。如果“服务发现”失效，客户端可以使用本地缓存的信息找到服务提供者。
5. 容错性。当“服务发现”侦测到某一个服务不可用时，可以将他从可用服务列表删除。可以自动检测到服务故障，无需人工参与。