微服务实战

微服务

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。

优点：架构简单，部署成本低。

缺点：耦合度高。

分布式架构：据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务。

优点：耦合度低，有利于服务升级拓展。

缺点：架构复杂，部署成本高。

微服务是一种经过良好架构设计的分布式架构方案，这种方案需要技术框架来落地，全球的互联网公司都在积极尝试自己的微服务落地技术。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。

企业需求

微服务架构特征：

单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发

面向服务：微服务对外暴露业务接口

自治：团队独立、技术独立、数据独立、部署独立

隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

学习路线

SpringCloud

目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。

SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验：

SpringCloud与SpringBoot的版本兼容关系如下：

我们课堂学习的版本是 Hoxton.SR10，因此对应的SpringBoot版本是2.3.x版本。

服务拆分及远程调用

服务拆分注意事项

单一职责：不同微服务，不要重复开发相同业务。

数据独立：不同微服务都应该有自己独立的数据库。

面向服务：将自己的业务暴露为接口，供其它微服务调用。

远程调用方式

基于RestTemplate发起的http请求实现远程调用。

http请求做远程调用是与语言无关的调用，只要知道对方的ip、端口、接口路径、请求参数即可。

提供者与消费者

服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）

服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

提供者与消费者角色其实是相对的。一个服务可以同时是服务提供者和服务消费者。

Eureka注册中心

Eureka的作用

消费者该如何获取服务提供者具体信息？

服务提供者启动时向eureka注册自己的信息 ，eureka保存这些信息，消费者根据服务名称向eureka拉取提供者信息。

如果有多个服务提供者，消费者该如何选择？

服务消费者利用负载均衡算法，从服务列表中挑选一个。

消费者如何感知服务提供者健康状态？

服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态，eureka会更新记录服务列表信息，心跳不正常会被剔除，消费者就可以拉取到最新的信息。

搭建EurekaServer

搭建EurekaServer服务步骤如下：

1. 创建项目，引入spring-cloud-starter-netflix-eureka-server的依赖

2. 编写启动类，添加@EnableEurekaServer注解

3. 添加application.yml文件，编写下面的配置

注册user-service

将user-service服务注册到EurekaServer步骤如下：

在user-service项目引入spring-cloud-starter-netflix-eureka-client的依赖

在application.yml文件，编写下面的配置：

我们可以将user-service多次启动， 模拟多实例部署，但为了避免端口冲突，需要修改端口设置：

注册order-service

order-service虽然是消费者，但与user-service一样都是eureka的client端，同样可以实现服务注册：

在order-service项目引入spring-cloud-starter-netflix-eureka-client的依赖

在application.yml文件，编写下面的配置：

在order-service完成服务拉取

服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡

1. 修改OrderService的代码，修改访问的url路径，用服务名代替ip、端口：

2. 在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解

Ribbon负载均衡

负载均衡流程

源码解读

负载均衡策略

Ribbon的负载均衡规则是一个叫做IRule的接口来定义的，每一个子接口都是一种规则：

修改负载均衡规则

1. 代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：

2. 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

Nacos注册中心

认识Nacos

Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。

服务注册到Nacos

在cloud-demo父工程中添加spring-cloud-alilbaba的管理依赖：

添加nacos的客户端依赖：

修改user-service&order-service中的application.yml文件，注释eureka地址，添加nacos地址：

Nacos服务分级存储模型

服务跨集群调用问题

服务调用尽可能选择本地集群的服务，跨集群调用延迟较高。

本地集群不可访问时，再去访问其它集群。

服务集群属性

修改application.yml，添加如下内容：

在Nacos控制台可以看到集群变化：

根据集群负载均衡

修改order-service中的application.yml，设置集群为HZ：

在order-service中设置负载均衡的IRule为NacosRule，这个规则优先会寻找与自己同集群的服务：

根据权重负载均衡

实际部署中会出现这样的场景：

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。

Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。

