简介:将业务内的所有功能集中在一个项目中开发,打成一个包部署。
优点
架构简单
部署成本低
缺点
简介:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务。
简介:是一种经过良好架构设计的分布式架构方案。
特征:
当我们某一个服务需要获取到其他服务的数据库信息时,我们就需要从当前服务向目标服务发送http请求,调用对应的接口获取数据。
@Bean
public RestTemplate restTemplate(){
return new RestTemplate();
}
@Autowired
private RestTemplate restTemplate;
public Order queryOrderById(Long orderId) {
// 1.查询订单
Order order = orderMapper.findById(orderId);
// 2.利用restTemplate发送http请求,查询用户
String url = "http://localhost:8081/user/" + order.getUserId();
User user= restTemplate.getForObject(url, User.class);
// 3.封装成Order对象
order.setUser(user);
// 4.返回
return order;
}
从结果可以看到成功拿到用户信息。
在服务调用的时候,地址固定,当项目环境发生变化时,对项目很不友好。
消费者该如何获取服务提供者具体信息?
◆服务提供者启动时向eureka注册自己的信息
◆eureka保存这些信息
◆消费者根据服务名称向eureka拉取提供者信息
如果有多个服务提供者,消费者该如何选择?
◆服务消费者利用负载均衡算法,从服务列表中挑选一个
消费者如何感知服务提供者健康状态?
◆服务提供者会每隔30秒向EurekaServer发送心跳请求,报告健康状态
◆eureka会更新记录服务列表信息,心跳不正常会被剔除
◆消费者就可以拉取到最新的信息
搭建EurekaServer服务步骤如下:
1.创建项目,引入spring-cloud-starter-netflix-eureka-server的依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-serverartifactId>
dependency>
2.编写启动类,添加@EnableEurekaServer注解
3.添加application.yml文件,编写下面的配置:
server:
port: 8082
spring:
application:
name: eureka-server
#eureka自己也会被注册
eureka:
client:
service-url:
defaultZone:http://localhost:8082/eureka/
将user-service服务注册到EurekaServer:步骤如下:
l.在user-service:项目引入spring-cloud-starter–netflix-eureka-client的依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
2.在application.yml文件,编写下面的配置:
spring:
application:
name: userservice
eureka:
client:
service-url:
#指的是注册中心服务的地址
defaultZone: http://localhost:8082/eureka/
拓展
:在idea启动单个项目的多个实例:
服务拉取是基于服务名称获取服务列表,然后在对服务列表做负载均衡
1.修改OrderService的代码,修改访问的url路径,用服务名代替ip、端口:
String url "http://userservice/user/"+order.getUserId();
2.在order-service.项目的启动类OrderApplication中的RestTemplate添加负载均衡注解:
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}
负载均衡(Load Balance),意思是将负载(工作任务,访问请求)进行平衡、分摊到多个操作单元(服务器,组件)上进行执行。是解决高性能,单点故障(高可用),扩展性(水平伸缩)的终极解决方案。
这种环境下,当我们的order-server向user-server发送http请求时,会平衡地向不同实例的user-server发送请求。
Ribbon的负载均衡规则是一个叫做IRule的接口来定义的,每一个子接口都是一种规则:
内置负载均衡规则类 | 规则描述 |
---|---|
RoundRobinRule | 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。 |
AvailabilityFilteringRule | 对以下两种服务器进行忽略:(1)在默认情况下,这台服务器如果3次连接失败,这台服务器就会被设置为“短路”状态。短路状态将持续30秒,如果再次连接失败,短路的持续时间就会几何级地增加。(2)并发数过高的服务器。如果一个服务器的并发连接数过高,配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限,可以由客户端的:.:.ActiveConnectionsLimit属性进行配置。 |
WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长,这个服务器的权重就越小。这个规则会随机选择 |
ZoneAvoidanceRule | 服务器,这个权重值会影响服务器的选择。 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类,这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。 |
BestAvailableRule | 忽略哪些短路的服务器,并选择并发数较低的服务器。 |
RandomRule | 随机选择一个可用的服务器。 |
RetryRule | 重试机制的选择逻辑 |
IRule默认为轮询规则,通过定义Rule实现可以修改负载均衡规则,有两种方式:
代码方式:在order-service中的OrderApplication类中,定义一个新的IRule:
@Bean
public IRule randomRule(){
return new RandomRule();
}
配置文件方式:在order-.servicef的application,ym段件中,
添加新的配置也,可以修改规侧:
user-service:
ribbon:
NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RandomRule #负载均规则
Ribbon默认是采用懒加载,即第一次访问时才会去创建LoadBalanceClient,请求时间会很长。
而饥饿加载则会在项目启动时创建,降低第一次访问的耗时,通过下面配置开启饥饿加载:
ribbon:
eager-load:
enabled: true #开启饥饿加载
clients: user-server #指定劢user-server这个服务饥饿加载