SideWipe’s Blog

详解springboot自动装配原理

2020-07-04T00:00:00+08:00

springboot自动装配原理

引述

在SpringBoot项目中，无需各种配置文件，一个main方法，就能把项目启动起来，离不开一个重要的功能–自动装配，这也是springboot和springmvc最大的不同之处。

说到自动装配的原理，springboot启动类的注解@SpringBootApplication是一个组合注解，其中包含了三个重要注解：

@SpringBootConfiguration：这个注解的底层是一个@Configuration注解，被@Configuration注解修饰的类是一个IOC容器，支持JavaConfig的方式来进行配置；
@ComponentScan：这个就是扫描注解的意思，默认扫描当前类所在的包及其子包下包含的注解，将@Controller/@Service/@Component/@Repository等注解加载到IOC容器中；
@EnableAutoConfiguration：这个注解表明启动自动装配，里面包含连个比较重要的注解@AutoConfigurationPackage和@Import。

这里重点分析@EnableAutoConfiguration，这也是自动装配的核心注解。

@EnableAutoConfiguration注解原理

点击进入 @EnableAutoConfiguration注解，可以看到如下图所示，重点是AutoConfigurationImportSelector这个类，@import注解会在刷新容器时解析，并将import的类实例化注册到spring容器。

AutoConfigurationImportSelecto实现了ImportSelector接口的selectImports方法，重点逻辑也在此方法中（如果要知道具体怎么实现的，需要看spring源码细节，在此不详细讨论），依次按照下图顺序点击进入核心方法：

重点来了，classLoader.getResources(FACTORIES_RESOURCE_LOCATION)，这句代码很显然是加载某个资源文件夹下面的数据，这个路径是：

@EnableAutoConfiguration就是利用SpringFactoriesLoader机制加载自动装配配置的，它的配置数据在META-INF/spring.factories中，我们打开spring-boot-autoconfigure jar中的该文件，发现EnableAutoConfiguration对应着N多XXXAutoConfiguration配置类，我们截取几个重要的配置类如下(已经删除了很多)

可以看到Spring Boot提供了N多XXXAutoConfiguration类，有Spring Framework的、Web的、redis的、JDBC的等等。这些类都会在容器启动时，通过自动装配注解，解析并注册到spring容器，这样我们只需要简单的在yml中配置一下就可以直接使用了。

此外，@EnableAutoConfiguration注解会在容器启动时，扫描所有jar包下的META-INF/spring.factories，具体有什么用，接着往下看。

基于spring.factories的扩展机制

SpringFactoriesLoader机制加载自动装配也是spring集成第三方框架的一种方式，拿spring集成dubbo这个框架举例，我们在导入jar包后，只需要在yml文件中做如下配置即可

原理是什么呢？

来到dubbo的源码包下，会发现在META-INF目录下也有一个spring.factories文件，截图如下：

这里也有一个对EnableAutoConfiguration的配置，这是spring自定义的SPI服务。通过实现自动装配注解，在容器启动，解析启动类@EnableAutoConfiguration注解时，所有jar包下META-INF/spring.factories目录配置为EnableAutoConfiguration的类，都会被解析并注册到spring容器。

注册到spring容器后，下一个问题就是怎么自动读取我们yml文件的配置？

还是以dubbo为例，我们点击进入spring.factories配置为EnableAutoConfiguration的类–DubboAutoConfiguration，如图：

上图标识的就是开启获取文件属性注解，点击进入

@ConfigurationProperties(DUBBO_PREFIX)这句注解就是把yml文件中，以dubbo为前缀的配置项，都映射到本类的实例化对象对应的属性中，同时在这里可以看到所有的可配置项。
也就是说，在自动装配阶段，通过spring.factories配置，会随着容器启动解析dubbo框架中的自动装配类；这个类中会包含读取yml的逻辑。

总结
Spring Boot自动装配的原理并不是非常复杂，其实背后的主要原理就是条件注解。
当我们使用@EnableAutoConfiguration注解激活自动装配时，实质对应着很多XXXAutoConfiguration类在执行装配工作，这些XXXAutoConfiguration类是在spring-boot-autoconfigure jar中的META-INF/spring.factories文件中配置好的，@EnableAutoConfiguration通过SpringFactoriesLoader机制创建XXXAutoConfiguration这些bean。XXXAutoConfiguration的bean会依次执行并判断是否需要创建对应的bean注入到Spring容器中，在注册过程中会通过ConfigurationProperties注解，去读取yml文件中所需要的固定前缀的配置。
在每个XXXAutoConfiguration类中，都会利用多种类型的条件注解@ConditionOnXXX对当前的应用环境做判断，如应用程序是否为Web应用、classpath路径上是否包含对应的类、Spring容器中是否已经包含了对应类型的bean。如果判断条件都成立，XXXAutoConfiguration就会认为需要向Spring容器中注入这个bean，否则就忽略。

补充：基于aop的扩展机制

springboot除了使用上述的这种扩展方式来集成很多第三方框架以外，还可以利用aop的方式来集成框架，比如常见的事务框架，线程池，Eureka等，只需要在配置类上面加@EnableTransactionManagement，@EnableAsync，@EnableEurekaServer启动注解，然后在对应方法上加上@Transactional，@Async注解即可使用（注意，事务框架比较特殊，它依赖于Aspectj，使用@EnableTransactionManagement注一定要加上@EnableAspectJAutoProxy）。

