1 Dubbo简述
概述:是一个RPC框架
RPC:远程方法(过程)调用
本地调用:之前的调用方式
表现层、业务层、持久层最终都存在于一个war包中。
远程调用(RPC):分布式系统中的调用方式
表现层和业务层处于不同的服务器下,此时在进行调用的时候就属于远程调用。
为什么要存在这种远程调用呢?主要是和系统架构的发展有直接的关系。
为什么需要不断对系统架构做调整?主要原因就是因为软件行业的迅速崛起。现在我们的项目主要是以互联网项目为主导。
2 互联网项目
2.1 互联网项目特点
互联网项目和传统项目的区别?
从用户群体的角度而言。
如果这个项目可以被任意的用户进行访问,那么这个项目就是互联网项目!(淘宝、京东、斗地主、货拉拉….)
如果这个项目只能被公司的内部人员进行访问,那么这个项目就是传统项目!(财务报销系统、OA、CRM系统…)
互联网项目特点?
- 用户多
- 流量大,并发高
- 海量数据
- 易受攻击
- 功能繁琐
- 变更快
2.2 互联网项目的目标
- 高性能
- QPS: Query Per Second每秒查询数。
- TPS: Transactions Per Second每秒事务(一个事务是指一 个客户机向服务器发送请求然后服务器做出反应的过程)数。
- 高可用:当某一台服务器出现宕机以后,不影响整个系统的访问。(部署集群)
- 可伸缩:可以灵活的根据当前系统的访问流量进行服务的动态扩缩容
- 高可靠扩展:可以灵活的给系统添加新的模块
2.3 分布式和集群的区别
集群:多台服务器干一件事情,干的事情都是相同的事情
分布式:多台服务器干一件事情,但是每一台服务器干的事情是不一样的
2.4 架构的演进(理解)
3 Dubbo简介
Dubbo是阿里巴巴公司开源的一个高性能、轻量级的Java RPC框架。
官网: htp://ubbo.apache.orgo
架构:
consumer:服务的消费方(我们自己所开发的应用)
provider:服务的提供方(我们自己所开发的应用)
registry:注册中心(一般情况下不需要我们自己开发,使用第三方的软件(Redis、zookeeper)作为注册中心即可)
Monitor:监控中心(负责对整个远程调用过程进行监控)
5 入门案例
5.1 服务提供方
注意几点:
1、打包方式是war
2、需要将开发的service注册到注册中心中
3、在spring的配置文件中去配置相关信息
1 |
|
5.2 服务消费方
注意几点:
1、打包方式是war
2、远程注入service,发起调用
3、需要在spring mvc的配置文件中去配置注册中心地址
1 |
|
6 高级特性
6.1 dubbo-admin(可视化的管理平台)
参考安装文档。
6.2 序列化
dubbo中传输对象是怎么实现的?
通过序列化进行实现的,但是一个对象能否被序列化有一个前提:这个对象必须去实现Serializable接口。
1 | public class User implements Serializable {...} |
6.3 地址缓存
注册中心挂了,服务是否可以正常访问?
可以,因为dubbo服务消费者在第一-次调用时,会将服务提供方地址缓存到本地,以后在调用则不会访问注册中心。
6.4 超时
当服务消费方去调用服务提供方的时候,如果在规定的时间之内服务提供方没有给出响应,此时就会报错。这个规定的时间就是超时时间。
默认情况下超时时间为1s。
修改超时时间:
1、服务提供方配置超时时间:@Service(timeout = 3000 , retries = 0)
2、服务消费方配置超时时间:@Reference(timeout = 1000)
如果两者都进行了配置,以服务消费方为准。但是在开发的时候一般只需要在一方进行配置:服务的提供方
6.5 重试
重试:当请求超时以后,再次发起请求。
默认情况下是重试2次。
配置重试次数:@Service(timeout = 3000 , retries = 1)
6.6 灰度发布
现在我们需要给线上的项目添加一个新的功能,新功能添加完毕以后我们是否需要将所有的线上所有的用户都切换到新功能呢?
并不是说直接让所有的用户都切换到新功能上,而是让一部分的用户先切换到新功能上。等待这个功能测试的都没有问题了,此时才会把所有的用户都切换过来。就相当于是让线上的部
分用户对新功能进行生产环境的测试。而我们上述所描述的事情就是灰度发布。
dubbo如何去实现灰度发布?
服务的提供方:
服务的消费方:
6.7 负载均衡
服务的提供方是可以部署多份的,当部署多份以后服务的消费方就需要按照指定的负载均衡算法进行请求了。
常见的负载均衡算法:
**Random:**按权重随机,默认值。按权重设置随机概率。
RoundRobin: 按权重轮询。
LeastActive: 最少活跃调用数,相同活跃数的随机。
**ConsistentHash:**一 致性Hash,相同参数的请求总是发到同一提供者。
给服务提供方设置权重:
服务的消费方去指定负载均衡算法:
1 | //@Reference(loadbalance = "roundrobin") |
所有的负载均衡算法都是继承AbstractLoadBalance
每一个负载均衡算法都存在对应的名称,名称是这个负载均衡算法所对应的name属性值:
6.8 集群容错
容错机制:当服务的消费方调用服务的提供方失败以后,对这一次调用应该如何处理,这种机制就是容错机制。
dubbo中的容错机制:
1 | Failover Cluster:失败重试。默认值。当出现失败,重试其它服务器,默认重试2次,使用retries配置。一般用于读操作 |
指定容错机制:
消费者配置
1 | //远程注入 |
6.9 服务降级
服务降级:当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或高效运作。
服务降级方式:
mock= force:return null:表示消费方对该服务的方法调用都直接返回null值,不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
mock=fail:return null:表示消费方对该服务的方法调用在失败后,再返回null值,不抛异常。用来容忍不重要服务不稳定时对调用方的影响
使用服务降级:
消费方配置
1 | //远程注入 |