SpringCloud 微服务框架详解

目录

• 微服务
• 远程调用
• 注册中心
• Eureka注册中心
• 搭建eureka-server
• 服务注册
• 负载均衡
• Nacos注册中心
• Nacos服务分级存储模型
• CAP定理：布鲁尔定理
• 配置中心
• 在idea中的使用
• 配置热更新

单体架构：将业务全部功能集中到一个项目中，打成一个war包存储,部署在一台服务器中，只有一个数据库

优点 ：架构简单，部署成本低。适合小型项目

问题：高python并发性能问题，开发时代码耦合问题，部署升级时停服的问题

垂直架构：拆分模块，每个模块使用自己的数据库，如果有模块需要其他模块数据时需要自己查对方模块数据库

问题：大量代码冗余，系统难以维护，性能问题，部署问题

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

服务之间相互调用，分布式多节点部署

优点：降低耦合，有利于服务升级和拓展 适合大型互联网项目

缺点：服务调用关系错综复杂

在进行服务拆分的时候要考虑很多问题：服务拆分的粒度如何界定，服务之后如何调用，服务的调用关系如何管理，需要指定一套有效的标准来约束分布架构

微服务

架构特点：1.单一职责，每一个服务对应唯一的业务能力，做到单一职责

2.自治，团队独立，技术独立，数据独立，独立部署和交付

3.面向服务，服务提供统一的接口，与语言技术无关

4.隔离性强，服务调用做好隔离，容错，降级避免出现级联问题（级联故障是由于正反馈循环并且随着时间的增加所产生的故障。典型表现：最初由单个节点或子系统故障触发的连锁反应）

微服务的上述特点给分布式架构制定啦一个标准，进一步降低服务之间的耦合，提供服务的独立性和灵活性。微服务是一种经过良好架构设计的分布式架构方案

微服务技术的对比

SpringCloud微服务框架

官网地址：Spring Cloud

开发springcloud组件的组织：spring社区，alibaba，netflix

springCloud集成了各种微服务功能组件，基于SpringBoot实现组件的自动装配

常见的组件：服务注册发现（Eureka,nacos,consul），服务远程调用(OpejsnFeign,Dubbo)，服务链路监控(Zipkin,Sleuth)，统一配置管理(SpringCloudConfig,nacos)，统一网关路由(SpringCloudGateway,zuul)，流控降级保护(Hystix,Sentinel)

SpringCloud底层是依赖于SpringBoot的，并且有版本兼容关系

服务拆分原则：1.不同微服务不用重复开发相同业务

2.微服务数据独立，有自己的数据库

3.微服务可以将自己的业务暴露为接口，供其他微服务使用

远程调用

微服务的调用方式：基于RestTemplate发起的http请求实现远程调用，http请求做远程调用只要知道ip，端口，接口路径，请求参数即可。

步骤：1.注册RestTemplate的实例到Spring容器

2.修改消费者order-service服务中的OrderService类中的queryOrderById方法，lHbPvbu根据Order对象中的userId查询User

3.将查询到的User填到Order对象

#在order-service服务中的OrderApplication启动类中，注册RestTemplate实例
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderAjavascriptpplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

#修改order-service服务中的OrderService类中的queryOrderById方法
@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;
    @Autowired
    private RestTemplate restTemplate;
    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        //2查询用户
        String url="http://userservice/user/"+order.getUserId();
        User user = restTemplate.getForObject(url, User.class);
        // 3封装user信息
        order.setUser(user);
        // 4.返回
        return order;
    }
}

在服务调用关系中，会有两个不同的角色，这两个角色是相对的

服务提供者Provider：一次业务中，被其他微服务调用的服务，提供接口给其他服务

服务消费者consumer：一次业务中，调用其他微服务的服务，调用其他微服务提供的接口

注册中心

解决问题：服务注册与发现（服务治理问题）

Eureka注册中心

EurekaServer:服务端，注册中心

EurekaClient:客户端

服务注册：提供者启动之后将自己的信息注册到eureka-server(Eureka服务端）

eureka-server保存服务名称到服务实例地址列表的映射关系

服务拉取：消费者根据服务名称拉取实例地址列表（注册表）并缓存到本地

消费者根据负载均衡算法选中一个实例地址，发起远程调用

健康检查：提供者每隔一段时间（默认30秒）向eureka-server发起请求，报告自己状态。称为心跳

当超过一段时间（90秒）没有发送心跳，eureka-server认为微服务实例故障，将该实例从列表中剔除，拉取服务时，该故障实例排除

搭建eureka-server

1.引入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

2.编写启动类

@SpringBootApplication
@EnableEurekaServer    //开启eureka的注册中心功能
public class EurekaApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaApplication.class, args);
    }
}

3.编写配置文件application.yml

server:
  port: 10086
spring:
  application:
    name: eureka-server
eureka:
  client:
    service-url: 
      defaultZone: http://127.0.0.1:10086/eureka

启动成功

服务注册

引入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

配置文件

spring:
  application:
    name: orderservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