这种集成方式基于aop的方式扩展，在容器启动时，对切入点创建动态代理。拿@EnableAsync注解举例；@EnableAsync使用了这种方式，注解源码如下：

EnableAsync注解中导入了AsyncConfigurationSelector，AsyncConfigurationSelector通过条件来选择需要导入的配置类，继承AdviceModeImportSelector又实现了ImportSelector接口，接口重写selectImports方法进行事先条件判断PROXY或者ASPECTJ选择不同的配置类。

参考链接：https://blog.csdn.net/m0_37595954/article/details/102720626

SpringCloud之sentinel(二)

2020-06-15T00:00:00+08:00

sentinel规则持久化

引述

在springcloud之sentinel(一)中，说明了sentinel的用法。文章链接：https://side-wipe.github.io/2020/06/13/sentinel/

同时，也留下了一个问题，就是在服务重启或者sentinel-dashboard重启是，规则会丢失，那么sentinel规则如何持久化？本篇博客也是建立在上一篇博客的基础之上。

本篇就将介绍：通过修改sentinel-dashboard源码，结合nacos注册中心对sentinel规则进行持久化。

sentinel持久化

1.修改sentinel-dashboard源码

修改后的源码已上传github，文章只能截图部分代码，请务必参照github上面的源码，地址链接： https://github.com/side-wipe/sentinelSourceCode

首先下载源码

我下载的是1.6.3版本，地址链接：https://github.com/alibaba/Sentinel/releases/tag/1.6.3

然后使用idea导入工作空间。

主要修改的代码在sentinel-dashboard子项目中。

修改推送/拉取源代码

首先确定修改的位置在哪里。其实Alibaba在源码中已经留了缺口供持久化使用，也写了相应的例子，只不过都放在springboot项目的test文件夹下，如图：

图中分别对应sentinel利用apollo，nacos，zookeeper三种注册中心进行持久化的代码，因此只需要依葫芦画瓢即可；先将nacos文件夹复制到发布目录的rule文件夹下。

修改pom文件中的依赖权限，默认的是只在test时生效

修改NacosConfig文件中的nacosConfigService方法，这个方法定义了sentinel将规则发送到注册中心的地址，因为我将注册中心部署到linux环境。

关键代码如下：

拉取配置

 /**
  * @author sidewipe
  * @desc 向nacos注册中心拉取配置规则
  */
 @Component("flowRuleNacosProvider")
 public class FlowRuleNacosProvider implements DynamicRuleProvider<List<FlowRuleEntity>> {
	
     @Autowired
     private ConfigService configService;    
	
     @Autowired
     private Converter<String, List<FlowRuleEntity>> converter;      //格式转换
	
     @Override
     public List<FlowRuleEntity> getRules(String appName) throws Exception {
         String rules = configService.getConfig(appName + NacosConfigUtil.FLOW_DATA_ID_POSTFIX,
             NacosConfigUtil.GROUP_ID, 3000);      //获取配置
         if (StringUtil.isEmpty(rules)) {
             return new ArrayList<>();
         }
         return converter.convert(rules);  //拉取的规则是一个json String，用转换器转化为List<FlowRuleEntity>
	

     }
 }

2.推送配置

	/**
	 * @author sidewipe
	 * @desc 推送配置规则到nacos配置中心
	 */
	@Component("flowRuleNacosPublisher")
	public class FlowRuleNacosPublisher implements DynamicRulePublisher<List<FlowRuleEntity>> {
	
	    @Autowired
	    private ConfigService configService;
	    @Autowired
	    private Converter<List<FlowRuleEntity>, String> converter;  //转换器，将规则转换为json String类型方便推送到nacos配置中心
	
	    @Override
	    public void publish(String app, List<FlowRuleEntity> rules) throws Exception {
	        AssertUtil.notEmpty(app, "app name cannot be empty");
	        if (rules == null) {
	            return;
	        }
	        configService.publishConfig(app + NacosConfigUtil.FLOW_DATA_ID_POSTFIX,
	            NacosConfigUtil.GROUP_ID, converter.convert(rules));  推送配置
	    }
	}

至此，推送和拉取部分的代码就改的差不多了，其实就是把本是放在test文件夹中的几个文件复制出来，然后改一下注册中心地址就可以了，没有什么需要改的东西。但是这些代码需要在controller层调用，这样才能将sentinel的规则推送到配置中心，接下来就要去controller包中改代码。

修改controller

首先看一张图：

图中标识的各种限流的controller，需要使用上面我们写的推送/拉取方式，因此都需要修改，这里以修改FlowControllerV1.class为例。

1.注入上一步新建的两个工具类，取代sentinelApiClient：

2.重新写一个publishRules()推送规则方法

3.然后将所有调用原本publishRules()的地方改为调用新的方法，举例如下：

4.修改拉取规则的方法，改为从nacos配置中心拉取

修改完成！

2.sentinel-pro工程修改

修改自己的springcloud工程，工程链接：https://github.com/side-wipe/sentinel-pro

只需要修改yml配置文件，为sentinel添加数据源，数据源就是nacos注册中心的地址，这样就使得项目会去nacos注册中心拉取sentinel配置规则，修改如图：

