spring cloud 负载均衡相关

负载均衡策略在消费端配置的缺点

   在上面的例子中，ribbon的负载均衡是在消费端完成的。流程是这样的：提供者服务A集群，启动2个进程A1，A2，都注册到eureka,app消费端根据api服务者名称获取到A1,A2的具体连接地址，ribbon就对A1,A2进行负载均衡。

   缺点：

    1） 如果所有的app消费端的配置策略不好，导致绝大部分的请求都到A1，那A1的压力就大了。也就是说负载策略不是有api提供者所控制的了（这里就不说A1,A2所在的服务器哪个性能更好了，因为如果app/api都是在Docker中运行，k8s负责资源调配的话，可以认为每个服务的进程所在的docker配置是一样的，比如A服务对应的A1,A2系统环境是一致的，B服务对应的B1,B2,B3系统环境是一致的，只是所对应的宿主机服务器估计不一样而已）。

   2）如果api提供者需要开放给第三方公司的时候，总不能把A1,A2告诉第三方吧，说我们这A服务集群了，有A1,A2,你随意吧。

    我们实际项目中的做法，都是每个提供者服务都有自己的nginx管理自己的集群，然后把nginx的域名提供给app消费者即可。之所以每个服务提供者都有自己的nginx，是因为docker被k8s管控的时候，ip都是变化的，需要更新到nginx中。如果A,B都共用一个nginx，那A重构建部署的时候，A1,A2的ip变化了，需要更新到nginx中去，那如果导致nginx出现问题了，岂不是影响到B的使用了，所以A,B都有自己的nginx。那spring cloud没有解决方案了吗？有。spring cloud集成了zuul,zuul服务网关，不但提供了和nginx一样的反向代理功能，还提供了负载均衡、监控、过滤等功能，在后面学习zuul的时候，我们再学习。

   docker+k8s实现的devOps平台（paas平台），构建好镜像后，部署的时候，k8s负责调控资源，将docker分配到不同的节点服务器，同时将docker的ip相关信息更新到nginx。这是自动化的，不需要开发人员手动操作docker，nginx配置。