WN-YoungKun的博客

之前，猿Why认为应用中集成Consul进行服务注册与服务发现。那么，应用中的服务列表应当也是由Consul模块进行更新。为了给同事一个准确的回答，再次看了看源码后，发现服务列表的更新，并不是由服务注册中心和服务发现模块来处理的（比如Consul、Eureka）。首先，服务注册中心的概念是抽象的，所以服务列表的更新必然不是由服务发现的具体实现方式（Consul、Eureka）来实现的。具体实现方式仅需要提供从服务注册中心获取服务列表的API，提供给负载均衡时候的服务发现使用。猿Why目前工作中用到的负载

猿Why为什么会想着写这样一篇文章？请先阅览先序篇。先序篇，对Consul服务的服务特性、Spring Cloud Consul模块服务注册与服务发现原理进行了了解。但是感觉还是不够，在与同事“抬扛”的时候，明显的底气不足，特别是和“云端的架构师”聊服务治理的时候。所以，猿Why打算针对Consul的一些服务特性做几个验证性试验。问题一：Consul服务重启，应用服务是否需要重新注册？实验步骤：启动Consul服务启动应用服务，注册到ConsulConsul服务关闭Consul服务重新启动

继续上一篇文章，猿Why最近与Consul杠上了。也是因为有这样一个需求：“服务启动（注册）失败请款下，要求Consul通过HTTP方式对服务进行健康检查，检查结果是critical”。我对这个“失败”的想法是比较多的，比如：中间件、数据源访问不通，我也可以认为是失败。那情况不就复杂了吗?最开始的路线是通过一个事件（失败、异常事件）去触发：builder.down()。对，依然是要基于 <dependency> <groupId>org.springframe

猿Why在之前的一次面试中被问及一个问题：“你们的服务治理是怎么做的？”。当时猿Why还是Spring Cloud小白，工作中也还没有接触Spring Cloud系列的技术栈，面试结果也就可想而知了。 目前在做的项目，使用Spring Cloud 技术栈。确实感到服务治理（服务注册、服务发现、服务下线）是一列重要的事情。线上服务出现问题后能快速排查故障服务节点；服务不可用在被用户感知之前，如何通过预警的手段，排除故障。如果对使用的服务注册中心服务不了解的化，是很难快速定位解决问题滴。 出于“对技术的热.