微服务架构演变
认识微服务
服务架构演变
单体架构:将业务的所有功能集中在一个项目种开发,打成一个包部署
优点:
- 架构简单
- 部署成本低
缺点:
- 耦合度高
分布式架构:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务
优点:
- 降低服务耦合
- 有利于服务升级拓展
需要考虑的问题:
- 服务拆分粒度
- 服务集群地址如何维护
- 服务之间如何实现远程调用
- 服务健康状态如何感知
微服务
- 单一职责:微服务拆分粒度更小,每个服务都对应唯一的业务能力,能做到单一职责,避免重复开发
- 面向服务:微服务对外暴露业务接口
- 自治:团队独立、技术独立、数据独立、部署独立
- 隔离性强:服务调用做好隔离、容错、降级、避免出现级联问题
微服务技术对比
企业需求
SpringCloud
官网:https://spring.io/projects/spring-cloud
服务拆分及远程调用
服务拆分注意事项:
- 不同微服务,不要重复开发相同业务
- 微服务数据独立,不要访问其它微服务的数据库
- 微服务可以将自己的业务暴露为接口,供其它微服务调用
远程调用方式分析:
服务远程调用
使用RestTemplate类
主启动类
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
service
@Autowired
private RestTemplate restTemplate;
public Order queryOrderById(Long orderId) {
// 1.查询订单
Order order = orderMapper.findById(orderId);
Long userId = order.getUserId();
String url = "http://userservice/user/"+userId;
User user = restTemplate.getForObject(url, User.class);
order.setUser(user);
// 4.返回
return order;
}
提供者与消费者
- 服务提供者:一次业务中,被其它微服务调用的服务
- 服务消费者:一次业务中,调用其它服务
eureka注册中心
服务调用出现的问题
-
服务消费者该如何获取服务提供者的地址信息
-
- 服务提供者启动时向eureka注册自己的信息
- eureka保存这些信息
- 消费者根据服务名称向eureka拉取提供者信息
-
如果有多个服务者,消费者该如何选择
-
- 服务消费者利用负载均衡算法,从服务列表中挑选一个
-
消费者如何得知服务提供者的健康状态
-
- 服务提供者会每隔30秒向EurekaServer发送心跳请求,报告健康状态
- eureka会更新记录服务列表信息,心跳不正常会被剔除
- 消费者就可以拉取到最新信息
Eureka的作用
搭建EurekaServer服务步骤如下:
引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
添加@EnableEurekaServer注解
添加application.yml配置文件
server:
port: 10086 #服务端口
spring:
application: # eureka的服务名称
name: eurekaserver
eureka:
client:
service-url: # eureka的地址信息
defaultZone: http://127.0.0.1:10086/eureka
配置EurekaService
引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
添加@EnableEurekaServer注解
添加application.yml配置文件
server:
port: 8081
spring:
application: # eureka的服务名称
name: userservice # user服务名称
eureka:
client:
service-url: # eureka的地址信息
defaultZone: http://127.0.0.1:10086/eureka
在order-service完成服务拉去
1.修改OrderService的代码,修改访问的url路径,用服务名代替ip、端口:
public Order queryOrderById(Long orderId) {
// 1.查询订单
Order order = orderMapper.findById(orderId);
Long userId = order.getUserId();
String url = "http://userservice/user/"+userId;
User user = restTemplate.getForObject(url, User.class);
order.setUser(user);
// 4.返回
return order;
}
2.在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解:
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
Ribbon负载均衡原理
流程
源码
负载均衡策略
改变负载均衡规则
- 代码方式:在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注册中心
官网:https://nacos.io/zh-cn/docs/v2/quickstart/quick-start.html
服务注册到nacos
依赖
父工程中(如果爆红,先在dependencies中导入刷新maven,再在dependencyManagement中导入)
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>2.2.5.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
子工程
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
application.yml
spring:
application:
name: orderservice
cloud:
nacos:
server-addr: localhost:8848
nacos服务分级存储模型
服务跨集群调用问题
cloud:
nacos:
server-addr: localhost:8848
# 集群配置
discovery:
cluster-name: HZ #集群名称
nacos控制中心
根据集群负载均衡
1.修改order-service中application.yml,设置集群为HZ:
userservice:
ribbon:
# 优先同区域再随机
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule
根据权重负载均衡
实际部署中会出现这样的场景:
- 服务器设备性能有差异,部分实例所在机器性能较好,另一些较差,我们希望性能好的机器承担更多的用户请求
Nacos提供了权重配置来访问频繁,权重越大则访问频率越高
如果出现500错误,则:
环境隔离-namespace
Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西,用来做最外层隔离
配置
yml配置
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: HZ
# 命名空间配置
namespace: 7c20c8b7-1a7b-46f2-8451-5190cf114fcb
nacos注册中心细节分析
配置非临时实例
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: HZ
namespace: 7c20c8b7-1a7b-46f2-8451-5190cf114fcb
ephemeral: false
Nacos与eureka共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
- Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测
- 临时实例心跳不正常会被剔除,非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式,服务列表更新及时
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: HZ
namespace: 7c20c8b7-1a7b-46f2-8451-5190cf114fcb
ephemeral: false
Nacos与eureka共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
- Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测
- 临时实例心跳不正常会被剔除,非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式,服务列表更新及时
- Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;Eureka采用AP方式