3.测试

修改完成后，可以在本地启动springboot项目进行测试；我在测试完之后，将sentinel-dashboard源码打成jar包（sentinel-dashboard.jar），重新部署在linux中，上面图示的配置地址都是我的linux服务器地址。

上传到linux服务器，输入

nohup java -Dserver.port=8888 -Dcsp.sentinel.dashboard.server=localhost:8888 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar &   

启动后，启动sentinel-pro工程的订单中心（order-center）和产品中心（product-center），和上一篇博客步骤一致；接着，在sentinel-dashboard添加限流规则：

然后去nacos配置中心会发现一个新的配置文件，点击详情，可以看到我们配置的阈值参数：

此时，就表示，流控规则已经推送到配置中心了；连续访问页面http://localhost:8082/selectOrderInfoById/1发现被限流了；并且重启服务，限流规则也不会消失，完成任务。

4.补充说明

对限流，热点参数，降级等都是一样的修改方式，本文叙述只是拿限流举例；我在修改源码时，也同时修改了其他的几种限流降级等策略，并对拉取和推送方法进行了封装，具体完整版参考我的github： https://github.com/side-wipe/sentinelSourceCode

SpringCloud之sentinel(一)

2020-06-13T00:00:00+08:00

springcloud中的流量哨兵sentinel

sentinel简介

在springcloud开发中，针对高并发系统经常会有限流降级的需求；提到限流降级，最常见的是netflix的hystrix和Alibaba的sentinel，sentinel相比hystrix功能更加强大，比如它可以将流控粒度细化控制到某一个具体接口甚至是接口传过来的具体数值（热点数据）；但是sentinel也有一定的缺点，就是不能持久化，关于如何解决持久化问题，参考我的另一篇博客，SpringCloud之sentinel(二)；链接：https://side-wipe.github.io/2020/06/15/sentinel/。

本篇就将介绍sentinel基本用法。

sentinel基本用法

1.环境准备

需要准备三个东西，springcloud的注册中心nacos，数据库mysql，以及sentinel-dashboard。
简单说一下sentinel-dashboard，这是一个Alibaba开源的项目，简单说就是一个springboot工程（jar包），安装启动后做为一个sentinel控制台使用，我们想进行流控的微服务工程也同样要注册到这个控制台，可以通过这个控制台来配置你想要的流控降级规则。
这三个东西我都是配置在linux环境下，也可以配置在windows环境下，具体相关配置操作百度即可，都比较简单就不在这里详细说了。需要的工具包（nacos和sentinel-dashboard）以及sql文件在我的github项目目录下（https://github.com/side-wipe/sentinel-pro/tree/master/tools），可自行下载。

2.使用示例

这里我们结合feign来进行使用，完整代码已上传github；地址：https://github.com/side-wipe/sentinel-pro/

项目结构简单说明：

如上所示：根据springcloud的架构习惯，common工程中都是一些项目通用的实体类；mapper-dao就是将调用mysql的dao层作为一个工程；feign-api工程就是所有feign调用的接口；这三个子工程都是给其他工程依赖的，无需启动。
建立两个微服务，order-center(订单服务)，product-center(产品服务)；模拟订单服务通过feign调用产品服务，并对订单服务就行限流降级控制。

核心代码除了基础的配置外（数据源，注册中心等），还需要sentinel的配置；既然是对订单服务进行配置，就要在订单服务的yml文件中配置sentinel，如下图：
需要注意的是，sentinel要配置两个端口，一个端口是微服务用来注册到sentinel控制台，一个是用于微服务和控制台通信

配置完成后，接下来只需要对feign-api的api接口进行改造就可以了；可以看到，这种方式对业务代码入侵非常低。

@FeignClient(name = "product-center",fallbackFactory = ProductCenterFeignApiWithSentielFallbackFactory.class)
public interface ProductCenterFeignApiWithSentinel {

    /**
     * 声明式接口,远程调用http://product-center/selectProductInfoById/{productNo}
     * @param productNo
     * @return
     */
    @RequestMapping("/selectProductInfoById/{productNo}")
    ProductInfo selectProductInfoById(@PathVariable("productNo") String productNo);

}

ProductCenterFeignApiWithSentielFallbackFactory是sentinel包中提供给我们的一个回调接口。可通过实现此接口，当/selectProductInfoById/{productNo}路径被限流处理时，返回的异常可以在回调函数中处理。

@Component
@Slf4j
public class ProductCenterFeignApiWithSentielFallbackFactory implements FallbackFactory<ProductCenterFeignApiWithSentinel> {
    @Override
	//可以在这里捕获返回的异常，限流和降级的异常是不一样的，可以在这里区分。
    public ProductCenterFeignApiWithSentinel create(Throwable throwable) {  
        return new ProductCenterFeignApiWithSentinel(){  


            @Override
            public ProductInfo selectProductInfoById(String productNo) {
                ProductInfo productInfo = new ProductInfo();
                if (throwable instanceof FlowException){
                    productInfo.setProductName("我是限流的默认商品");
                }
                else {
                    productInfo.setProductName("我是降级的默认商品");

                }
                return productInfo;
            }
        };
    }
}

完整的代码请到github下载。

3.效果展示

启动工程

