知秋的博客

“不积跬步，无以至千里。”Controller中调用FeignClient 接口方法，经过动态代理机制，由FeignInvocationHandler 的invoke() 方法处理，转而交给SynchronousMethodHandler 的invoke() 方法处理，继续调用LoadBalancerFeignClient 的execute() 方法return lbClient(clientName).executeWithLoadBalancer(ribbonRequest, requestCo.

“不积跬步，无以至千里。”前面说了，FeignClientFactoryBean的getObject()方法返回的就是一个类型为FeignInvocationHandler的代理对象所有，一旦Controller 中调用feign接口的方法，实际调用的就是这个动态代理，有点尝试的都知道，对于动态代理对象的方法调用，都会经过其绑定的InvocationHandler 的invoke()方法来处理private final Map<Method, MethodHandler> dispat.

“不积跬步，无以至千里。”回顾一下，前面说了，把Feign.Builder、context、HardCodedTarget 一起传入了一个loadBalance()方法里面，最后给 return 了，这个 return 的就是feign client的代理对象，然后注入给Controller的属性这篇文章来着重分析一下 loadBalance() 方法protected <T> T loadBalance(Feign.Builder builder, FeignContext cont.

“不积跬步，无以至千里。”这一篇文章的话，就来看一下feign的动态代理是怎么生成的，生成的动态代理会被添加到容器中，在需要的时候被调用，实际上我们前面也说了，在Controller中自动注入的就是这里生成的动态代理对象，那么这个对象里面包含了什么组件？怎么读取application.yml中配置的跟feign相关的参数的？接着上篇的代码继续跟进，给Feign.Builder 注入一些组件（logger、encoder、decoder等）之后configureFeign(context, buil.

“不积跬步，无以至千里。”前面说了，@EnableFeignClients 这个注解往容器中导入了一个组件 FeignClientsRegistrar ，这个组件实现了 ImportBeanDefinitionRegistrar接口，那么它的 registerBeanDefinitions() 方法就会往spring容器中导入一些组件registerFeignClients(metadata, registry);这个方法会搞一个组件扫描器ClassPathScanningCandidateCom.

“不积跬步，无以至千里。”这篇文章，一起来看看feign的核心机制，看看是如何扫描所有包下的@FeignClient注解的接口入口就是这个registerFeignClients(metadata, registry)方法public void registerFeignClients(AnnotationMetadata metadata, BeanDefinitionRegistry registry) { ClassP.

“不积跬步，无以至千里。”之前我们讲了ribbon的核心源码，其实在实际生产环境中，国内用ribbon+restTemplate去做微服务调用的甚少，因为会导致我们每次去调用人家一个接口，都要单独写一些代码，非常不简洁，所以我们这一个专题开始，研究一下feign的底层核心源码。feign这个东西呢，底层也是依赖了ribbon做负载均衡的，所以是整合了ribbon的，feign的具体用法这里就不赘述了，相信来看这篇博文的，都是熟练使用的，技术，用，是很简单的，随便百度一下，csdn其他的文章，一搜一大.

“不积跬步，无以至千里。”上文写到，ribbon通过其内置的IRule组件，使用指定的负载均衡算法（默认轮询）从ILoadBalancer组件的server list中会拿到一个真正要发送请求的server地址，那么接下来，就会调用网络通信组件发起http请求了。@Overridepublic <T> T execute(String serviceId, ServiceInstance serviceInstance, LoadBalancerRequest<T> req.

“不积跬步，无以至千里。”之前我们看到了ribbon负载均衡组件里的服务列表实际上是从eureka client自己本地的缓存中获取的eureka client自己本身，是不断的去从eureka server每隔30秒更新一次注册表，拉取增量注册表所以ribbon和eureka整合的机制里，肯定得有一个组件，负责每隔一定的时间，从本地的eureka client里刷新一下服务的注册表到LoadBalancer中继续回到 DynamicServerListLoadBalancer 组件的 rest.

“不积跬步，无以至千里。”众所周知，在springcloud体系中，Ribbon组件的功能是充当了负载均衡的作用，那么具体完成这个工作的是其内部哪个组件？答案是ILoadBalancer。ILoadBalancer loadBalancer = getLoadBalancer(serviceId);Server server = getServer(loadBalancer);从这两行源码中也可以看出，每个被调服务都会对应一个ILoadBalancer而且里面会包含服务列表，这篇文章就来重.

“不积跬步，无以至千里。”接着上一篇文章，return this.loadBalancer.execute(serviceName, requestFactory.createRequest(request, body, execution));显然微服务调用的逻辑都在这个LoadBalancerClient组件的execute方法中，那么这个组件是从哪里来的@Beanpublic LoadBalancerInterceptor ribbonInterceptor( LoadBala.

“不积跬步，无以至千里。”这个专题开始，来深度刨析一下作为springcloud老牌的客户端负载均衡组件，Ribbon。在项目中需要使用Ribbon，只需要使用@LoadBalanced去标注一个RestTemplate的bean即可，后续就可以在Controller中注入一个RestTemplate，调用getForObject()之类的方法了@LoadBalanced@Beanpublic RestTemplate getRestTemplate() { return new Re.

“不积跬步，无以至千里。”使用在生产环境的eureka，一定没有人是“单机”的，那样的话，一个注册中心挂了，整个微服务都不可用了，当然你也别抬杠说eureka client会缓存本地注册表，再怎么说，注册中心它也是微服务集群正常工作的核心，重中之重作为eureka系列的最后一篇文章，就来探讨一下eureka的集群模式吧。首先就从eureka server的初始化看起，在EurekaBootStrap#initEurekaServerContext()中，有一块代码，是跟PeerEurekaNode.

“不积跬步，无以至千里。”eureka专题的第10篇文章，来聊聊eureka所谓的**“自我保护机制”**。提起eureka的自我保护机制，相信人人都能说两句，大概的意思，就是eureka在一段时间内，如果过期的服务实例过多，超多了一个比例，eureka server就会认为自己作为注册中心一定是网络发生了故障，导致接收不到客户端的心跳，这个时候就会进入一个保护模式，就不会再摘除任何服务实例了，然后静静地等待自己的网络恢复，巴拉巴拉… …大概就是这么个意思，这个保护机制，有些地方说生产环境建议开启.

“不积跬步，无以至千里。”如果是eureka client主要停机下线，可以去调用shutdown()方法这种优雅的方式将服务实例摘除，但实际生产中，我们开发人员一般不会主动去发送请求将服务实例下线，而是某个服务发生了故障宕机。那么eureka应对这种服务故障宕机的场景，就会采用故障检测机制进行感知，然后把故障实例摘除eureka靠什么感知故障？心跳。每个eureka client会定时向server端发送心跳，服务端记录对应服务及心跳发送时间，搞一个后台调度线程池去轮询，发现某个服务超过了一段.

“不积跬步，无以至千里。”这篇文章来看看Eureka中两个重要的核心机制：心跳续约与故障摘除。心跳续约，eureka client每隔一定时间，向server发送心跳，让eureka server知道自己还活着，还可以继续对外提供服务，简言之，就是如此。这个心跳是通过一个调度线程池实现的，根据之前的经验，跟client有关的功能，找DiscoveryClient这个类，准没错，把eureka源码读完之后，会发现，DiscoveryClient里面近2000行代码，几乎涵盖了client端的所以功.

“不积跬步，无以至千里。”之前说过，Eureka client第一次启动的时候，回去一次性全量拉取server端的注册表信息，缓存在本地，后续会通过一个定时调用的线程任务，每隔一定时间（默认30s），发动请求到server端，拉取增量的注册表。这个所谓的“增量”，其实是说，跟上一次拉取相比，后续有变动的服务实例，而不是每次都全部拉取下来。这个定时调度的线程池是通过DiscoveryClient构造方法中的一个initScheduledTasks()方法初始化的// finally, init t.

“不积跬步，无以至千里。”这篇文章内容比较短，可以开篇聊点题外话。前几天，跟朋友闲聊，谈起了国内的互联网局势，“开始内卷”，其实内卷倒不是什么坏事，这不也恰恰说明国内的IT界“上限”在提高嘛，整体有了增长的态势，这是幸事。但是作为一个普通的码农，学习肯定是要的，我也鼓励大家利用业务时间充充电，我就是这么做的，这是我的第一层观点，即“学习不能停”。至于怎么学习，这个得自己摸索，不过我个人的这些年的经验，可以简单跟大家分享分享，我早些年学技术，比较喜欢学习“新”技术，出了个什么新玩意，马上火急火燎的去.

“不积跬步，无以至千里。”Eureka client初始化的时候，就会自动发送个请求到Eureka server一次性抓取全量的注册表，这一篇文章，我们来看看Eureka server端是如何处理抓取全量注册表的请求的，首先我们知道，Eureka client发送的请求是类似：http://localhost:8080/v2/apps/，GET请求。server这一端，我们来到ApplicationsResource这个类，通过匹配url确定getContainers方法就是处理抓取全量注册表请求的.

“不积跬步，无以至千里。”Eureka client服务注册之后，需要从Server服务器那里拉取最新的注册表信息到本地存储起来，供后续的业务使用，这个服务注册表，我们之前也看过了，是一个ConcurrentHashMap数据结构，Key是服务名称，Value是一个Map，为什么是Map，这个好理解，一个服务，可以部署在多台机器上面，那么就会有多个实例信息，即InstanceInfo，所以Map的Key就是服务实例Id，Value就是服务实例信息，即InstanceInfo，只不过用Lease对象包了.

“不积跬步，无以至千里。”Eureka Client启动之后，第一件事情一定是找Eureka Server进行服务注册与注册表的抓取，这一篇文章重点分析一下Eureka Client服务注册的流程。Eureka Client这一块的代码架构设计方面做的不是特别好，为什么这么讲？？不是个人吹毛求疵，因为Eureka作为一个服务注册中心的一个组件，那么这个服务注册一定是最重要的一块机制，一定是要放在显眼的位置，便于阅读和故障调试，但是在Eureka的代码里，这块代码藏的比较深，甚至于命名都不太规范，以至.

“不积跬步，无以至千里。”说完了Eureka Server的启动，现在再来看看Eureka Client是怎么启动的。出发点是eureka-examples这个模块的一个Example类：ExampleEurekaClient。这个类相当于模拟了我们平时写的客户端程序，所以我们找到这个main()方法里的代码，启动流程的逻辑就在这个main()方法里；public static void main(String[] args) { ExampleEurekaClient sampleCl.

“不积跬步，无以至千里。”spring cloud eureka server和client是对netflix的eureka进行了封装，加了一些注解，对spring boot进行支持。所以上来如果你要看eureka的源码，是先从netflix eureka开始看起。netflix eureka的版本：1.7.2。eureka-client：eureka客户端代码模块eureka-core：eureka服务端代码模块，包括服务注册与发现，心跳，摘除故障服务实例功能eureka-resource.