淘宝架构演进之路
https://mp.weixin.qq.com/s?__biz=MzU0OTk3ODQ3Ng==&mid=2247485427&idx=1&sn=35a1d4d4bc8a96ecb5e841bea2cc1102&chksm=fba6eff0ccd166e6c048741bec01d8979b2be277f6abd38996e0aed2e2f887559dd61f693c71&mpshare=1&scene=1&srcid=0616Hpu6jcYpt7HaXeXHDhea&sharer_sharetime=1596984524454&sharer_shareid=5e222757dd91db135a3736679bc9eb56&key=bbd9db2a3d7572cdbd226e0775c7ca7f0d70f724d8b03095eeecf112cc204c20fba4dff140e40327c794c36ff38352fba5da804015bb2ed758cfdec881b8600fc88cd85cc84fe8b87c901e1b1da583fb&ascene=1&uin=MTE5ODAyNDI3OA%3D%3D&devicetype=Windows+10+x64&version=62090529&lang=zh_CN&exportkey=A1PI8LOUY6TMNRWrt7504jQ%3D&pass_ticket=U40ThnXGAl1WXUCF7y5mEpLjz19dLmkCkdYPHIB2MTvojIlJr2M57ToBVxtUzROh
前置相关知识
1.集群：多台服务器做相同的事情
1.1解决的问题：
a.高并发
b.解决单点故障(服务只有一个服务器提供，此服务器宕机，项目瘫痪)
c.保证服务的高可用
2.分布式：即多个服务器分别负责不同的功能模块，协作完成整个项目
2.1解决的问题：降低耦合，让服务器专职做一个服务
3.正向代理：代理客户端访问服务器
4.反向代理：代理服务器，接收客户端的请求
5.负载均衡：通过指定的策略将请求分发给不同服务器
微服务【面试题】：微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
SpringCloud【面试题】：SpringCloud是一系列框架的集合，集成SpringBoot，提供很多优秀服务：服务发现和注册，统一配置中心, 负载均衡，网关, 熔断器等的一个微服务治理框架.
SpringCloud的组件【主要内容】：
nacos: 注册中心, 服务注册和发现和配置中心
Ribbon: 负载均衡, 实现服务调用的负载均衡
Seata: 熔断器
Feign/Dubbo: 远程调用
Gateway: 网关
nacos：配置中心
Eureka注册中心（C/S架构）
- 服务注册中心
Eureka的服务端应用，提供服务注册和发现功能，就是刚刚我们建立的eureka-demo
- 服务提供者
提供服务的应用，可以是SpringBoot应用，也可以是其它任意技术实现，只要对外提供的是Rest风格服务即可。本例中就是我们实现的user-service-demo
- 服务消费者
消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。本例中就是我们实现的user-consumer-demo
2. 使用步骤
2.1 搭建服务注册中心
创建Maven空工程作为注册中心服务端，导入Eureka-server起步依赖
<!-- 引入eureka起步依赖--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency>在配置文件中定义服务端地址 ```yaml server: port: 10086 spring: application: name: eureka-server
eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka register-with-eureka: false # 不注册自己 fetch-registry: false # 不拉取本eureka服务的信息
3. 在启动类中开启注册中心服务支持
```java
package cn.itcast.eureka;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
@SpringBootApplication
@EnableEurekaServer //开启Eureka服务支持
public class EurekaApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaApplication.class, args);
}
}
2.2 搭建服务提供者应用
【说明】服务提供者相对于注册中心而言也是客户端，相对于服务消费者是服务提供者。
引入Eureka-client起步依赖
<!-- 引入eureka-client依赖--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>编写配置文件：定义服务名称，注册中心地址
eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka instance: # 在Eureka中显示服务的ip地址 ip-address: 127.0.0.1 # 配置服务器ip地址 prefer-ip-address: true # 更倾向于使用ip而不是host名 instance-id: ${eureka.instance.ip-address}:${server.port} # 自定义实例的id2.3 搭建服务消费者应用
引入Eureka-client起步依赖
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>编写配置文件：定义服务名称，注册中心地址
eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka # 定义在Eureka中显示服务的ip地址(如果需要)2.4 补充：
- 在RestTemplate对象的方法上加@LoadBalanced
@Bean @LoadBalanced //配置负载均衡策略(默认采用可用区域轮询) RestTemplate restTemplate(){ return new RestTemplate(); }Ribbon负载均衡
上一节中，我们添加了@LoadBalanced注解，即可实现负载均衡功能，这是什么原理呢？
1.负载均衡原理
SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。
那么我们发出的请求明明是http://userservice/user/1，怎么变成了http://localhost:8081的呢？
2.源码跟踪
为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。
显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。
我们进行源码跟踪：
1）LoadBalancerInterceptor
可以看到这里的intercept方法，拦截了用户的HttpRequest请求，然后做了几件事：
request.getURI()：获取请求uri，本例中就是 http://user-service/user/8originalUri.getHost()：获取uri路径的主机名，其实就是服务id，user-servicethis.loadBalancer.execute()：处理服务id，和用户请求。
这里的this.loadBalancer是LoadBalancerClient类型，我们继续跟入。
2）LoadBalancerClient
继续跟入execute方法：
代码是这样的：
- getLoadBalancer(serviceId)：根据服务id获取ILoadBalancer，而ILoadBalancer会拿着服务id去eureka中获取服务列表并保存起来。
- getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。本例中，可以看到获取了8082端口的服务
放行后，再次访问并跟踪，发现获取的是8081：
果然实现了负载均衡。
3）负载均衡策略IRule
在刚才的代码中，可以看到获取服务使通过一个getServer方法来做负载均衡:
我们继续跟入：
继续跟踪源码chooseServer方法，发现这么一段代码：
我们看看这个rule是谁：
这里的rule默认值是一个RoundRobinRule，看类的介绍：
这不就是轮询的意思嘛。
到这里，整个负载均衡的流程我们就清楚了。
4）总结
SpringCloudRibbon的底层采用了一个拦截器，拦截了RestTemplate发出的请求，对地址做了修改。用一幅图来总结一下：
基本流程如下：
- 拦截我们的RestTemplate请求http://userservice/user/1
- RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service
- DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表
- eureka返回列表，localhost:8081、localhost:8082
- IRule利用内置负载均衡规则，从列表中选择一个，例如localhost:8081
- RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实请求
3.负载均衡策略
3.1.负载均衡策略
负载均衡的规则都定义在IRule接口中，而IRule有很多不同的实现类：
不同规则的含义如下：
| 内置负载均衡规则类 | 规则描述 |
|---|---|
| RoundRobinRule | 简单轮询服务列表来选择服务器。 |
| AvailabilityFilteringRule | 对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。 |
| WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。 |
| ZoneAvoidanceRule | 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。 |
| BestAvailableRule | 忽略那些短路的服务器，并选择并发数较低的服务器。 |
| RandomRule | 随机选择一个可用的服务器。 |
| RetryRule | 重试机制的选择逻辑 |
默认的实现就是ZoneAvoidanceRule，是一种轮询方案
3.2.自定义负载均衡策略
通过定义IRule实现可以修改负载均衡规则，有两种方式：
- 代码方式：在order-service中的OrderApplication类中，定义一个新的IRule：
@Bean
public IRule randomRule(){
return new RandomRule();
}
- 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：
userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
注意，一般用默认的负载均衡规则，不做修改。
4.饥饿加载
Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。
而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：
ribbon:
eager-load:
enabled: true
clients: userservice
Nacos注册中心
1. 认识和安装Nacos
【概述】Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。
【安装】解压即用
2. 注册服务到Nacos
2.1 Nacos和Eureka的区别【重要】
2.1.1 Nacos的服务实例分为两种类型：
- 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
- 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。
2.1.2 配置一个服务实例为永久实例：
spring:
cloud:
nacos:
discovery:
ephemeral: false # 设置为非临时实例
2.1.3 Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：
- Nacos与eureka的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
- Nacos与Eureka的区别
引入依赖
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2.2.6.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency>引用服务项目引入依赖
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency>配置nacos注册中心地址 ```yaml spring: cloud: nacos: server-addr: localhost:8848
4. 重启服务，使用浏览器访问注册中心
<a name="OtQvC"></a>
## 3. Nacos分级存储模型
【说明】分级存储即：以往服务名称对应实例列表，分级是在服务名称和实力列表之间加一层集群。现在的结构为：服务 -> 集群 -> 实例<br />一个**服务**可以有多个**实例**，例如我们的user-service，可以有:
- 127.0.0.1:8081
- 127.0.0.1:8082
- 127.0.0.1:8083
假如这些实例分布于全国各地的不同机房，例如：
- 127.0.0.1:8081，在上海机房
- 127.0.0.1:8082，在上海机房
- 127.0.0.1:8083，在杭州机房
Nacos就将同一机房内的实例 划分为一个**集群**。也就是说，user-service是服务，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型，如图：<br /><br />微服务互相访问时，应该**尽可能访问同集群实例**，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。例如：杭州机房内的order-service应该优先访问同机房的user-service。<br />
<a name="sNozZ"></a>
### 3.1 给userservice服务配置集群
1. 修改配置文件，添加集群配置
2. 重启服务查看nacos控制台
3. 复制userservice服务，添加集群配置
3. 再次启动服务，查看nacos控制台
<a name="Nk7Z8"></a>
### 3.2 同集群优先的负载均衡策略
默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。<br />因此Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。
1. 给服务调用者配置集群信息；eg：orderservice中的配置文件
```yaml
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: HZ # 集群名称
修改负载均衡策略；eg：orderservice中的配置文件
userservice: ribbon: NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则3.3 权重配置
实际部署中会出现这样的场景：服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。
但默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。
因此，Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。在nacos控制台点击详情
- 点击编辑
- 配置权重
4. 环境隔离
Nacos提供了namespace来实现环境隔离功能。
- nacos中可以有多个namespace
- namespace下可以有group、service等
- 不同namespace之间相互隔离，例如不同namespace的服务互相不可见
4.1 实现步骤
- 创建命名空间(即环境)
创建后：
- 添加服务到指定命名空间
- 重启服务查看nacos控制台
默认public命名空间
dev命名空间(开发环境)
此时再访问orderservice服务，由于开发环境即命名空间隔离(orderservice和userservice服务分别在不同的开发环境中)，会访问出错
控制台报错信息：userservice服务没有对应的实例
思维导图
若有收获，就点个赞吧
0 人点赞