首先启动nacos和sentinel-dashboard（这两个我已经在linux环境下配置好了），启动后截图如下：

这里我用nginx和nacos在linux下配置了一个注册中心集群，一共三个节点（配置方式可参考我的另一篇博客），此时微服务工程未启动，可以看到服务列表为空。

nacos控制台：

sentinel控制台：

linux环境下，下载sentinel-dashboard-1.6.3.jar后，输入

nohup java -Dserver.port=8888 -Dcsp.sentinel.dashboard.server=localhost:8888 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.6.3.jar  

即可，注意替换成自己的机器ip和端口

启动订单微服务和产品微服务，此时的nacos注册中心：

此时的sentinel控制台：

（注意：可能启动后还是没有，用浏览器或者postman调用一次接口就有了）

访问订单服务：

添加限流规则

针对order-center进行流控：配置规则为，每秒只允许一个访问通过，其他的都会进行拦截。

规则配置完成，再次访问，并不断刷新页面，会出现如图所示：

可以看到，发生了限流提示，而这个提示正是我们在feign-api工程中处理的，可以debug看一下：

同样的，如果在sentinel控制台设置降级规则，则会返回降级异常，根据我们的处理，返回的参数也有所不同。

当然，sentinel的可配置规则不仅限于此，还有很多强大的功能，这里就不一一展示；但是也有一个问题，前文也说到了，就是不能持久化，通俗的说，就是无论你的控制台重启还是项目重启，在控制台配置的规则都会全部丢失，这显然是一个很大的问题，下一篇文章将会简述如何持久化。

SpringCloud之ribbon

2020-06-11T00:00:00+08:00

springcloud中负载均衡工具ribbon用法及原理

1.ribbon用法

在这里我使用restTemplate和ribbon结合使用为例，前提是服务到注册到同一注册中心，本例使用的是nacos。

基本用法

一般情况下，我们使用restTemplate做服务调用，代码如下：

  ResponseEntity<ProductInfo> responseEntity= restTemplate.getForEntity(uri+orderInfo.getProductNo(), ProductInfo.class);

  ProductInfo productInfo = responseEntity.getBody();

  if(productInfo == null) {
 	   return "无数据";
  } 

当调用的服务有多个实例，需要做负载均衡是，则引入了ribbon，使用如下：

使用@LoadBalnaced注解，那么返回的restTemplate注解就是一个具有负载算法的对象；在调用服务时，会从注册中心获取被调用方的所有可调用实例列表，并依据负载均衡算法进行服务调用。

如果需要指定负载均衡算法，则在配置类中返回一个实现IRule接口的负载算法对象即可：

问题：那么ribbon是怎么让restTemplate具有负载均衡功能的呢？后面再分析原理

进阶用法

在一些业务场景中，我们希望对不同的微服务集群使用不同的负载均衡算法，甚至某些服务集群使用自定义的负载均衡算法。比如：我对订单服务集群使用轮询负载算法，对付费服务集群使用随机负载算法，对积分服务集群使用自定义的权重负载算法，这时我们有两种方式可以实现：

基于yml文件配置的方法（推荐的方式）：通过yml配置的方式，对不同的微服务集群采用不同的负载算法，ribbon中自带的负载算法均是实现IRule接口。

IRule接口是一个ribbon-balancer包下的一个上层接口，大致结构如下，使用的是模板方法模式，其实现类实现了不同的负载均衡算法：

类图如下：

我们可以基于此接口实现自己的负载均衡算法：如下：

自定义负载算法类：TulingWeightedRule.class （自定义实现权重算法：nacos注册中心可以给集群中的实例设置权重）

package com.tuling.myrule;

import com.alibaba.cloud.nacos.NacosDiscoveryProperties;
import com.alibaba.cloud.nacos.ribbon.NacosServer;
import com.alibaba.nacos.api.exception.NacosException;
import com.alibaba.nacos.api.naming.NamingService;
import com.alibaba.nacos.api.naming.pojo.Instance;
import com.netflix.client.config.IClientConfig;
import com.netflix.loadbalancer.AbstractLoadBalancerRule;
import com.netflix.loadbalancer.BaseLoadBalancer;
import com.netflix.loadbalancer.Server;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;

/**
 */
@Slf4j
public class TulingWeightedRule extends AbstractLoadBalancerRule {

    @Autowired
    private NacosDiscoveryProperties discoveryProperties;

    @Override
    public void initWithNiwsConfig(IClientConfig clientConfig) {
        //读取配置文件并且初始化,ribbon内部的 几乎用不上
    }


    @Override
    public Server choose(Object key) {
        try {
            log.info("key:{}",key);
            BaseLoadBalancer baseLoadBalancer = (BaseLoadBalancer) this.getLoadBalancer();
            log.info("baseLoadBalancer--->:{}",baseLoadBalancer);

            //获取微服务的名称
            String serviceName = baseLoadBalancer.getName();

            //获取Nocas服务发现的相关组件API
            NamingService namingService =  discoveryProperties.namingServiceInstance();

            //获取 一个基于nacos client 实现权重的负载均衡算法
            Instance instance = namingService.selectOneHealthyInstance(serviceName);

            //返回一个server
            return new NacosServer(instance);
        } catch (NacosException e) {
            log.error("自定义负载均衡算法错误");
        }
        return null;
    }
}

