目录
服务架构演变
单体架构
分布式架构
分布式架构需要考虑的问题
微服务
架构比较
微服务技术对比
服务拆分注意事项
案例
服务远程调用
RestTemplate
Eureka注册中心
RestTemplate存在的问题
服务调用考虑的问题
Eureka的作用
搭建EurekaServer
服务注册
服务发现
Ribbon负载均衡
负载均衡流程
负载均衡策略更改
Ribbon加载方式
微服务开发,实现充分解耦
服务架构演变
单体架构
将业务的所有功能集中在一个项目中开发,打成一个包部署
优点:架构简单、部署成本低
缺点:耦合度高
分布式架构
根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,成为一个服务
优点:降低服务耦合、有利于服务升级拓展
缺点:成本上升,需要搭建集群等
分布式架构需要考虑的问题
- 服务拆分粒度如何
- 服务集群地址如何维护
- 服务之间如何实现远程调用
- 服务健康状态如何感知
微服务
微服务是一种经过良好架构设计的分布式架构方案。
微服务架构特征:
- 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责,避免重复业务开发
- 面向服务:微服务对外暴露业务接口
- 自治:团队独立、技术独立、数据独立、部署独立
- 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题
架构比较
微服务技术对比
服务拆分注意事项
- 不同微服务,不要重复开发相同业务
- 微服务数据独立,不要访问其它微服务的数据库
- 微服务可以将自己的业务暴露为接口,供其它微服务调用
案例
数据准备,两个数据库中分别有一个表
创建项目
demo链接:https://pan.baidu.com/s/19DcTpkvCdHixQaLCiAYbBw?pwd=zmbw
服务远程调用
RestTemplate
有一种远程调用方式为A模块访问B模块的某个方法url地址,然后B模块返回结果给A模块。
现在我们需要实现一个查询订单的功能,这里需要订单模块像用户模块发起一个查询用户的请求。发起请求我们可以采用RestTemplate来实现
首先在Order的引导类中将RestTemplate加载为Bean
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
@EnableFeignClients(basePackages = "com.zmt.clients")
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class, args);
}
@Bean
public RestTemplate restTemplate(){
return new RestTemplate();
}
}
在OrderService中使用RestTemplate
@Service
public class OrderService {
@Autowired
private OrderMapper orderMapper;
@Autowired
private RestTemplate restTemplate;
public Order queryOrderById(Long orderId) {
// 1.查询订单
Order order = orderMapper.findById(orderId);
//利用RestTemplate查询
String url="http://localhost:8081/user/"+order.getUserId();
//发送请求,得到JSON对象,如果给定需要转化的对象,则会转换为Java对象
User user = restTemplate.getForObject(url, User.class);
order.setUser(user);
// 4.返回
return order;
}
}
Eureka注册中心
RestTemplate存在的问题
采用硬编码的方式去调用服务。不符合分布式中集群的使用场景。
服务调用考虑的问题
- 服务消费者该如何获取服务提供者的地址信息?
- 如果有多个服务提供者,消费者该如何选择?
- 消费者如何得知服务提供者的健康状态?
Eureka的作用
当服务器启动后,会主动将自己的信息注册到Eureka-server中,当一个服务器需要远程调用另一个服务器中心方法时,需要从Eureka-server中拉去对应的地址信息,如果存在多个地址,则采用负载均衡的策略调用对应服务器。存活的服务器每三十秒向Eureka-server中发送一次心跳,当Eureka-server超过30秒没有接收到心跳,则会将对应的地址从注册中心中剔除。防止其他服务器调用到对应地址服务器。
搭建EurekaServer
新建一个Maven项目,并配置如下依赖
<parent>
<artifactId>cloud-demo</artifactId>
<groupId>cn.itcast.demo</groupId>
<version>1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.zmt</groupId>
<artifactId>eureka-serve</artifactId>
<dependencies>
<!-- Eureka服务 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<!-- 特别容易导错文件,启动报错一定检查pom是否导入正确 -->
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
</dependencies>
编写启动类,并添加注解
@SpringBootApplication
@EnableEurekaServer//开启Eureka服务
public class EurekaApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaApplication.class,args);
}
}
添加配置文件
server:
port: 8082
spring:
application:
name: eureka-serve # 服务名称
eureka:
client:
register-with-eureka: true #false 标识不向注册中心注册自己
fetch-registry: false # false 表示自己就是注册中心,维护服务实例即可,不需要去检索服务
service-url: # eureka的地址信息
defaultZone: http://127.0.0.1:8082/eureka/
随后启动服务
点击进入Eureka界面
服务注册
现在将用户模块与订单模块注册到Eureka-Server中,需要引入Eureka-Client依赖,并添加配置文件
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
spring:
application:
name: xxx-server
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:8082/eureka/
之后启动服务观察Eureka页面
此时实例数都分别为1,现在测试集群下的实例,一个模块启动多个服务。具体操作如下
启动后观察
服务发现
在RestTemplate加载为Bean的方法上添加@LocdBalanced注解(意为负载均衡策略),用服务提供者的服务名进行远程调用。
@Bean
@LoadBalanced//负载均衡策略
public RestTemplate restTemplate(){
return new RestTemplate();
}
public Order queryOrderById(Long orderId) {
// 1.查询订单
Order order = orderMapper.findById(orderId);
//将具体的地址修改为服务名称
String url="http://user-server/user/"+order.getUserId();
//发送请求,得到JSON对象,如果给定需要转化的对象,则会转换为Java对象
User user = restTemplate.getForObject(url, User.class);
order.setUser(user);
// 4.返回
return order;
}
访问地址观察结果
Ribbon负载均衡
负载均衡流程
使用RestTemplate访问服务名的地址实际上并不是真实的url地址,通过Ribbon将格式转化,从eureka-server中拉去需要转化的信息,然后返回服务列表由Ribbon来决定使用哪个地址
发现服务后,具体如何请求到对应的服务器上,接下来看源码分析
getServer()方法去做具体均衡策略
点击进去观察
进入chooseServer()方法观察
rule中存在如下几个实现类来决定如何实现分配
消费者通过服务者提供的服务名进行远程调用时,请求被Ribbon负载均衡所拦截,Ribbon去eureka-server拉取生产者的信息,eureka-server返回服务列表给Ribbon,由Ribbon选择访问哪个服务器具体拦截方式,通过RestTemplate上面的@LocdBalanced注解拦截,拦截通过RestTemplate发送的请求
负载均衡策略更改
1、全局更改(该消费者无论访问哪个服务都使用该策略)
在消费者的启动类下加入IRule的Bean(即,重写默认的IRule),return一个需要的负载均衡策略对象。
2、针对某一生产者的修改
在application.yml中配置生产者的服务名以及负载均衡策略。
user-server: #生产者服务名称
ribbon:
NFLoadBalancerRuleClassName: com.netflix.Loadbalancer.RandomRule #选择负载均衡策略
Ribbon加载方式
Ribbon默认采用懒加载方式。也就是用到的时候才会进行加载,这就决定了,第一次访问时,耗时会长一些。也可以在配置文件中选择饥饿加载。具体配置如下
ribbon:
eager-load:
enabled: true #开启饥饿加载
clients:
- user-server
- xxx-server