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

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

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

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

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

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

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

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

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

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

微服务

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

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

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

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

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

微服务技术的对比

SpringCloud微服务框架

官网地址:Spring Cloud

开发springcloud组件的组织:spring社区,alibaba,netflix

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

常见的组件:服务注册发现(Eureka,nacos,consul),服务远程调用(OpenFeign,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方法,根据Order对象中的userId查询User

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

1.

#在order-service服务中的OrderApplication启动类中,注册RestTemplate实例
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

2.

#修改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解决办法 - Angel挤一挤 - 博客园

 在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文件,修改负载均衡规则:

userservice:
  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注解。

 


原创作者:m0_50601240 版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 原文链接:https://blog.csdn.net/m0_50601240/article/details/124049460

未经允许不得转载! 作者:百思站长,转载或复制请以超链接形式并注明出处百思网

原文地址:《SpringCloud 微服务框架》发布于:2023-04-09

发表评论

快捷回复: 表情:
评论列表 (暂无评论,384人围观)

还没有评论,来说两句吧...