在yml配置中只需要指定对应的配置算法包位置即可，如下图所示：

这种配置方式不需要再添加其他的java代码，是最常用也是推荐的方式。

在真实开发中一般我们会使用feign代替restTemplate+ribbon，feign是对ribbon的封装，针对feign调用配置负载均衡算法，其实也是对ribbon的配置，配置方法和上图一致

通过javaConfig的方式配置定义负载算法的配置类：跟基础用法的原理一样，通过配置类向容器中加入实现IRule接口的负载算法即可。

这种方式需要增加一个配置类。并使用@RibbonClients注解，代码如下：

	package com.tuling.config; 
	import org.springframework.cloud.client.loadbalancer.LoadBalanced;
	import org.springframework.context.annotation.Bean;`
	import org.springframework.context.annotation.Configuration;
	import org.springframework.web.client.RestTemplate;


	@Configuration
	public class WebConfig {
	
	@LoadBalanced
	@Bean
	public RestTemplate restTemplate( ) {
		return new RestTemplate();
		}
	} 

负载算法配置总类：

package com.tuling.config;

import com.ribbonconfig.GlobalRibbonConfig;
import com.ribbonconfig.PayCenterRibbonConfig;
import com.ribbonconfig.ProductCenterRibbonConfig;
import org.springframework.cloud.netflix.ribbon.RibbonClient;
import org.springframework.cloud.netflix.ribbon.RibbonClients;
import org.springframework.context.annotation.Configuration;


@Configuration
@RibbonClients(
   		defaultConfiguration = GlobalRibbonConfig.class, 	//全局默认算法
value = {
    @RibbonClient(name = "product-center",configuration ProductCenterRibbonConfig.class),    //服务集群product-center使用的负载算法
    @RibbonClient(name = "pay-center",configuration = PayCenterRibbonConfig.class) //服务集群pay-center使用的负载算法
})

public class CustomRibbonConfig {

}

服务集群product-center对应的算法配置：ProductCenterRibbonConfig.class:

package com.ribbonconfig;

import com.netflix.loadbalancer.IRule;
import com.netflix.loadbalancer.RandomRule;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ProductCenterRibbonConfig {

	@Bean
	public IRule randomRule() {
		return new RandomRule();
	}
}

服务集群pay-center对应的算法配置：PayCenterRibbonConfig.class:

package com.ribbonconfig;

import com.netflix.loadbalancer.IRule;
import com.netflix.loadbalancer.RoundRobinRule;
import org.springframework.context.annotation.Configuration;


@Configuration
public class PayCenterRibbonConfig {

    public IRule roundRobinRule() {
        return new RoundRobinRule();
    }
} 

全局默认使用自定义的负载算法（比如需要实现权重算法：nacos注册中心可以给集群中的实例设置权重）：

全局默认算法对应配置： GlobalRibbonConfig.class

package com.ribbonconfig;

import com.netflix.loadbalancer.IRule;
import com.tuling.myrule.TheSameClusterPriorityRule;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;


@Configuration
public class GlobalRibbonConfig {

    @Bean
    public IRule theSameClusterPriorityRule() {
        return new TulingWeightedRule();  //上文中自定义的负载算法	     
	}
}

综上，就通过javaConfig的方式，实现了指定负载均衡算法，并且可以指定使用自定义的负载算法。

2.ribbon的原理

先通过一个例子来说明，也可以理解为手写实现一个简单的ribbon嵌入到restTemplate中：

首先还是基础的restTemplate配置类：

package com.tuling.config;

import org.springframework.cloud.client.discovery.DiscoveryClient;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;


@Configuration
public class WebConfig {

    @Bean
    public RestTemplate restTemplate(DiscoveryClient discoveryClient) {
        return new TulingRestTemplate(discoveryClient);
    }
}

可以看到这次我不是直接返回一个springcloud包中的RestTemplate的实例，而是一个自定义的TulingRestTemplate，该类代码如下：

package com.tuling.config;

import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.client.discovery.DiscoveryClient;
import org.springframework.http.HttpMethod;
import org.springframework.http.client.ClientHttpRequest;
import org.springframework.http.client.ClientHttpResponse;
import org.springframework.lang.Nullable;
import org.springframework.util.Assert;
import org.springframework.web.client.*;

import java.io.IOException;
import java.net.URI;
import java.net.URISyntaxException;
import java.util.List;
import java.util.Random;

/**
 * 根据RestTemplate特性自己改造
 */
@Slf4j
public class TulingRestTemplate extends RestTemplate {

    private DiscoveryClient discoveryClient;

    public TulingRestTemplate (DiscoveryClient discoveryClient) {
        this.discoveryClient = discoveryClient;
    }

    protected <T> T doExecute(URI url, @Nullable HttpMethod method, @Nullable RequestCallback requestCallback,
                              @Nullable ResponseExtractor<T> responseExtractor) throws RestClientException {

        Assert.notNull(url, "URI is required");
        Assert.notNull(method, "HttpMethod is required");
        ClientHttpResponse response = null;
        try {

            log.info("请求的url路径为:{}",url);
            //把服务名 替换成我们的IP
            url = replaceUrl(url);

            log.info("替换后的路径:{}",url);

            ClientHttpRequest request = createRequest(url, method);
            if (requestCallback != null) {
                requestCallback.doWithRequest(request);
            }
            response = request.execute();
            handleResponse(url, method, response);
            return (responseExtractor != null ? responseExtractor.extractData(response) : null);
        }
        catch (IOException ex) {
            String resource = url.toString();
            String query = url.getRawQuery();
            resource = (query != null ? resource.substring(0, resource.indexOf('?')) : resource);
            throw new ResourceAccessException("I/O error on " + method.name() +
                    " request for \"" + resource + "\": " + ex.getMessage(), ex);
        } finally {
            if (response != null) {
                response.close();
            }
        }
    }


    /**
     * 方法实现说明:把微服务名称  去注册中心拉取对应IP进行调用
     * http://product-center/selectProductInfoById/1
     * @param url:请求的url
     * @return:
     * @exception:
     */
    private URI replaceUrl(URI url){

        //1:从URI中解析调用的调用的serviceName=product-center
        String serviceName = url.getHost();
        log.info("调用微服务的名称:{}",serviceName);

        //2:解析我们的请求路径 reqPath= /selectProductInfoById/1
        String reqPath = url.getPath();
        log.info("请求path:{}",reqPath);


        //通过微服务的名称去nacos服务端获取 对应的实例列表
        List<ServiceInstance> serviceInstanceList = discoveryClient.getInstances(serviceName);
        if(serviceInstanceList.isEmpty()) {
            throw new RuntimeException("没有可用的微服务实例列表:"+serviceName);
        }

        String serviceIp = chooseTargetIp(serviceInstanceList);

        String source = serviceIp+reqPath;
        try {
            return new URI(source);
        } catch (URISyntaxException e) {
            log.error("根据source:{}构建URI异常",source);
        }
        return url;
    }

    /**
     * 方法实现说明:从服务列表中 随机选举一个ip
     * @param serviceInstanceList 服务列表
     * @return: 调用的ip
     * @exception:
     */
    private String chooseTargetIp(List<ServiceInstance> serviceInstanceList) {
        //采取随机的获取一个
        Random random = new Random();
        Integer randomIndex = random.nextInt(serviceInstanceList.size());
        String serviceIp = serviceInstanceList.get(randomIndex).getUri().toString();
        log.info("随机选举的服务IP:{}",serviceIp);
        return serviceIp;
    }
    
}

代码很多，思路就是通过继承RestTemplate类，并复写doExecute方法（在RestTemplate源码中可以看到，所有的调用方法最后都会走doExecute方法）。

大体意思是在调用时，去拉取注册中心该服务的服务实例列表，然后通过random随机算法来选出一个服务实例来进行调用。这样就相当于对RestTemplate进行了一个扩展，让它在调用服务时，拥有了负载均衡的功能。

那么ribbon也是通过扩展restTemplate来实现负载均衡的。

跟踪源码可以看到，ribbon是通过在spring容器启动时，向restTemplate中加入interceptor拦截器的方式来为restTemplate添加负载均衡功能，截图如下：

大体的思想就是这样！

nginx安装配置

2020-03-06T00:00:00+08:00

linux下nginx安装并配置负载均衡

记一次linux下配置负载均衡踩坑，先把安装过程大致梳理一遍。

1.安装nginx

下载nginx

wget -c https://nginx.org/download/nginx-1.4.6.tar.gz wget命令下载到当前文件夹，如果没有wget命令，则使用yum install wget安装。
tar -zxvf nginx-1.4.6.tar.gz 解压下载的nginx压缩文件
安装nginx环境
./configure --prefix=/usr/local/nginx （此为你的nginx安装目录）使用默认configure文件配置nginx，如果没有部署好环境，此步骤一定会报错，（总之就是报错缺少什么就安装什么。）如下：

需要安装的依赖主要有：
yum install gcc-c++

yum install -y pcre pcre-devel

yum install -y zlib zlib-devel

yum install -y openssl openssl-devel

安装成功后，再次输入./configure --prefix=/usr/local/nginx即可配置成功

make && make install完成编译安装

2.配置nginx负载均衡

大概的负载均衡配置如下图：

注意：一开始我这样配置，没有任何问题，但是我在浏览器访问http://192.168.137.21:8847/nacos_cluster/nacos一直访问不了，报400错误，也google了很多办法，都没有解决。最终我把nacos_cluster的下划线改掉就好了，为什么呢？我用的nginx版本是1.4，可能由于源码的原因，无法解析带有下划线的地址（很坑），最终配置如下：

访问地址为http://192.168.137.21:8847/cluster/nacos

注意：修改配置后需要重新启动或者动态加载，具体如下：

nginx启动: ./sbin/nginx

nginx停止: ./sbin/nginx -s stop

nginx配置动态加载: ./sbin/nginx -s reload（在nginx运行时才能使用此命令）

CentOS7网络配置

2020-02-06T00:00:00+08:00

VMware虚拟机中，CentOS操作系统网络设置和问题解决

在VMware中装好CentOS7后，我们一开始是上不了网的

需要进行一些网络设置，具体如下：

1.设置VMware虚拟网络

把系统的IP设置为静态的，设置步骤如下：

点击VMware虚拟机左上角的“编辑”，选择“虚拟网络编译器”。
选中VMnet8（NAT模式），再点击右侧的“NAT设置”此时会看到如下界面：按照图中所示进行设置，子网ip为你的linux虚拟ip的网段

需要注意的是，虚拟机linux的ip地址，子网ip，网关ip，起始ip地址均要在同一网段。如图中，这些ip均在192.168.137.0，后面我会将IP地址设置为192.168.137.21

点击NAT设置，按照图中所示设置

点击DHCP设置

特别提醒：设置完之后要用命令service network restart重启网卡

2.进入centOS，设置虚拟机的IP地址

在操作系统中设置虚拟机的IP地址，网络配置

cd /etc/sysconfig/network-scripts/ 进入此目录下

特别提醒：如上图所示，箭头所指就是需要修改的网络配置文件。由于linux操作系统的版本问题，网络配置文件名字可能有所不同，可能是名为ifcfg-ens33，ifcfg-enth0等；在使用vi编辑该文件时，最好进到该目录下看下默认的文件是哪一个；直接vi编辑，如果该文件不存在，会自动创建一个新的空文件，那么你的配置写在新的文件中，系统读取的还是默认的文件，这样你的配置将无法生效。总之，保证在此目录下只有一个系统默认的文件是最稳妥的

输入 vi ifcfg-ens33 编辑文件，设置如下：

HDADDR为硬件地址，输入 ifconfig 指令可查询

附上常见网络设置问题解决方式（基本涵盖所有情况）：https://blog.csdn.net/yyy987456123/article/details/97142858

Java对象头

2020-02-04T00:00:00+08:00

Java对象由什么组成？java对象的内存大小怎么计算？对象头是什么东西？

首先来看一下对象的创建流程：

1.类加载检查

虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。
new指令对应到语言层面上讲是，new关键词、对象克隆、对象序列化等。

2.分配内存

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。

这个步骤有两个问题：

1.如何划分内存。
2.在并发情况下，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。

划分内存的方法：

“指针碰撞”（Bump the Pointer）：(默认用指针碰撞) 如果Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。
“空闲列表”（Free List）：如果Java堆中的内存并不是规整的，已使用的内存和空闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录

解决并发问题的方法：

CAS（compare and swap）虚拟机采用CAS配上失败重试的方式保证更新操作的原子性来对分配内存空间的动作进行同步处理。
本地线程分配缓冲（Thread Local Allocation Buffer,TLAB）把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存。通过XX:+/UseTLAB参数来设定虚拟机是否使用TLAB(JVM会默认开启XX:+UseTLAB)，XX:TLABSize 指定TLAB大小。

3.初始化

内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。

4.设置对象头

初始化零值之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头Object Header之中。 **在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。 **

如图：

对象头： Mark Word：包含一系列的标记位，比如轻量级锁的标记位，偏向锁标记位等等。在32位系统占4字节，在64位系统中占8字节； Class Pointer(类型指针)：用来指向对象对应的Class对象（其对应的元数据对象）的内存地址。在32位系统占4字节，在64位系统中占8字节（开启JVM指针压缩后占4字节）； Length：占4个字节（只有数组对象才有）；
实例数据（Instance Data）：如对象中定义的属性id，String等，字节长度根据字段类型长度进行累加。
对齐填充：如果上述两个区域加起来字节数不是8的整数倍，会进行追加填充字节到8的整数倍。

比如现在计算一个对象大小，对象中只有一个int成员属性占四个字节，那么在64位操作系统内存中创建一个该对象占几个字节？
1.首先计算对象头，成员属性int类型不是数组，对象头没有Length，所以对象头内存大小=8（MarkWork）+8(ClassPointer)=16 byte；
2.实例数据大小，即int成员属性大小=4 byte；
3.前面两个加起来内存大小=20 byte，不是8的整数倍，所以需要对齐填充至24 byte；
综上，该对象占内存大小为24字节。

HotSpot虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

5.执行方法

即对象按照程序员的意愿进行初始化。对应到语言层面上讲，就是为属性赋值（注意，这与上面的赋零值不同，这是由程序员赋的值），和执行构造方法。

Android Studio 遇到问题集锦

2018-12-05T00:00:00+08:00

打开 Android Studio 卡在「Fetching Android SDK component information」界面。

如图：

Android Studio First Run 检测 Android SDK 及更新，由于众所周知的原因，我们会「Unable to access Android SDK add-on list」，而且大家一般也已经提前配置好了 Android SDK，真正需要更新的时候手动去 SDK Manager 更新就好了。

解决方案：

在 Android Studio 安装目录 bin/idea.properties 文件最后追加一句

disable.android.first.run=true

参考： http://ask.android-studio.org/?/article/14

新建工程后构建时提示找不到 appcompat-v7

Error:Failed to find: com.android.support:appcompat-v7:22.+

解决方案：

打开 SDK Manager，然后安装 Extras 下的 Android Support Repository：
Rebuild 工程。

aidl 文件的放置

按以前 Eclipse 的方式，将 aidl 及其包目录层级放置在与自己的顶级包同级的目录下，即如下的 android/content/pm：

app/src/main
├─assets
├─java
│  ├─android
│  │  └─content
│  │      └─pm
│  └─org
│      └─mazhuang
│          └─easycleaner
└─res
   ├─drawable
   ├─layout
   ├─menu
   ...

然而这样在调用处一直报错：

Cannot resolve symbol 'IPackageStatsObserver'

解决方案：

将 aidl 文件放置在与 app/src/main/java 目录同级的 app/src/main/aidl 文件夹下。

app/src/main
├─aidl
│  └─android
│      └─content
│          └─pm
├─assets
├─java
│  └─org
│      └─mazhuang
│          └─easycleaner
└─res
   ├─drawable
   ├─layout
   ├─menu
   ...

在 Android Studio 里编译通过之后，命令行使用 gradlew build 为什么还是会重新下载 Gradle？

Gradle 的版本在 Android Studio 工程里有三处：

一、gradle/wrapper/gradle-wrapper.properties 文件的 distributionUrl 字段里指定的。

#Wed Oct 21 11:34:03 PDT 2015
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-2.8-all.zip

比如这里指定的是 2.8 版本。

二、Android Studio 的 File > Project Structure > Project 里显示的。

这个实际上就是显示的「一」里的版本。

三、Android Studio 的 File > Settings > Build, Execution, Deployment > Build Tools > Gradle 里选择的是「Use default gradle wrapper (recommended)」还是「Use local gradle distribution」。

出现题目里的问题一般是由于「三」中选择的是「Use local gradle distribution」，这个选项下的「Gradle home」路径一般是指向 Android Studio 安装目录下的 Gradle 目录，比如 C:/Program Files/Android/Android Studio/gradle/gradle-2.8，而 gradlew 脚本是独立于 Android Studio 的，所以并不受其配置的影响，它是使用「一」里指定的版本，会到 ~/.gradle/wrapper/dists 目录下去寻找对应版本的 Gradle 是否已经存在，如果没有话就会去重新下载。

模拟器启动失败

PANIC: ANDROID_SDK_HOME is defined but could not find Nexus_5_API_23.ini file in $ANDROID_SDK_HOME/.android/avd
(Note: avd is searched in the order of $ANDROID_AVD_HOME,$ANDROID_SDK_HOME/.android/avd and $HOME/.android/avd)

实际上文件存在于 $HOME/.android/avd 目录下，但看样子如果设置了 $ANDROID_SDK_HOME 环境变量，Android Studio 在 $ANDROID_SDK_HOME/.android/avd 下找不到模拟器文件将直接报错，而不会再去找 $HOME 目录下的文件。

解决方案：

添加 $ANDROID_AVD_HOME 环境变量，值为 $HOME/.android/avd 的展开全路径。

debug.keystore 的存放位置

在使用高德地图 SDK 时，需要 key 与 keystore 文件的 sha1 校验通过，而我将 debug.keystore 拷贝到 $HOME/.android 目录下后发现一直提示 key 校验失败，也就是没有使用我拷贝到 $HOME/.android 目录下的 debug.keystore 来做 debug 签名。

原因是 debug.keystore 的默认存储路径是 $HOME/.android，但是如果配置了 $ANDROID_SDK_HOME，则会将 debug.keystore $ANDROID_SDK_HOME/.android 目录下。

解决方案：

将 debug.keystore 文件拷贝到 $ANDROID_SDK_HOME/.android 目录下。

BTW:

关于给 App 签名的手动、自动方法参考 Signing Your Applications。

Android Studio 自动生成的 debug.keystore 的信息：

Keystore password: android
Key alias: androiddebugkey
Key password: android

SideWipe’s Blog

详解springboot自动装配原理

springboot自动装配原理

引述

@EnableAutoConfiguration注解原理

基于spring.factories的扩展机制

补充：基于aop的扩展机制

SpringCloud之sentinel(二)

sentinel规则持久化

引述

sentinel持久化

1.修改sentinel-dashboard源码

2.sentinel-pro工程修改

3.测试

4.补充说明

SpringCloud之sentinel(一)

springcloud中的流量哨兵sentinel

sentinel简介

sentinel基本用法

1.环境准备

2.使用示例

这里我们结合feign来进行使用，完整代码已上传github；地址：https://github.com/side-wipe/sentinel-pro/

3.效果展示

SpringCloud之ribbon

springcloud中负载均衡工具ribbon用法及原理

1.ribbon用法

基本用法

进阶用法

2.ribbon的原理

nginx安装配置

linux下nginx安装并配置负载均衡

1.安装nginx

下载nginx

安装nginx环境

2.配置nginx负载均衡

CentOS7网络配置

VMware虚拟机中，CentOS操作系统网络设置和问题解决

1.设置VMware虚拟网络

2.进入centOS，设置虚拟机的IP地址

附上常见网络设置问题解决方式（基本涵盖所有情况）：https://blog.csdn.net/yyy987456123/article/details/97142858

Java对象头

Java对象由什么组成？java对象的内存大小怎么计算？对象头是什么东西？

1.类加载检查

2.分配内存

这个步骤有两个问题：

3.初始化

4.设置对象头

5.执行方法

Android Studio 遇到问题集锦

打开 Android Studio 卡在「Fetching Android SDK component information」界面。

新建工程后构建时提示找不到 appcompat-v7

aidl 文件的放置

在 Android Studio 里编译通过之后，命令行使用 gradlew build 为什么还是会重新下载 Gradle？

模拟器启动失败

debug.keystore 的存放位置