1. 在Nacos控制台可以设置实例的权重值，首先选中实例后面的编辑按钮

2. 将权重设置为0.1，测试可以发现8081被访问到的频率大大降低

环境隔离 - namespace

Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西，用来做最外层隔离。

1. 在Nacos控制台可以创建namespace，用来隔离不同环境

2. 然后填写一个新的命名空间信息

3. 保存后会在控制台看到这个命名空间的id

4. 修改order-service的application.yml，添加namespace

5. 重启order-service后，再来查看控制台

6. 此时访问order-service，因为namespace不同，会导致找不到userservice，控制台会报错

nacos注册中心细节分析

临时实例和非临时实例

服务注册到Nacos时，可以选择注册为临时或非临时实例，通过下面的配置来设置：

临时实例宕机时，会从nacos的服务列表中剔除，而非临时实例则不会。

Nacos与eureka对比

共同点

都支持服务注册和服务拉取

都支持服务提供者心跳方式做健康检测

不同点

Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式

临时实例心跳不正常会被剔除，非临时实例则不会被剔除

Nacos支持服务列表变更的消息推送模式，服务列表更新更及时

Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

Nacos配置管理

统一配置管理

在Nacos中添加配置信息

在弹出表单中填写配置信息

配置获取的步骤如下

1.引入Nacos的配置管理客户端依赖

2.在userservice中的resource目录添加一个bootstrap.yml文件，这个文件是引导文件，优先级高于application.yml：

3.我们在user-service中将pattern.dateformat这个属性注入到UserController中做测试：

配置自动刷新

Nacos中的配置文件变更后，微服务无需重启就可以感知。不过需要通过下面两种配置实现

方式一

在@Value注入的变量所在类上添加注解@RefreshScope

方式二

使用@ConfigurationProperties注解

多环境配置共享

微服务启动时会从nacos读取多个配置文件：

[spring.application.name]-[spring.profiles.active].yaml，例如：userservice-dev.yaml

[spring.application.name].yaml，例如：userservice.yaml

无论profile如何变化，[spring.application.name].yaml这个文件一定会加载，因此多环境共享配置可以写入这个文件

多种配置的优先级

服务名-profile.yaml >服务名称.yaml > 本地配置

Nacos集群搭建

集群搭建步骤

1.搭建MySQL集群并初始化数据库表

2.下载解压nacos

3.修改集群配置（节点信息）、数据库配置

4.分别启动多个nacos节点

5.nginx反向代理

http客户端Feign

RestTemplate方式调用存在的问题

先来看我们以前利用RestTemplate发起远程调用的代码

存在下面的问题:

代码可读性差，编程体验不统一

参数复杂URL难以维护

Feign的介绍

Feign是一个声明式的http客户端，官方地址：https://github.com/OpenFeign/feign

其作用就是帮助我们优雅的实现http请求的发送，解决上面提到的问题。

定义和使用Feign客户端

引入依赖

在order-service的启动类添加注解开启Feign的功能

编写Feign客户端

主要是基于SpringMVC的注解来声明远程调用的信息，比如：

服务名称：userservice

请求方式：GET

请求路径：/user/{id}

请求参数：Long id

返回值类型：User

用Feign客户端代替RestTemplate

自定义Feign的配置

Feign运行自定义配置来覆盖默认配置，可以修改的配置如下

一般我们需要配置的就是日志级别。

配置Feign日志有两种方式

方式一

全局生效

局部生效

方式二

java代码方式，需要先声明一个Bean

全局配置

而后如果是全局配置，则把它放到@EnableFeignClients这个注解中：

如果是局部配置，则把它放到@FeignClient这个注解中：

Feign的性能优化

Feign底层的客户端实现：

URLConnection：默认实现，不支持连接池

Apache HttpClient ：支持连接池

OKHttp：支持连接池

因此优化Feign的性能主要包括：