可以将user-service多次启动，模拟多实例部署，注意修改端口设置-Dserver.port=自定义的端口号

如果没有service选项【IDEA】idea打开新项目，左下角的工作栏中没有显示Services解决办法

在order-service完成服务拉取，修改OrderService的代码，修改访问路径

在order-service项目的启动类OrderApplication中RestTemplate添加负载均衡诸界

    @Bean
    @LoadBalanced    //负载均衡注解
    public RestTemplate restTemplate(){
        return  new RestTemplate();
    }

负载均衡

SpringCloud底层利用Ribbon的组件，实现负载均衡。服务调用者动态调用服务提供者的多个节点

Ribbon内部就是集成了LoadBalancerClient负载均衡，通过@LoadBalance注解开启负载均衡器。

基本流程：RibbonLoadBalanceClient从请求url中获取服务名称，DynamicServerListLoadBalancer根据服务名称到eureka拉取服务列表eureka返回服务列表，IRule利用内置的负载均衡规则从列表中选择一个服务，返回给RibbonLoadBalanceClient

Ribbon的负载均衡规则时一个叫IRule的接口来定义的，每一个接口就是一种规则

内置的负载均衡规则：

RoundRobinRule 简单的轮询服务列表来选择服务器，Ribbon默认的负载均衡规则

ZoneAvoidanceRule 以区域可用的服务器为基础进行服务器的选择

默认的实现就是ZoneAvoidanceRule，是一种轮询方案（一般使用默认的负载均衡规则，不修改）

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

Nacos注册中心

Nacos是阿里巴巴的产品，现在是SpringCloudAlibaba中的一个组件(SpringCloudAlibaba实现啦对SpringCloud组件进行扩展）

与Eureka的差异：依赖不同，服务地址不同

Nacos服务搭建，下载安装包，解压，在bin目录下运行startup.cmd -mstandalone

引入依赖，在父工程里面，引入

<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>

在服务消费者和提供者的pom文件引入nacos的依赖，注释掉eureka的依赖

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

配置nacos地址，在user-service和order-service的application.yml中添加nacos地址，不要忘了注释掉eureka的地址

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

在启动类添加注解@EnableDicoveryClient

Nacos服务分级存储模型

一个服务有多个实例，实例分布在不同的机房中，Nacos将同一机房的实例划分为一个集群

服务-集群-实例

服务调用尽可能选择本地集群的服务，跨集群调用延迟较高。（本地集群不可访问时，在访问其他集群）

给user-service配置集群，修改user-service的application.yml文件

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称

复制一个user-service启动配置，添加属性

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH

默认的zoneAvoidanceRule不能实现同集群有效实现负载均衡，Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。

修改负载均衡规则修改order-service的application.yml文件，修改负载均衡规则：

userservjsice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 

根据权重负载均衡：在实际部署中提高权重配置来控制访问频率，权重高访问频率高

在Nacos控制台设置实例的权重值0~1之间

环境隔离namespace

Nacos中服务存储和数据存储的最外层都是一个namespace的东西，用做最外层隔离，修改order-service的application.yml文件：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID

Nacos的服务实例分为两种类型：

临时实例：如果实例宕机超过一段时间，会从服务列表中剔除，默认的类型

非临时实例：如果实例宕机，不会从服务列表中剔除，也叫永久实例

Nacos和Eureka的区别：

相同点：都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测

区别：1.Nacos支持服务端主动检测提供者状态：临时实例采用心跳检测，非临时实例nacos主动询问

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

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

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

CAP定理：布鲁尔定理

指出对于一个分布式计算机来说，不可能同时满足三点，最多同时满足两点：

一致性(Consistency)系统中所有数据备份，在同一时刻同样的值

可用性(Availability)保证每次请求不管成功失败都有响应

分区容错性（Partition tolerance）系统中任意信息的丢失或失败不会影响系统的继续运作

配置中心

配置统一管理和配置隔离问题

nacos=SpringCloud eureka注册中心+SpringCloud config配置中心

项目的核心配置，需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。(热加载：不重启一个项目，使得部分代码更新，通过Java类加载器实现）

保证项目中有bootstrap.yml

微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动

在bootstrap.yml中提那就配置中心相关内容：环境相关spring.profiles.active

配置中心地址，配置文件后缀

配置加载顺序：先加载共享配置文件，再加载环境相关配置文件，在加载application.yml

在idea中的使用

导入依赖

<!--nacos配置管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

添加bootstrap.yaml

spring:
  application:
    name: userservice # 服务名称
  profiles:
    active: dev #开发环境，这里是dev 
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名

配置热更新

最终目的，是修改nacos中的配置后，微服务无需重启就可以让配置生效（配置热更新）

使用两种方式：

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

二： 在controller中使用@ConfigurationProperties注解代替@Value注解。

到此这篇关于SpringCloud 微服务框架详解的文章就介绍到这了,更多相关SpringCloud 微服务框架内容请搜索编程客栈(www.devze.com)以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程客栈(www.devze.com)！