一、认识微服务
服务架构演变
单体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署。
特点:简单方便,高度耦合,扩展性差,适合小型项目。
分布式架构:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务。
特点:松耦合,扩展性好,但架构复杂,难度大。适合大型互联网项目
微服务:一种良好的分布式架构方案
优点:拆分粒度更小、服务更独立、耦合度更低
缺点:架构非常复杂,运维、监控、部署难度提高
微服务架构特征:
单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责,避免重复业务开发
面向服务:微服务对外暴露业务接口
自治:团队独立、技术独立、数据独立、部署独立
隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题
SpringCloud
SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验
![](https://i-blog.csdnimg.cn/blog_migrate/8b8ca15c3e83a49d59ae093288bb60e8.png)
二、微服务拆分案例
基于小案例练习,需求:根据订单id查询订单的同时,把订单所属的用户信息一起返回
![](https://i-blog.csdnimg.cn/blog_migrate/2072a1aca19f21a2682500f843fae885.png)
服务拆分注意事项
单一职责:不同微服务,不要重复开发相同业务
数据独立:不要访问其它微服务的数据库,不同微服务都应该有自己独立的数据库
面向服务:将自己的业务暴露为接口,供其它微服务调用
微服务远程调用
基于RestTemplate发起http请求实现远程调用,http请求做远程调用是与语言无关的调用,只要知道对方的ip、端口、接口路径、请求参数即可
注册RestTemplate
在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();
}
}
服务远程调用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.利用RestTemplate发送http请求,查询用户
//2.1.url路径
String url = "http://localhost:8081/user/" + order.getUserId();
//2.2.发送http请求,实现远程调用
User user = restTemplate.getForObject(url,User.class);
//3.封装user到order
order.setUser(user);
// 4.返回
return order;
}
}
服务调用关系
服务提供者:暴露接口给其它微服务调用
服务消费者:调用其它微服务提供的接口
提供者与消费者角色其实是相对的,一个服务可以同时是服务提供者和服务消费者
三、Eureka注册中心
Eureka的作用
![](https://i-blog.csdnimg.cn/blog_migrate/fe7ad79b164bbf2da4b6351495d30ba4.png)
消费者该如何获取服务提供者具体信息?
服务提供者启动时向eureka注册自己的信息,eureka保存这些信息,消费者根据服务名称向eureka拉取提供者信息
如果有多个服务提供者,消费者该如何选择?
服务消费者利用负载均衡算法,从服务列表中挑选一个
消费者如何感知服务提供者健康状态?
服务提供者会每隔30秒向EurekaServer发送心跳请求,报告健康状态
eureka会更新记录服务列表信息,心跳不正常会被剔除
消费者就可以拉取到最新的信息
在Eureka架构中,微服务角色有两类:
EurekaServer:服务端,注册中心
记录服务信息、心跳监控
EurekaClient:客户端
Provider:服务提供者,例如案例中的user-service
注册自己的信息到EurekaServer、每隔30秒向EurekaServer发送心跳
consumer:服务消费者,例如案例中的order-service
根据服务名称从EurekaServer拉取服务列表
基于服务列表做负载均衡,选中一个微服务后发起远程调用
代码实践
![](https://i-blog.csdnimg.cn/blog_migrate/9a97b3c14b94c668b2b2821b9ef3eb84.png)
搭建EurekaServer服务步骤如下:
创建项目,引入spring-cloud-starter-netflix-eureka-server的依赖
<!--eureka服务端-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
编写启动类,添加@EnableEurekaServer注解
添加application.yml文件,编写下面的配置:
server:
port: 10086
spring:
application:
name: eurekaserver # eureka的服务名称
eureka:
client:
service-url: # eureka的地址信息
defaultZone: http://127.0.0.1:10086/eureka
将user-service服务注册到EurekaServer步骤如下:
(order-service虽然是消费者,但与user-service一样都是eureka的client端,同样可以实现服务注册,步骤与user-service一致)
在user-service项目引入spring-cloud-starter-netflix-eureka-client的依赖
<!--eureka客户端-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
在application.yml文件中配置eureka地址:
spring:
application:
name: userservice # user服务的服务名称
eureka:
client:
service-url: # eureka的地址信息
defaultZone: http://127.0.0.1:10086/eureka/
在order-service完成服务拉取
服务拉取是基于服务名称获取服务列表,然后再对服务列表做负载均衡
修改OrderService的代码,修改访问的url路径,用服务名代替ip、端口:
String url = "http://userservice/user/" + order.getUserId();
在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解:
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}
总结:
1.搭建EurekaServer
•引入eureka-server依赖
•添加@EnableEurekaServer注解
•在application.yml中配置eureka地址
2.服务注册
•引入eureka-client依赖
•在application.yml中配置eureka地址
3.服务发现
•引入eureka-client依赖
•在application.yml中配置eureka地址
•给RestTemplate添加@LoadBalanced注解
•用服务提供者的服务名称远程调用
四、Ribbon负载均衡原理
负载均衡流程
![](https://i-blog.csdnimg.cn/blog_migrate/4fd2a6194c225ff174022a6011232088.png)
![](https://i-blog.csdnimg.cn/blog_migrate/0760feb927b11cc39bb31d9c08b1e4e3.png)
负载均衡策略
Ribbon的负载均衡规则是一个叫做IRule的接口来定义的,每一个子接口都是一种规则:
![](https://i-blog.csdnimg.cn/blog_migrate/5706f0f345bb8bd3e6342603f8c2fe98.png)
默认实现是ZoneAvoidanceRule,根据zone选择服务列表,然后轮询
通过定义IRule实现可以修改负载均衡规则,有两种方式:
代码方式:在order-service中的OrderApplication类中,定义一个新的IRule:
(配置灵活,但修改时需要重新打包发布)
@Bean
public IRule randomRule(){
return new RandomRule();
}
配置文件方式:在order-service的application.yml文件中,添加新的配置也可以修改规则:
(直观,方便,无需重新打包发布,但是无法做全局配置)
userservice:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule# 负载均衡规则
饥饿加载
Ribbon默认是采用懒加载,即第一次访问时才会去创建LoadBalanceClient,请求时间会很长。而饥饿加载则会在项目启动时创建,降低第一次访问的耗时,通过下面配置开启饥饿加载:
ribbon:
eager-load:
enabled: true # 开启饥饿加载
clients: userservice # 指定对userservice这个服务饥饿加载
五、Nacos注册中心
Nacos服务搭建
下载安装包
解压
在bin目录下运行指令:startup.cmd -m standalone
Nacos服务注册或发现
在cloud-demo父工程中添加spring-cloud-alilbaba的管理依赖:
<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>
引入客户端nacos.discovery依赖
<!-- nacos客户端依赖 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
user-service&order-service中的application.yml文件配置nacos地址spring.cloud.nacos.server-addr
spring:
cloud:
nacos:
server-addr: localhost:8848 # nacos 服务端地址
Nacos服务分级存储模型
①一级是服务,例如userservice
②二级是集群,例如杭州或上海
③三级是实例,例如杭州机房的某台部署了userservice的服务器
![](https://i-blog.csdnimg.cn/blog_migrate/61f7268d82028f6c75d4e6b0aaf57709.png)
服务调用尽可能选择本地集群的服务,跨集群调用延迟较高
本地集群不可访问时,再去访问其它集群
设置实例的集群属性
修改application.yml文件,添加spring.cloud.nacos.discovery.cluster-name属性即可
spring:
cloud:
nacos:
server-addr: localhost:8848 # nacos 服务端地址
discovery:
cluster-name: HZ # 配置集群名称,也就是机房位置,例如:HZ,杭州
NacosRule负载均衡策略
①优先选择同集群服务实例列表
②本地集群找不到提供者,才去其它集群寻找,并且会报警告
③确定了可用实例列表后,再采用随机负载均衡挑选实例
userservice:
ribbon:
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则
实例的权重控制
①Nacos控制台可以设置实例的权重值,0~1之间
②同集群内的多个实例,权重越高被访问的频率越高
③权重设置为0则完全不会被访问
Nacos环境隔离
①每个namespace都有唯一id
②服务设置namespace时要写id而不是名称
③不同namespace下的服务互相不可见
![](https://i-blog.csdnimg.cn/blog_migrate/10a6a5a8fd10958c1d91be198259d6ae.png)
Nacos注册中心细节
![](https://i-blog.csdnimg.cn/blog_migrate/0842645371e913c069310a8ab91403c6.png)
服务注册到Nacos时,可以选择注册为临时或非临时实例,通过下面的配置来设置:
(临时实例宕机时,会从nacos的服务列表中剔除,而非临时实例则不会)
spring:
cloud:
nacos:
discovery:
ephemeral: false # 设置为非临时实例
六、Eureka与Nacos比较
共同点
①都支持服务注册和服务拉取
②都支持服务提供者心跳方式做健康检测
区别
①Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式
②临时实例心跳不正常会被剔除,非临时实例则不会被剔除
③Nacos支持服务列表变更的消息推送模式,服务列表更新更及时
④Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;Eureka采用AP方式