什么是微服务？

单体架构：

  • 将业务的所有功能集中在一个项目中开发，打成一个包部署。
  • 优点：架构简单，部署成本低。
  • 缺点：耦合度高。

分布式架构：

  • 根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，成为一个服务
  • 优点：降低服务耦合，有利于服务升级拓展

微服务：

  • 微服务是一种经过良好结构设计的分布式架构方案，微服务架构特征：
  • 单一职责：微服务拆分力度更小，每一服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
  • 面向服务：微服务对外暴露业务接口
  • 自治：团队独立、技术独立、数据独立、部署独立
  • 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
微服务结构：

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

Dubbo：
  1. 注册中心：zookeeper、Redis
  2. 服务远程调用：Dubbo 协议
  3. 配置中心：无
  4. 服务网关：无
  5. 服务监控和保护：dubbo-admin，功能弱
SpringCloud：
  1. 注册中心：Eureka、Consul
  2. 服务远程调用：Feign (http 协议)
  3. 配置中心：SpringCloudConfig
  4. 服务网关：SpringCloudGateway、Zuul
  5. 服务监控和保护：Hystrix
SpringCloudAlibaba：
  1. 注册中心：Nacos、Eureka
  2. 服务远程调用：Dubbo、Feign
  3. 配置中心：SpringCloudConfig、Nacos
  4. 服务网关：SpringCloudGateway、Zuul
  5. 服务监控和保护：Sentinel

SpringCloud：

是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud
SpringCloud 继承了各种微服务功能组件，并基于 SpringBoot 实现了这些组件的自动装配，从而提供了良好的开箱即用体验：
– 服务注册发现：Eureka、Nacos、Consul
– 服务远程调用：OpenFeign、Dubbo
– 服务链路监控：Zipkin、Sleuth
– 统一配置管理：SpringCloudConfig、Nacos
– 统一网关路由：SpringCloudGateway、Zuul
– 流控、降级、保护：Hystix、Sentinel

SpringCloud 与 SpringBoot 的版本兼容关系如下：
ReleaseTrain BootVersion
2020.0.x aka ilford 2.4.x
Hoxton 2.2.x,2.3.x (Starting with SR3.5；SR5 用 2.2.x、SR5 以上用 2.3.x)
Greenwich 2.1.x
Finchley 2.0.x
Edgware 1.5.x
Dalston 1.5.x
服务拆分注意事项：
  1. 不同微服务，不要重复开发相同业务
  2. 微服务数据独立，不要访问其它微服务的数据库
  3. 微服务可以将自己的业务暴露为接口，供其它微服务调用
微服务远程调用：
  • 基于 RestTemplate 发起的 http 请求实现远程调用
  • http 请求交作远程调用是与语言无关的调用，只要指导对方的 ip、端口、接口路径、请求参数即可
1. 注册 RestTemplate

在 order-service 的 OrderApplication 中注册 RestTemplate

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
    /**
     * 创建RestTemplate并注入Spring容器
     */
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
2. 服务远程调用 RestTemplate

修改 order-service 中的 OrderService 的 queryOrderById 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Autowired
private RestTemplate restTemplate;
 
public Order queryOrderById(Long orderId) {
    // 1.查询订单
    Order order = orderMapper.findById(orderId);
    // 2.利用RestTemplate发起http请求，查询用户
    // 2.1.url路径
    String url = "http://localhost:8081/user/" + order.getUserId();
    // 2.2.发送http请求，实现远程调用
    User user = restTemplate.getForObject(url, User.class);        //(url,返回值类型)
    // 3.封装user到Order
    order.setUser(user);
    // 4.返回
    return order;
}
提供者与消费者：
  • 服务提供者：一次业务中，被其他微服务调用的服务 (提供接口给其他微服务)
  • 服务消费者：一次业务中，调用其他微服务的服务 (调用其他微服务提供的接口)
  • 提供者与消费者角色其实是相对的，一个服务可以同时是服务提供者和服务消费者
eureka 的作用：
  1. 服务消费者该如何获取服务提供者的地址信息？
    • 服务提供者启动时向 eureka 注册自己的信息
    • eureka 保存这些信息
    • 消费者根据服务名称向 eureka 拉取提供者信息
  2. 如果有多个服务提供者，消费者该如何选择？
    • 服务消费者利用负载均衡算法，从服务列表中挑选一个
  3. 消费者如何得知服务提供者的健康状态？
    • 服务提供者会每隔 30 秒向 EurekaServer 发送心跳请求，报告健康状态
    • eureka 会更新记录服务列表信息，心跳不正常会被剔除
    • 消费者就可以拉渠道最新的信息
在 eureka 架构中，微服务角色有两类：
  1. EurekaServer：服务端，注册中心
    • 记录服务信息
    • 心跳监控
  2. EurekaClient：客户端
    • provider：服务提供者，例如案例中的 user-service
      • 注册自己的信息到 EurekaServer
      • 每隔 30 秒向 EurekaServer 发送心跳
    • consumer：服务消费者，例如案例中的 order-service
      • 根据服务名称从 EurekaServer 拉取服务列表
      • 根据服务列表作负载均衡，选一个微服务后发起远程调用
搭建 EuerkaServer：
  1. 创建项目，引入 spring-cloud-starter-netflix-eureka-server 的依赖
1
2
3
4
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
  1. 编写启动类，添加 @EnableEurekaServer 注解
  2. 添加 application.yml 文件，编写下面的配置：