使用连接池代替默认的URLConnection

日志级别，最好用basic或none

Feign的性能优化-连接池配置

Feign添加HttpClient的支持

引入依赖

配置连接池

Feign的最佳实践

方式一（继承）

给消费者的FeignClient和提供者的controller定义统一的父接口作为标准。

服务紧耦合

父接口参数列表中的映射不会被继承

方式二（抽取）

将FeignClient抽取为独立模块，并且把接口有关的POJO、默认的Feign配置都放到这个模块中，提供给所有消费者使用

抽取FeignClient

实现最佳实践方式二的步骤如下：

首先创建一个module，命名为feign-api，然后引入feign的starter依赖

将order-service中编写的UserClient、User、DefaultFeignConfiguration都复制到feign-api项目中

在order-service中引入feign-api的依赖

修改order-service中的所有与上述三个组件有关的import部分，改成导入feign-api中的包

重启测试

当定义的FeignClient不在SpringBootApplication的扫描包范围时，这些FeignClient无法使用。有两种方式解决：

方式一：指定FeignClient所在包

方式二：指定FeignClient字节码

统一网关Gateway

为什么需要网关

网关的技术实现

在SpringCloud中网关的实现包括两种：gateway，zuul。

Zuul是基于Servlet的实现，属于阻塞式编程。而SpringCloudGateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能。

搭建网关服务的步骤

1. 创建新的module，引入SpringCloudGateway的依赖和nacos的服务发现依赖

2.编写路由配置及nacos地址

路由断言工厂Route Predicate Factory

网关路由可以配置的内容包括

• 路由id：路由唯一标示

• uri：路由目的地，支持lb和http两种

• predicates：路由断言，判断请求是否符合要求，符合则转发到路由目的地

• filters：路由过滤器，处理请求或响应

我们在配置文件中写的断言规则只是字符串，这些字符串会被Predicate Factory读取并处理，转变为路由判断的条件,例如Path=/user/**是按照路径匹配，这个规则是由org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory类来处理的，像这样的断言工厂在SpringCloudGateway还有十几个。

Spring提供了11种基本的Predicate工厂

路由过滤器 GatewayFilter

GatewayFilter是网关中提供的一种过滤器，可以对进入网关的请求和微服务返回的响应做处理

Spring提供了31种不同的路由过滤器工厂。例如

给所有进入userservice的请求添加一个请求头：Truth=itcast is freaking awesome!

实现方式：在gateway中修改application.yml文件，给userservice的路由添加过滤器：

默认过滤器

如果要对所有的路由都生效，则可以将过滤器工厂写到default下。格式如下

全局过滤器 GlobalFilter

全局过滤器的作用也是处理一切进入网关的请求和微服务响应，与GatewayFilter的作用一样。

区别在于GatewayFilter通过配置定义，处理逻辑是固定的。而GlobalFilter的逻辑需要自己写代码实现。定义方式是实现GlobalFilter接口。

定义全局过滤器，拦截并判断用户身份

需求：定义全局过滤器，拦截请求，判断请求的参数是否满足下面条件：

参数中是否有authorization，

authorization参数值是否为admin

如果同时满足则放行，否则拦截

自定义类，实现GlobalFilter接口，添加@Order注解或者implements Ordered里面的getOrder()

过滤器的执行顺序

请求进入网关会碰到三类过滤器：当前路由的过滤器、DefaultFilter、GlobalFilter

请求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器

每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。

GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定

路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。

当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。

可以参考下面几个类的源码来查看：

跨域问题处理

跨域：域名不一致就是跨域，主要包括：

域名不同： www.taobao.com 和 www.taobao.org 和 www.jd.com 和 miaosha.jd.com

域名相同，端口不同：localhost:8080和localhost8081

跨域问题：浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截的问题

解决方案：CORS

网关处理跨域采用的同样是CORS方案，并且只需要简单配置即可实现：

Docker