qq_35918388的博客

之前写过一篇ribbon的帖子，介绍过ribbon的概念和基本使用，这里不再展开描述，具体可以查看我的另外一篇文章客户端负载均衡Ribbon，时间来到20年，ribbon跟随eureka一样已经进入维护模式，springcloud为了自己的生态不受影响，已经自行研发替代ribbon的方案，后期会换成使用Loadbalancer，本文对此组件不过多展开描述，目前大部分公司使用应该还是以ribbon为主。Ribbon的作用就是负载均衡，不同于服务端的负载均衡策略，它使用的是客户端负载均衡，简单讲就是将请求分

老版的springcloud全家桶对于服务注册与发现组件，官网给出了Eureka，Zookeeper，Consul的选择，之前的博客也都做过简单的介绍，今天想分析和比较一下这三大服务注册与发现组件的异同点。首先springcloud的出现主要是为了解决分布式服务难于治理的局面而产生的微服务架构的解决方案，做过分布式和微服务的应该都知道CAP理论（即强一致性，高可用性，分区容错性），其实CAP理论的提出关注的是数据，而不是系统设计，但是当前微服务盛行的时代，系统设计上也借鉴数据CAP理论，形成了系统设计的

上篇文章介绍了如何使用zookeeper作为服务与注册中心，本篇文章将介绍一下如何使用Consul来实现服务注册与发现，当然这个也不是我个人杜撰，是springcloud官网介绍推荐的组件之一，既然要学就要学的彻底一些，我在实际项目开发中，用的都是eureka和最新的nacos，Consul也仅限于在个人学习中使用过，踩的坑很少，可能也有一些理解上的错误，还是那句话，欢迎批评指正，技术是需要交流的。Consul我接触的不多，第一次和最后一次接触只在springcloud官网上见过，度娘了一下它的用途，在

上次关于springcloud的学习还是在18年写的，当时初入门槛很多都是照本宣科的记录，加上工作原因，一直处于断更状态，近两年一直在做springcloud的相关开发，自己也在实际开发中踩过不少坑，现在想对过往经验做些记录和总结，也给初入springcloud全家桶的朋友介绍一下我的经验，其中不乏有错误，如果有发现，欢迎指正。今天这篇博客想介绍一下当时风靡一时的eureka在停更进入维护后，我们如何使用zookeeper作为服务注册的替代方案，至于eureka为何停更这里不再多说，感兴趣的朋友可以自行

        上一篇介绍使用了Eureka服务注册与发现的组件使用，我们已经将服务提供者和服务消费者注册到EurekaServer上，但是在消费者调取服务者时，还是在使用硬编码的方式（指定ip和端口号）来使用的，这种方式使用起来不够灵活，而且需要变更服务提供者的时候需要手动修改相应的访问地址，而且我们配置多个服务提供方以后，如何实现对服务提供方随机访问呢，实现的办法比较多，比如在消费方和服务提供...