1
2
3
4
5
6
7
8
9
server:
  port: 10086 # 服务端口
spring:
  application:
    name: eurekaserver # eureka的服务名称
eureka:
  client:
    service-url:  # eureka的地址信息
      defaultZone: http://127.0.0.1:10086/eureka
注册 user-service：
  1. 在 user-service 项目引入 spring-cloud-starter-netflix-eureka-client 的依赖
1
2
3
4
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
  1. 在 application.yml 文件，编写下面的配置：
1
2
3
4
5
6
7
spring:
  application:
    name: userserver # user的服务名称
eureka:
  client:
    service-url:  # user的地址信息
      defaultZone: http://127.0.0.1:10086/eureka
  1. 另外，我们可以将 user-service 多次启动，模拟多实例部署，但为了避免端口冲突，需要修改端口设置：
    Serices窗口中，选中UserApplication右键点击Copy Configuration；修改Environment中的VM options项为：-Dserver.port=8082
在 order-service 完成服务拉取：

服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡
\1. 修改 OrderService 的代码，修改访问的 url 路径，用服务名代替 ip、端口：
String url = "http://userservice/user/" + order.getUserId();

  1. 在 order-service 项目的启动类 OrderApplication 中的 RestTemplate 添加负载均衡注解：
1
2
3
4
5
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
    return new RestTemplate();
}
Eureka 总结：
  1. 搭建 EurekaServer
    1. 引入 eureka-server 依赖
    2. 添加 @EnableEurekaServer 注解
    3. 在 application.yml 中配置 eureka 地址
  2. 服务注册
    1. 引入 eureka-client 依赖
    2. 在 application.yml 中配置 eureka 地址
  3. 服务发现
    1. 引入 eureka-client 依赖
    2. 在 application.yml 中配置 eureka 地址
    3. 给 RestTemplate 添加 @LoadBelanced 注解
    4. 用服务提供者的服务名称远程调用

Ribbon 负载均衡：

负载均衡流程：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
oeder-service
        1. 发起请求：http://userservice/user/1
到RibbonLoadBanlancerclient
        2. 获取url中的服务id：userservicr
到DynamicServerListLoadBalancer
        3. 拉取userservice
        4. 返回服务列表localhost:8081、localhost8082
到DynamicServerListLoadBalancer
        5. 服务器负载均衡localhost:8081、localhost8082
到IRule
        6. 选择某个服务localhost:8081
到RibbonLoadBanlancerclient
        7. 修改url，发起请求：http://localhost:8081/user/1
        8. 请求到8081或8082
到user-service8081或user-service8082
负载均衡策略：
  1. RoundRobinRule：
    简单轮询服务列表来选择服务器。它是 Ribbon 默认的负载均衡规则
  2. AvailabilityFilteringRule：
    • 对以下两种服务器进行忽略：
      1. 在默认情况下，这台服务器如果 3 次连接失败，这台服务器就会被设置为” 短路” 状态。短路状态将持续 30 秒，如果再次连接失败，短路的持续时间就会几何级地增加。
      2. 并发数过高的服务器。如果一个服务器的并发连接数过高，配置了 AvailabilityFilteringRule 规则的客户端也会将其忽略。并发连接数的上线，可以由客户端的 <clientName><clientConfigNameSpace>.ActiveConnectionsLimit 属性进行配置。
  3. WeightedResponseTimeRule：
    • 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重值就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
  4. ZoneAvoidanceRule：
    • 以区域可用的服务器为基础进行服务器的选择。使用 Zone 对服务器进行分类，这个 Zone 可以理解为一个机房、一个机架等。而后在对 Zone 内的多个服务做轮询。
  5. BestAvailableRule：
    • 忽略哪些短路的服务器，并选择并发数较低的服务器。
  6. RandomRule：
    • 随机选择一个可用的服务器。
  7. RetryRule：
    • 重试机制的选择逻辑
通过定义 IRule 实现可以修改负载均衡规则，有两种方式：
  1. 代码方式：在 order-service 中的 OrderApplication 类中，定义一个新的 IRule：
1
2
3
4
@Bean
public IRule randomRule(){
        return new RandomRule();
}
  1. 配置文件方式：在 order-service 的 application.yml 文件中，添加新的配置也可以修改规则：
1
2
3
userservice:
  ribbon: 
    NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RandomRule #负载均衡规则
饥饿加载：

Ribbon 默认是采用懒加载，即第一次访问时才会去创建 LoadBalanceClient，请求时间会很长。
而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：

1
2
3
4
ribbon:
  eager-load:
    enabled: ture # 开启饥饿加载
    clients: userservice # 指定对userservice这个服务饥饿加载
Ribbon 总结：
  1. Ribbon 负载均衡规则：
    1. 规则接口是 IRule
    2. 默认实现是 ZoneAvoidanceRule，根据 zone 选择服务列表，然后轮询
  2. 负载均衡自定义方式：
    1. 代码方式：配置灵活，但修改时需要重新打包发布
    2. 配置方式：只管，方便，无需重新打包发布，但是无法做全局配置
  3. 饥饿加载：
    1. 开启饥饿加载
    2. 指定饥饿加载的微服务名称
微服务
什么是微服务？
http://blog.hrseno.cn/2024/06/20/微服务-什么是微服务/
作者
黄浩森
发布于
2024年6月20日
许可协议