假如我们的服务提供者user-service部署了多个实例,如图:

大家思考几个问题:
- order-service在发起远程调用的时候,该如何得知user-service实例的ip地址和端口?
- 有多个user-service实例地址,order-service调用时该如何选择?
- order-service如何得知某个user-service实例是否依然健康,是不是已经宕机?
假如我们的服务提供者user-service部署了多个实例,如图:
大家思考几个问题:
基于Netflix Feign 实现,整合了Spring Cloud Ribbon 与Spring Cloud Hystrix, 它提供了一种声明式服务调用的方式。
先来看我们以前利用RestTemplate发起远程调用的代码:
存在下面的问题:
Spring Cloud Gateway 项目是基于 Spring 5.0,Spring Boot 2.0 和 Project Reactor 等响应式编程和事件流技术开发的网关,它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。
Gateway网关是我们服务的守门神,所有微服务的统一入口。
网关的核心功能特性:
架构图:
在微服务架构中,服务与服务之间通过远程调用的方式进行通信,一旦某个被调用的服务发生了故障,其依赖服务也会发生故障,此时就会发生故障的蔓延,最终导致灾难性雪崩效应。Hystrix实现了断路器模式,当某个服务发生故障时,通过断路器的监控,给调用方返回一个错误响应,而不是长时间的等待,这样就不会使得调用方由于长时间得不到响应而占用线程,从而防止故障的蔓延。Hystrix具备服务降级、服务熔断、线程隔离、请求缓存、请求合并及服务监控等强大功能。
什么是灾难性的雪崩效应?我们通过结构图来说明,如下
上一节中,我们添加了@LoadBalanced注解,即可实现负载均衡功能,这是什么原理呢?
SpringCloud底层其实是利用了一个名为Ribbon的组件,来实现负载均衡功能的。
那么我们发出的请求明明是http://userservice/user/1,怎么变成了http://localhost:8081的呢?
任何分布式架构都离不开服务的拆分,微服务也是一样。
这里我总结了微服务拆分时的几个原则:
随着互联网行业的发展,对服务的要求也越来越高,服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢?
单体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署。
单体架构的优缺点如下:
分布式系统中设计分布式 ID 对于确保订单、用户或记录等实体的唯一性至关重要。
Dubbo是一个分布式、高性能、透明化的RPC服务框架,提供服务自动注册、自动发现等高效服务治理方案,可以和Spring框架无缝集成。Dubbo最常用的应用就是远程调用。
Dubbo中服务端最核心的对象有四个:
要介绍分布式锁,首先要提到与分布式锁相对应的是线程锁、进程锁。