1、应用架构的演进过程
单一应用架构
当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是关键。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dYeHu8Rt-1639100619742)(img/3.png)]
垂直应用架构
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的Web框架(MVC)是关键。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2N21f7hC-1639100619745)(img/4.png)]
分布式服务架构
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式服务框架(RPC)是关键
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-x8K5CwqN-1639100619748)(img/5.png)]
面向服务架构
流动计算架构
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VquHdgWB-1639100619749)(img/14.png)]
微服务架构:
与流动计算架构很相似,除了具备流动计算架构优势外,微服务架构中的微服务可以独立部署,独立发展。且微服务的开发不会限制于任何技术栈。微服务架构的最佳实践是SpringCloud。
2、RPC是什么意思,你怎么理解
介绍
Remote Procedure Call 远程过程调用,是分布式架构的核心,按响应方式分如下两种:
1、同步调用
客户端调用服务方方法,等待直到服务方返回结果或者超时,再继续自己的操作
2、异步调用
客户端把消息发送给中间件,不再等待服务端返回,直接继续自己的操作
RPC是一种进程间的通信方式
它允许应用程序调用网络上的另一个应用程序中的方法
对于服务的消费者而言,无需了解远程调用的底层细节,是透明的
注意:
RPC并不是一个具体的技术,而是指整个网络远程调用过程。
RPC是一个泛化的概念,严格来说一切远程过程调用手段都属于RPC范畴。各种开发语言都有自己的RPC框架。Java中的RPC框架比较多,广泛使用的有RMI、Hessian、Dubbo等
RPC组件
简单来说一个RPC架构里包含如下4个组件:
1、 客户端(Client):服务调用者
2、 客户端存根(Client Stub):存放服务端地址信息,将客户端的请求参数打包成网络消息,再通过网络发送给服务方
3、 服务端存根(Server Stub):接受客户端发送过来的消息并解包,再调用本地服务
4、 服务端(Server):服务提供者。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ckzthFvh-1639100619751)(img/15.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-N1NCST0l-1639100619752)(img/16.png)]
3、Dubbo是什么?有什么作用?
是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源Java RPC框架,可以和Spring框架无缝集成。
作用:
提供了三大核心能力:
1、面向接口的远程方法调用
2、智能容错和负载均衡
3、服务自动注册和发现
4、Dubbo的架构以及都有哪些节点角色?
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uwACYckL-1639100619753)(img/17.png)]
节点角色说明:
节点 | 角色名称 |
---|---|
Provider | 暴露服务的服务提供方 |
Consumer | 调用远程服务的服务消费方 |
Registry | 服务注册与发现的注册中心 |
Monitor | 统计服务的调用次数和调用时间的监控中心 |
Container | 服务运行容器 |
虚线都是异步访问,实线都是同步访问
蓝色虚线:在启动时完成的功能
红色虚线(实线)都是程序运行过程中执行的功能
调用关系说明:
- 服务容器负责启动,加载,运行服务提供者。
- 服务提供者在启动时,向注册中心注册自己提供的服务。
- 服务消费者在启动时,向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
- 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
- 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。
5、介绍下Dubbo的负载均衡吧
负载均衡(Load Balance):其实就是将请求分摊到多个操作单元上进行执行,从而共同完成工作任务。
在集群负载均衡时,Dubbo 提供了多种均衡策略(包括随机random、轮询roundrobin、最少活跃调用数leastactive),缺省为random随机调用。
配置负载均衡策略,既可以在服务提供者一方配置,也可以在服务消费者一方配置,两者取一
- 服务提供者指定负载均衡策略
@Service(loadbalance = "roundrobin")
public class UserServiceImpl implements UserSerivce {
}
- 服务消费者指定负载均衡策略
@Controller
@RequestMapping("/user")
public class UserController {
@Reference(loadbalance = "roundrobin")
private UserSerivce userService;
}
6、Dubbo 超时时间设置怎么设置,服务调用超时问题如何解决
Dubbo 超时时间设置有两种方式:
1、服务提供者端设置超时时间,在Dubbo 的用户文档中,推荐如果能在服务端多配置就尽量
多配置,因为服务提供者比消费者更清楚自己提供的服务特性。
2、服务消费者端设置超时时间,如果在消费者端设置了超时时间,以消费者端为主,即优先
级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时,服务端线程不会
定制,会产生警告
7、dubbo 在调用服务不成功时,默认是会重试几次?
2次
8、在一个项目里引用多个服务,怎么保证你引用的那个服务就是那个服务
你打开不是有监控中心,你可以看服务后台它注册了多少个服务,消费端有多
少个,提供者有多少个。端口号不同,一个服务启动起来会占用一个端口,而且是一个java
jvm 的进程。如果一台服务分配到两三台机器,会给负载均衡策略的。
9、为什么需要服务治理
- 过多的服务URL配置困难
- 负载均衡分配节点压力过大的情况下也需要部署集群
- 服务依赖混乱,启动顺序不清晰
- 过多服务导致性能指标分析难度较大,需要监控
10、Dubbo的注册中心集群挂掉,发布者和订阅者之间还能通信么?
可以的,启动dubbo时,消费者会从zookeeper拉取注册的生产者的地址接口等数据,缓存在本地。
每次调用时,按照本地存储的地址进行调用。
注册中心对等集群,任意一台宕机后,将会切换到另一台;注册中心全部宕机后,服务的提供者和消费者仍能通过本地缓存通讯。服务提供者无状态,任一台 宕机后,不影响使用;服务提供者全部宕机,服务消费者会无法使用,并无限次重连等待服务者恢复;
挂掉是不要紧的,但前提是你没有增加新的服务,如果你要调用新的服务,则是不能办到的。
11、Dubbo与Spring的关系/项目中怎么用的dubbo
关系:
Dubbo采用全Spring配置方式,透明化接入应用,对应用没有任何API侵入,只需用Spring加载Dubbo的配置即可,Dubbo基于Spring的Schema扩展进行加载
项目中的使用:
Dubbo 是依赖spring 容器的,所以我们在使用的时候是结合spring 用的,我们在配置服务的
提供者的项目中,在Spring 的xml 配置文件中写下面标签注册到注册中心,在dubbo 标签中
配置服务提供者端口号,服务提供名称,注册中心的地址和端口号,下面红色代码不用
说.<dubbo:protocol name="dubbo" port="20887"></dubbo:protocol>(服务提供者端口号)
<dubbo:application name="youlexuan-cart-service"/>
<dubbo:registry address="zookeeper://192.168.177.129:2181"/>
<dubbo:annotation package="com.youlexuan.cart.service.impl" />
调用是通过,在springmvc.xml 文件中配置<!-- 引用dubbo 服务-->
<dubbo:application name="youlexuan-cart-web" />
<dubbo:registry address="zookeeper://192.168.177.129:2181"/>
<dubbo:annotation package="com.youlexuan.cart.controller" />
用dubbo 的好处是:把项目拆分成各个独立的小工程,通过接口调用方式,互相交互数据,
可以单独进行部署和升级,这样就减少了他们直接的耦合性和代码的复用性。还可以针对不
同模块采用不同的部署策略,比如订单模块并发比较高,所以可以把订单模块这个war 包,
单独部署多套,都注册到同一个zookeeper 中。当客户端调用时,zookeeper 会帮忙进行负
载处理。
12、Dubbo使用的是什么通信框架
默认使用NIO Netty框架
13、Dubbo的集群容错方案有哪些?
- Failover Cluster
失败自动切换,当出现失败,重试其它服务器。通常用于读操作,但重试会带来更长延迟。
- Failfast Cluster
快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
- Failsafe Cluster
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作
- Failback Cluster
失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作
Dubbo默认采用的是:Failover Cluster
14、Dubbo在安全机制方面是如何解决?
Dubbo通过Token令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo还提供服务黑白名单,来控制服务所允许的调用
15、Dubbo和Spring Cloud的关系?
Dubbo 是 SOA 时代的产物,它的关注点主要在于服务的调用,流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代,考虑的是微服务治理的方方面面,另外由于依托了 Spirng、Spirng Boot 的优势之上,两个框架在开始目标就不一致,Dubbo 定位服务治理、Spirng Cloud 是一个生态体系。
最大的区别:
Dubbo底层是使用Netty这样的NIO框架,是基于TCP协议传输的,配合以Hession序列化完成RPC通信。
而SpringCloud是基于Http协议+Rest接口调用远程过程的通信,相对来说,Http请求会有更大的报文,占的带宽也会更多。但是REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖。
16、dubbo的直连方式
即在服务消费方配置服务提供方的位置信息。
1、xml 配置方式:
<dubbo:reference id="userService" interface="com.kaola.service.UserService"
url="dubbo://localhost:20880" />
2、注解方式:
@Reference(url = "127.0.0.1:20880")
HelloService helloService;
17、dubbo的健壮性体现
1. 监控中心宕掉不影响使用,只是丢失部分采样数据
2. 数据库宕掉后,注册中心仍能通过缓存提供服务列表查询,但不能注册新服务
3. 注册中心对等集群,任意一台宕掉后,将自动切换到另一台
4. 注册中心全部宕掉后,服务提供者和服务消费者仍能通过本地缓存通讯
5. 服务提供者无状态,任意一台宕掉后,不影响使用
6. 服务提供者全部宕掉后,服务消费者应用将无法使用,并无限次重连等待服务提供者恢
复我们前面提到过:注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和
消费者只在启动时与注册中心交互,注册中心不转发请求,压力较小。
用,只是丢失部分采样数据
2. 数据库宕掉后,注册中心仍能通过缓存提供服务列表查询,但不能注册新服务
3. 注册中心对等集群,任意一台宕掉后,将自动切换到另一台
4. 注册中心全部宕掉后,服务提供者和服务消费者仍能通过本地缓存通讯
5. 服务提供者无状态,任意一台宕掉后,不影响使用
6. 服务提供者全部宕掉后,服务消费者应用将无法使用,并无限次重连等待服务提供者恢
复我们前面提到过:注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和
消费者只在启动时与注册中心交互,注册中心不转发请求,压力较小。