微服务技术栈

持续集成

技术详情

这里插入图片描述](https://img-blog.csdnimg.cn/3850cef441c246039707143cb2e74fa1.png)

微服务框架

认识微服务

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

优点：

• 架构简单
• 部署成本低
  缺点：
• 耦合度高

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

• 降低服务耦合

• 有利于服务升级扩展
  缺点：

• 服务拆分

服务治理
分布式架构要考虑的问题：

• 服务拆分粒度如何？
• 服务集群地址如何维护？
• 服务之间如何实现远程调用？
• 服务健康状态如何感知？

**微服务：**是一种经过良好架构设计的分布式架构方案，微服务架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务卡开发
• 面向服务：微服务对外暴露业务结构
• 自治：团队独立，技术独立，数据独立，
• 隔离性强：服务调用做好隔离、容错、降级、避免出现级联问题。

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

企业需求：

SpringCloud

SpringCloud 是目前国内使用最广泛的微服务框架。
SpringCloud 集成了个杂种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用的体验：

• SpringCloud与SpringBoot对应的版本兼容关系

服务拆分及远程调用

服务拆分注意事项

1. 不同微服务，不要重复开发相同业务
2. 微服务数据独立，不要访问其他微服务的数据库。每个微服务有自己的数据库
3. 微服务可以将自己的业务暴漏为接口，供其他微服务调用

导入cloud-demo项目

总结

1. 微服务需要根据业务模块拆分，做到单一职责，不要重复开发相同业务
2. 微服务可以将业务暴露为接口，供其他微服务使用
3. 不同微服务都应该有自己独立的数据库

微服务远程调用

案例：根据订单id查询订单功能
需求：根据订单id查询订单的同时，把订单所属的用户信息一起返回

使用Spring提供的RestTemplate进行远程调用

public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
    /** 
     * @Describe  创建RestTemplate并注入Spring容器
     * @Author ccl
     * @Email c1374954185@163.com
     * @date 2022/7/12 16:10
     
     */
    @Bean
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}


@Autowired
private RestTemplate restTemplate;

public Order queryOrderById(Long orderId) {
    // 1.查询订单
    Order order = orderMapper.findById(orderId);
    // 2.利用restTemplate发起http请求
    String url = "http://localhost:8081/user/" + order.getUserId();
        //发送http请求
    User user = restTemplate.getForObject(url, User.class);
    //3.封装user到Order
    order.setUser(user);
    // 4.返回
    return order;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

总结：

• 基于RestTemplate发起的http请求实现远程调用
• http请求做远程调用是与语言无关的调用，只要知道对反的ip、端口、接口路径、请求参数即可。

提供者与消费者

• **服务提供者：**一次业务中，被其它微服务调用的服务（提供接口给其他微服务）
• **服务消费者：**一次业务中，调用其他微服务的服务。（调用其他微服务提供的接口）
• 提供者与消费者角色其实是相对的
• 一个服务既可以是服务者又可以是消费者

Eureka注册中心

服务调用出现的问题

• 服务消费者该如何获取服务提供者的地址信息？
  • 服务提供者启动时向eureka注册自己的信息
  • eureka保存这些信息
  • 消费者根据服务名称想eureka拉取提供者信息
• 如果有多个服务提供者，消费者该如何选择？
  • 服务消费者利用负载均衡算法，从服务列表中挑选一个
• 消费者如何得知服务提供者的健康状态？
  • 服务提供者会每隔30秒想EurekaServer发送心跳请求，报告健康状态
  • eureka会更新记录服务列表信息，心跳不正常会被剔除
  • 消费者就可以拉去到最新的信息

总结：
在Eureka架构中，微服务角色有两类：

• EurekaServer：服务端，注册中心
  • 记录服务信息
  • 心跳监控
• EurekaClient：客户端
  • provider：服务提供者
    • 注册自己的信息到EurekaServer
    • 每隔30秒向EurekaServer发送心跳
  • consumer：服务消费者
    • 根据服务名称从EurekaServer拉去服务列表
    • 基于服务列表做负载均衡，选中一个微服务后发起远程调用

动手实践

新建一个Maven模块
引入eureka依赖

    org.springframework.cloud
    spring-cloud-starter-netflix-eureka-server

1
2
3
4

编写启动类
给eureka-server服务编写一个启动类，一定要添加一个EnableEurekaServer注解，开启eureka的注册中心功能

@EnableEurekaServer
@SpringBootApplication
public class EurekaApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaApplication.class,args);
    }
}
1
2
3
4
5
6
7

编写配置文件

server:
  port: 10086  #服务端口

spring:     # 为了服务的注册配置这些信息
  application:
    name: eurekaServer  # 服务名称

eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka   #eureka的地址信息
1
2
3
4
5
6
7
8
9
10
11

启动微服务
启动微服务后，在浏览器访问 localhost:10086

表示配置成功

服务注册

引入依赖

    org.springframework.cloud
    spring-cloud-starter-netflix-eureka-client

1
2
3
4

配置文件

spring:
  application:
    name: userservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka
1
2
3
4
5
6
7

启动实例

总结

• 服务注册：
  • 引入eureka-client依赖
  • 在application.yml中配置eureka地址
• 无论是消费者还是提供者，引入eureka-clien依赖，知道eureka地址后，都可以完成注册

完成服务拉取

Ribbon负载均衡

负载均衡策略

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

通过定义IRule实现可以修改负载均衡的规则，有两者中方式：

1. 代码方式：在Order-service中的OrderApplication类中，定义一个新的IRule（全局）

@Bean
    public IRule RandomRule(){
        return new RandomRule();
    }
1
2
3
4

2. 配置文件方式：在Order-service的application。yml文件中添加新的配置也可以修改规则（指7针对某个微服务而言）

   userService:
   ribbon:
   NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

饥饿加载

Ribbon默认采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载。
ribbon:
eager-load:
enabled: true # 开启饥饿加载
clients: userService; #指定某个服务饥饿加载、结合的形式入下：
# -userService
# -userService

总结

• Ribbon负载均衡规则
  • 规则接口是IRule
  • 默认实现是ZonAvoidanceRule，根据zone选择服务列表，然后轮询
• 负载均衡自定义方式
  • 代码方式：配置灵活，但修改时需要重新打包发布
  • 配置方式：直观，方便，无需重新打包发布，但无法做全局配置
• 饥饿加载
  • 开启饥饿加载
  • 指定饥饿加载的微服务名称