文章大纲
一、Eureka中的核心概念
二、Spring RestTemplate详解
三、代码实战服务与负载均衡的客户端
四、项目源码与参考资料下载
五、参考文章
一、Eureka中的核心概念
1. 服务提供者
Eureka服务治理体系支持跨平台，虽然我们前文使用了Spring Boot来作为服务提供者，但是对于其他技术平台只要支持Eureka通信机制，一样也是可以作为服务提供者，换句话说，服务提供者既可以是Java写的，也可以是python写的，也可以是js写的。这些服务提供者将自己注册到Eureka上，供其它应用发现然后调用，这就是我们的服务提供者，服务提供者主要有如下一些功能：
1.1 服务注册
服务提供者在启动的时候会通过发送REST请求将自己注册到Eureka Server上，同时还携带了自身服务的一些元数据信息。Eureka Server在接收到这个REST请求之后，将元数据信息存储在一个双层结构的Map集合中，第一层的key是服务名，第二层的key是具体服务的实例名，我们在上篇文章最后展示出来的截图中，大家也可以看出一些端倪，如下：
同时，我们在服务注册时，需要确认一下eureka.client.register-with-eureka=true配置是否正确，该值默认就为true，表示启动注册操作，如果设置为false则不会启动注册操作。比如第一天中eureka_server需要设置为false，eureka_provider需要设置为true.
1.2 服务同步
再说服务同步之前，我先描述一个场景：首先我有两个服务注册中心，地址分别是http://localhost:1111和http://localhost:1112，然后我还有两个服务提供者，地址分别是http://localhost:8080和http://localhost:8081，然后我将8080这个服务提供者注册到1111这个注册中心上去，将8081这个服务提供者注册到1112这个注册中心上去，此时我在服务消费者中如果只向1111这个注册中心去查找服务提供者，那么是不是只能获取到8080这个服务而获取不到8081这个服务？大家看下面一张图：
答案是服务消费者可以获取到两个服务提供者提供的服务。虽然两个服务提供者的信息分别被两个服务注册中心所维护，但是由于服务注册中心之间也互相注册为服务，当服务提供者发送请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步，通过服务同步，两个服务提供者的服务信息我们就可以通过任意一台注册中心来获取到。所以在第一天学习中，我们已经将服务提供者注册到两个服务注册中心了，在下面代码实战中，我们会将两个服务提供者注册到高可用服务注册中心，以实现服务同步。
1.3 服务续约
在注册完服务之后，服务提供者会维护一个心跳来不停的告诉Eureka Server：“我还在运行”，以防止Eureka Server将该服务实例从服务列表中剔除，这个动作称之为服务续约，和服务续约相关的属性有两个，如下：
eureka.instance.lease-expiration-duration-in-seconds=90
eureka.instance.lease-renewal-interval-in-seconds=30
第一个配置用来定义服务失效时间，默认为90秒，第二个用来定义服务续约的间隔时间，默认为30秒。
2. 服务消费者
消费者主要是从服务注册中心获取服务列表，拿到服务提供者的列表之后，服务消费者就知道去哪里调用它所需要的服务了，我们从下面几点来进一步了解下服务消费者。
2.1 获取服务
当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心来获取服务注册中心上面的服务提供者列表，而Eureka Server上则会维护一份只读的服务清单来返回给客户端，这个服务清单并不是实时数据，而是一份缓存数据，默认30秒更新一次，如果想要修改清单更新的时间间隔，可以通过eureka.client.registry-fetch-interval-seconds=30来修改，单位为秒(注意这个修改是在eureka-server上来修改)。另一方面，我们的服务消费端要确保具有获取服务提供者的能力，此时要确保eureka.client.fetch-registry=true这个配置为true。
2.2 服务调用
服务消费者从服务注册中心拿到服务提供者列表之后，通过服务名就可以获取具体提供服务的实例名和该实例的元数据信息，客户端将根据这些信息来决定调用哪个实例，我们之前采用了Ribbon，Ribbon中默认采用轮询的方式去调用服务提供者，进而实现了客户端的负载均衡。
2.3 服务下线
服务提供者在运行的过程中可能会发生关闭或者重启，当服务进行正常关闭时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心我要下线了，服务注册中心收到请求之后，将该服务状态置为DOWN，表示服务已下线，并将该事件传播出去，这样就可以避免服务消费者调用了一个已经下线的服务提供者了。
2.4 服务注册中心
服务注册中心就是Eureka提供的服务端，它提供了服务注册与发现功能。
2.5 失效剔除
上面我们说到了服务下线问题，正常的服务下线发生流程有一个前提那就是服务正常关闭,但是在实际运行中服务有可能没有正常关闭，比如系统故障、网络故障等原因导致服务提供者非正常下线，那么这个时候对于已经下线的服务Eureka采用了定时清除：Eureka Server在启动的时候会创建一个定时任务，每隔60秒就去将当前服务提供者列表中超过90秒还没续约的服务剔除出去，通过这种方式来避免服务消费者调用了一个无效的服务。
2.6 自我保护
我们在实际操作中，可能会遇到一个这样的警告，如下图：
这个警告实际上就是触发了Eureka Server的自我保护机制。Eureka Server在运行期间会去统计心跳失败比例在15分钟之内是否低于85%，如果低于85%，Eureka Server会将这些实例保护起来，让这些实例不会过期，但是在保护期内如果服务刚好这个服务提供者非正常下线了，此时服务消费者就会拿到一个无效的服务实例，此时会调用失败，对于这个问题需要服务消费者端要有一些容错机制，如重试，断路器等。我们在单机测试的时候很容易满足心跳失败比例在15分钟之内低于85%，这个时候就会触发Eureka的保护机制，一旦开启了保护机制，则服务注册中心维护的服务实例就不是那么准确了，此时我们可以使用eureka.server.enable-self-preservation=false来关闭保护机制，这样可以确保注册中心中不可用的实例被及时的剔除。
3. 服务端与客户端负载均衡
3.1 服务端负载均衡
负载均衡是我们处理高并发、缓解网络压力和进行服务端扩容的重要手段之一，但是一般情况下我们所说的负载均衡通常都是指服务端负载均衡，服务端负载均衡又分为两种，一种是硬件负载均衡，还有一种是软件负载均衡。
硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，常见的如F5。
软件负载均衡则主要是在服务器上安装一些具有负载均衡功能的软件来完成请求分发进而实现负载均衡，常见的就是Nginx。
无论是硬件负载均衡还是软件负载均衡，它的工作原理都不外乎下面这张图：
3.2 客户端负载均衡
我们在Spring Cloud中服务的发现与消费一文中涉及到了客户端负载均衡，在那篇文章中我们提到
“Ribbo是一个基于HTTP和TCP的客户端负载均衡器，当我们将Ribbon和Eureka一起使用时，Ribbon会从Eureka注册中心去获取服务端列表，然后进行轮询访问以到达负载均衡的作用，客户端负载均衡中也需要心跳机制去维护服务端清单的有效性，当然这个过程需要配合服务注册中心一起完成。”
从上面的描述我们可以看出，客户端负载均衡和服务端负载均衡最大的区别在于服务清单所存储的位置。在客户端负载均衡中，所有的客户端节点都有一份自己要访问的服务端清单，这些清单统统都是从Eureka服务注册中心获取的。在Spring Cloud中我们如果想要使用客户端负载均衡，方法很简单，开启@LoadBalanced注解即可，这样客户端在发起请求的时候会先自行选择一个服务端，向该服务端发起请求，从而实现负载均衡。具体小伙伴们可以参考Spring Cloud中服务的发现与消费这篇文章。
4. 负载均衡策略
4.1 IRule
这是所有负载均衡策略的父接口，里边的核心方法就是choose方法，用来选择一个服务实例。
4.2 AbstractLoadBalancerRule
AbstractLoadBalancerRule是一个抽象类，里边主要定义了一个ILoadBalancer，就是我们上文所说的负载均衡器，负载均衡器的功能我们在上文已经说的很详细了，这里就不再赘述，这里定义它的目的主要是辅助负责均衡策略选取合适的服务端实例。
4.3 RandomRule
看名字就知道，这种负载均衡策略就是随机选择一个服务实例，看源码我们知道，在RandomRule的无参构造方法中初始化了一个Random对象，然后在它重写的choose方法又调用了choose(ILoadBalancer lb, Object key)这个重载的choose方法，在这个重载的choose方法中，每次利用random对象生成一个不大于服务实例总数的随机数，并将该数作为下标所以获取一个服务实例。
4.4 RoundRobinRule
RoundRobinRule这种负载均衡策略叫做线性负载均衡策略，也就是我们在上文所说的BaseLoadBalancer负载均衡器中默认采用的负载均衡策略。这个类的choose(ILoadBalancer lb, Object key)函数整体逻辑是这样的：开启一个计数器count，在while循环中遍历服务清单，获取清单之前先通过incrementAndGetModulo方法获取一个下标，这个下标是一个不断自增长的数先加1然后和服务清单总数取模之后获取到的（所以这个下标从来不会越界），拿着下标再去服务清单列表中取服务，每次循环计数器都会加1，如果连续10次都没有取到服务，则会报一个警告No available alive servers after 10 tries from load balancer: XXXX。
4.5 RetryRule
看名字就知道这种负载均衡策略带有重试功能。首先RetryRule中又定义了一个subRule，它的实现类是RoundRobinRule，然后在RetryRule的choose(ILoadBalancer lb, Object key)方法中，每次还是采用RoundRobinRule中的choose规则来选择一个服务实例，如果选到的实例正常就返回，如果选择的服务实例为null或者已经失效，则在失效时间deadline之前不断的进行重试（重试时获取服务的策略还是RoundRobinRule中定义的策略），如果超过了deadline还是没取到则会返回一个null。
4.6 WeightedResponseTimeRule
WeightedResponseTimeRule是RoundRobinRule的一个子类，在WeightedResponseTimeRule中对RoundRobinRule的功能进行了扩展，WeightedResponseTimeRule中会根据每一个实例的运行情况来给计算出该实例的一个权重，然后在挑选实例的时候则根据权重进行挑选，这样能够实现更优的实例调用。WeightedResponseTimeRule中有一个名叫DynamicServerWeightTask的定时任务，默认情况下每隔30秒会计算一次各个服务实例的权重，权重的计算规则也很简单，如果一个服务的平均响应时间越短则权重越大，那么该服务实例被选中执行任务的概率也就越大。
4.7 ClientConfigEnabledRoundRobinRule
ClientConfigEnabledRoundRobinRule选择策略的实现很简单，内部定义了RoundRobinRule，choose方法还是采用了RoundRobinRule的choose方法，所以它的选择策略和RoundRobinRule的选择策略一致，不赘述。
4.8 BestAvailableRule
BestAvailableRule继承自ClientConfigEnabledRoundRobinRule，它在ClientConfigEnabledRoundRobinRule的基础上主要增加了根据loadBalancerStats中保存的服务实例的状态信息来过滤掉失效的服务实例的功能，然后顺便找出并发请求最小的服务实例来使用。然而loadBalancerStats有可能为null，如果loadBalancerStats为null，则BestAvailableRule将采用它的父类即ClientConfigEnabledRoundRobinRule的服务选取策略（线性轮询）。
4.9 PredicateBasedRule
PredicateBasedRule是ClientConfigEnabledRoundRobinRule的一个子类，它先通过内部定义的一个过滤器过滤出一部分服务实例清单，然后再采用线性轮询的方式从过滤出来的结果中选取一个服务实例。
4.10 ZoneAvoidanceRule
ZoneAvoidanceRule是PredicateBasedRule的一个实现类，只不过这里多一个过滤条件，ZoneAvoidanceRule中的过滤条件是以ZoneAvoidancePredicate为主过滤条件和以AvailabilityPredicate为次过滤条件组成的一个叫做CompositePredicate的组合过滤条件，过滤成功之后，继续采用线性轮询的方式从过滤结果中选择一个出来。
二、Spring RestTemplate详解
1. RestTemplate功能介绍
当我们从服务消费端去调用服务提供者的服务的时候，使用了一个很好用的对象，叫做RestTemplate，我们只使用了RestTemplate中最简单的一个功能getForEntity发起了一个get请求去调用服务端的数据，同时，我们还通过配置@LoadBalanced注解开启客户端负载均衡，RestTemplate的功能不可谓不强大，那么今天我们就来详细的看一下RestTemplate中几种常见请求方法的使用。
2. GET请求
在RestTemplate中，发送一个GET请求，我们可以通过如下两种方式：
2.1 getForEntity
getForEntity方法的返回值是一个ResponseEntity<T>，ResponseEntity<T>是Spring对HTTP请求响应的封装，包括了几个重要的元素，如响应码、contentType、contentLength、响应消息体等。比如下面一个例子：
@RequestMapping("/gethello")
public String getHello() {
ResponseEntity<String> responseEntity = restTemplate.getForEntity("http://HELLO-SERVICE/hello", String.class);
String body = responseEntity.getBody();
HttpStatus statusCode = responseEntity.getStatusCode();
int statusCodeValue = responseEntity.getStatusCodeValue();
HttpHeaders headers = responseEntity.getHeaders();
StringBuffer result = new StringBuffer();
result.append("responseEntity.getBody()：").append(body).append("<hr>")
.append("responseEntity.getStatusCode()：").append(statusCode).append("<hr>")
.append("responseEntity.getStatusCodeValue()：").append(statusCodeValue).append("<hr>")
.append("responseEntity.getHeaders()：").append(headers).append("<hr>");
return result.toString();
}
关于这段代码，我说如下几点：
getForEntity的第一个参数为我要调用的服务的地址，这里我调用了服务提供者提供的/hello接口，注意这里是通过服务名调用而不是服务地址，如果写成服务地址就没法实现客户端负载均衡了。
getForEntity第二个参数String.class表示我希望返回的body类型是String
拿到返回结果之后，将返回结果遍历打印出来，最终显示结果如下：
有时候我在调用服务提供者提供的接口时，可能需要传递参数，有两种不同的方式，如下：
@RequestMapping("/sayhello")
public String sayHello() {
ResponseEntity<String> responseEntity = restTemplate.getForEntity("http://HELLO-SERVICE/sayhello?name={1}", String.class, "张三");
return responseEntity.getBody();
}
@RequestMapping("/sayhello2")
public String sayHello2() {
Map<String, String> map = new HashMap<>();
map.put("name", "李四");
ResponseEntity<String> responseEntity = restTemplate.getForEntity("http://HELLO-SERVICE/sayhello?name={name}", String.class, map);
return responseEntity.getBody();
}
可以用一个数字做占位符，最后是一个可变长度的参数，来一一替换前面的占位符
也可以前面使用name={name}这种形式，最后一个参数是一个map，map的key即为前边占位符的名字，map的value为参数值
第一个调用地址也可以是一个URI而不是字符串，这个时候我们构建一个URI即可，参数神马的都包含在URI中了，如下：
@RequestMapping("/sayhello3")
public String sayHello3() {
UriComponents uriComponents = UriComponentsBuilder.fromUriString("http://HELLO-SERVICE/sayhello?name={name}").build().expand("王五").encode();
URI uri = uriComponents.toUri();
ResponseEntity<String> responseEntity = restTemplate.getForEntity(uri, String.class);
return responseEntity.getBody();
}
通过Spring中提供的UriComponents来构建Uri即可。
当然，服务提供者不仅可以返回String，也可以返回一个自定义类型的对象，比如我的服务提供者中有如下方法：
@RequestMapping(value = "/getbook1", method = RequestMethod.GET)
public Book book1() {
return new Book("三国演义", 90, "罗贯中", "花城出版社");
}
对于该方法我可以在服务消费者中通过如下方式来调用：
@RequestMapping("/book1")
public Book book1() {
ResponseEntity<Book> responseEntity = restTemplate.getForEntity("http://HELLO-SERVICE/getbook1", Book.class);
return responseEntity.getBody();
}
运行结果如下：
2.2 getForObject
getForObject函数实际上是对getForEntity函数的进一步封装，如果你只关注返回的消息体的内容，对其他信息都不关注，此时可以使用getForObject，举一个简单的例子，如下：
@RequestMapping("/book2")
public Book book2() {
Book book = restTemplate.getForObject("http://HELLO-SERVICE/getbook1", Book.class);
return book;
}
getForObject也有几个重载方法，如下：
这几个重载方法参数的含义和getForEntity一致，我就不再赘述了。
3. POST请求
在RestTemplate中，POST请求可以通过如下三个方法来发起：
3.1 postForEntity
该方法和get请求中的getForEntity方法类似，如下例子：
@RequestMapping("/book3")
public Book book3() {
Book book = new Book();
book.setName("红楼梦");
ResponseEntity<Book> responseEntity = restTemplate.postForEntity("http://HELLO-SERVICE/getbook2", book, Book.class);
return responseEntity.getBody();
}
方法的第一参数表示要调用的服务的地址
方法的第二个参数表示上传的参数
方法的第三个参数表示返回的消息体的数据类型
我这里创建了一个Book对象，这个Book对象只有name属性有值，将之传递到服务提供者那里去，服务提供者代码如下：
@RequestMapping(value = "/getbook2", method = RequestMethod.POST)
public Book book2(@RequestBody Book book) {
System.out.println(book.getName());
book.setPrice(33);
book.setAuthor("曹雪芹");
book.setPublisher("人民文学出版社");
return book;
}
服务提供者接收到服务消费者传来的参数book，给其他属性设置上值再返回，调用结果如下：
postForEntity的其他重载方法如下：
这些方法的参数含义和getForEntity参数的含义一致，不再赘述。
3.2 postForObject
如果你只关注，返回的消息体，可以直接使用postForObject。用法和getForObject一致。
3.3 postForLocation
postForLocation也是提交新资源，提交成功之后，返回新资源的URI，postForLocation的参数和前面两种的参数基本一致，只不过该方法的返回值为Uri，这个只需要服务提供者返回一个Uri即可，该Uri表示新资源的位置。
4. PUT请求
在RestTemplate中，PUT请求可以通过put方法调用，put方法的参数和前面介绍的postForEntity方法的参数基本一致，只是put方法没有返回值而已。举一个简单的例子，如下：
@RequestMapping("/put")
public void put() {
Book book = new Book();
book.setName("红楼梦");
restTemplate.put("http://HELLO-SERVICE/getbook3/{1}", book, 99);
}
book对象是我要提交的参数，最后的99用来替换前面的占位符{1}
5. DELETE请求
delete请求我们可以通过delete方法调用来实现，如下例子：
@RequestMapping("/delete")
public void delete() {
restTemplate.delete("http://HELLO-SERVICE/getbook4/{1}", 100);
}
delete方法也有几个重载的方法，不过重载的参数和前面基本一致，不赘述。
6. RestTemplate底层讲解
https://mp.weixin.qq.com/s/uvJDmN2f9y3EEI6A3ss_aQ
三、代码实战服务与负载均衡的客户端
相信小伙伴们已经可以自己搭建一个单节点或者多节点的服务注册中心了，同时也能够向这个服务注册中心去注册服务。服务注册成功了，我们就该发现和消费服务了，今天我们就来看看如何实现服务的发现与消费
1. 前置准备条件
1.1 启动服务注册中心
1.2 启动服务提供者
2. 开发消费者客户端
2.1 创建Spring Boot项目
创建名为ribbon-consumer的springboot项目
创建后项目结构如下：
2.2 pom.xml添加配置
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.sang</groupId>
<artifactId>ribbon-consumer</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>ribbon-consumer</name>
<description>Demo project for Spring Boot</description>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.6.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
<spring-cloud.version>Dalston.SR3</spring-cloud.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-ribbon</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
这里重点是添加了spring-cloud-starter-eureka和spring-cloud-starter-ribbon依赖。
2.3 资源文件配置
创建后的资源文件结构如下：
其中static、templates的文件夹内容为空，application.properties文件内容如下：
server.port=9000
spring.application.name=ribbon-consumer
eureka.client.service-url.defaultZone=http://peer1:1111/eureka,http://peer2:1112/eureka
注意服务消费者的端口号不要和前面的端口号冲突。
2.4 创建Controller进行服务消费
在com.wxc.test包下新建HelloController.java,并向Controller类中注入RestTemplate对象，同时在Controller中提供一个名为/ribbon-consumer的接口，在该接口中，我们通过刚刚注入的restTemplate来实现对HELLO-SERVICE服务提供的/hello接口进行调用（上篇文章中我们有详细介绍HELLO-SERVICE的实现）。在调用的过程中，我们的访问地址是HELLO-SERVICE，而不是一个具体的地址。OK，基于以上理解，我们的Controller如下：
@RestController
public class ConsumerController {
@Autowired
RestTemplate restTemplate;
@RequestMapping(value = "/ribbon-consumer",method = RequestMethod.GET)
public String helloController() {
return restTemplate.getForEntity("http://HELLO-SERVICE/hello", String.class).getBody();
}
}
2.5 创建项目启动类
入口类上我们需要做两件事：
亮明Eureka客户端身份
首先在入口类上添加@EnableDiscoveryClient注解，表示该应用是一个Eureka客户端应用，这样该应用就自动具备了发现服务的能力。
提供RestTemplate的Bean
RestTemplate可以帮助我们发起一个GET或者POST请求，这个我们在后文会详细解释，这里我们只需要提供一个RestTemplate Bean就可以了，在提供Bean的同时，添加@LoadBalanced注解，表示开启客户端负载均衡。
OK，基于以上两点，我们的入口类如下：
@SpringBootApplication
@EnableDiscoveryClient
public class RibbonConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(RibbonConsumerApplication.class, args);
}
@LoadBalanced
@Bean
RestTemplate restTemplate() {
return new RestTemplate();
}
}
2.6 启动项目并访问
项目启动
启动成功
项目访问
我们向localhost:9000/ribbon-consumer地址发起请求，就可以看到provider工程中/hello接口返回的Hello World，如下：
那么这个时候有小伙伴可能会有疑问，这个Hello World是由哪一个provider提供的？因为我们在前面启动了两个provider实例。我们看下面一张图：
小伙伴们看到，上面那个日志是由端口号为8081的provider打印出来的，下面的日志是由端口号为8080的provider打印出来的，说明我们这里的负载均衡已经起作用了。此时我们观察客户端的日志，如下：
小伙伴们看到Ribbon输出了当前客户端维护的HELLO-SERVICE的服务列表情况，每一个provider的位置都展示出来，Ribbon就是按照这个列表进行轮询，进而实现基于客户端的负载均衡。同时这里的日志还输出了其他信息，比如各个实例的请求总数量，第一次连接信息，上一次连接信息以及总的请求失败数量等。
四、项目源码与参考资料下载
链接：https://pan.baidu.com/s/1D7zZBq422jhbRWFk7lmMIQ
提取码：qcyl