一、了解微服务架构

1、微服务技术栈

  1. 整体框架
  2. 微服务架构下的接口与集成_eureka


  3. 整体学习规划路线

2、微服务与单体架构的区别

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

优势

  • 结构简单
  • 部署成本低

缺点

  • 耦合度高,不利于构建和开发

3、分布式架构:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,成为一个服务。

优点:

  • 降低服务耦合度
  • 有利于服务升级扩展

缺点:

  • 架构非常复杂
  • 运维、监控,部署难度提高

4、微服务:是一种经过良好架构设计的分布式架构方案

微服务架构特征:

  • 单一职责:微服务菜饭粒度更小,每一个服务都对应唯一的业务能力,做到单一职责,避免重复业务开发
  • 面向服务:微服务对外暴露业务接口
  • 自治:团队独立,技术独立,数据独立,部署独立
  • 隔离性强:服务调用做好隔离、容错、降级、避免出现级联问题

5、微服务技术对比




微服务架构下的接口与集成_负载均衡_02


6、一般企业需求对比



微服务架构下的接口与集成_微服务架构下的接口与集成_03


二、SpringCloud

1、介绍:SpringCloud是目前国内使用最广泛的微服务框架。

SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验



微服务架构下的接口与集成_微服务架构下的接口与集成_04


SpringCloudyuSpringBoot的版本兼容关系如下:



微服务架构下的接口与集成_负载均衡_05


2、服务拆分及远程调用

  • 不同微服务,不能重复开发相同业务
  • 微服务数据独立,不要访问其他微服务的数据库
  • 微服务可以将自己的业务暴露为接口,供其他微服务调用

3、微服务远程调用

  • 远程调用分析:在模块中发出http请求,访问其他模块的接口,实现远程接口的调用
  • 基于RestTemplate发起的http请求实现远程调用
  • http请求做远程调用是与语言无关的调用,只要知道对方的ip,端口,接口路径,请求参数即可。

//在主类(配置类)中引入springboot带有的RestTemplate(),注入spring容器//主类springbootApplication就是配置类@Beanpublic RestTemplate restTemplate(){ return new RestTemplate(); } restTemplate.getForObject(url,User.class); 可根据请求地址(该请求地址和在浏览器中的地址相同),User.class可将返回的json类型转换为对应的类(对象);


远程调用的提供者与消费者:

  • 服务提供者:在一次业务中,被其他微服务调用的服务。(提供接口给其他微服务)
  • 服务消费者:在一次业务中,调用其他微服务的服务。(调用其他微服务的接口)
  • 中间角色(调用其他微服务,又被其他微服务调用):按照业务逻辑来看,提供接口和调用接口分别就是服务提供者和服务消费者
  • 提供者与消费者的角色相对而言(相对业务而言)

三、Eureka注册中心

1、传统直接地址调用的问题

硬编码:写死地址(微服务多个地址如何解决)

微服务架构下的接口与集成_微服务_06

Eureka的作用:

(1)Eureka注册中心分为两部分:

微服务架构下的接口与集成_ribbon_07



微服务架构下的接口与集成_ribbon_08


消费者根据负载均衡选择对应微服务,并进行远程调用



微服务架构下的接口与集成_微服务架构下的接口与集成_09


注册中心与服务提供者存在一个30秒心跳续约,检测该微服务是否还是正常运行,如果没有正常运行,

就从注册中心删除,并且消费者也不会再收到这个微服务的对应信息,如图中的8083

微服务架构下的接口与集成_eureka_10

主要问题:解决

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

Eureka的搭建主要步骤:

Eureka服务端:

  • 引入eureka-server依赖

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


  •   主类上添加@EnableEurekaServer注解
  • 在application.yml中配置Eureka地址

server: port: 10086 # 服务端口spring: application: name: eurekaserver # eureka的服务名称eureka: client: service-url: # eureka的地址信息 defaultZone: http://127.0.0.1:10086/eureka


Eureka客户端:

  • 引入Eureka-client依赖

<!--eureka客户端依赖--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>


  • 在application.yml中配置Eureka地址

spring: application: name: user-service #服务名称eureka: client: service-url: # eureka的地址信息(客户端与服务端的相同) defaultZone: http://127.0.0.1:10086/eureka


大致服务搭建流程:@LoadBalanced注解用于负载均衡



微服务架构下的接口与集成_负载均衡_11


四、Ribbon(实现负载均衡)SpringCloud的组件

  • 负载均衡原理
  • 负载均衡策略
  • 懒加载


微服务架构下的接口与集成_微服务架构下的接口与集成_12


底层源码实现原理:

流程:

  1. 发起请求:RibbonLoadBanlancerClient根据URL中的id去动态的获取服务列表DynamicServerListLoadBalancer拉取对应的服务列表
  2. 获取服务列表之后根据自己的策略IRule(可自定义),选择某个服务器返回给RibbonLoadBanlancerClient,重新拼接地址,请求到对应服务器

微服务架构下的接口与集成_ribbon_13

轮询策略:



微服务架构下的接口与集成_ribbon_14


修改负载均衡策略:(server:服务器;service:服务)

1、代码方式,在配置类中,定义一个新的IRule;这种方式配置之后不论是该类访问哪一个服务都会遵循这个规则,分配的服务器都是随机的。


//此处是在application(需要随机服务器的主类)中配置的配置类,负载均衡策略为随机@Beanpublic IRule randomRule() {        return new RandomRule();    }


2、在配置文件中application.yml,添加新的配置也可以修改配置的规则; (这里可以指定某种服务请求会使用这种规则,此处为userservice)表示该类,该服务类请求userservice时就会按照这个规则,其他的不管。


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


负载均衡的加载:初始化为懒加载,懒加载之后会进行缓存,后面请求访问就会更快

(开启饥饿加载)



微服务架构下的接口与集成_负载均衡_15


如果有多个指定服务:



微服务架构下的接口与集成_微服务架构下的接口与集成_16