Dubbo2.x版本学习笔记
1.分布式系统中的相关概念
1.1大型互联网项目架构目标
1. 用户体验:
- 美观
- 功能
- 速度
- 稳定性
2. 互联网项目特点:
- 用户多
- 流量大,并发高
- 海量数据
- 易受攻击
- 功能繁琐
- 变更快
3.高性能: 提供快速的访问体验。
4.大型互联网项目架构目标
衡量网站的性能指标:
响应时间:指执行一个请求从开始到最后收到响应数据所花费的总体时间。
并发数:指系统同时能处理的请求数量。
-
并发连接数:指的是客户端向服务器发起请求,并建立了TCP连接。每秒钟服务器连接的总TCP数量
-
请求数:也称为QPS(Query Per Second) 指每秒多少请求.
-
并发用户数:单位时间内有多少用户
吞吐量:指单位时间内系统能处理的请求数量。
-
QPS:Query Per Second 每秒查询数。
-
TPS:Transactions Per Second 每秒事务数。
一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。
一个页面的一次访问,只会形成一个TPS;但一次页面请求,可能产生多次对服务器的请求,就会有多个QPS
QPS >= 并发连接数 >= TPS
高性能:提供快速的访问体验。
高可用:网站服务一直可以正常访问。
可伸缩:通过硬件增加/减少,提高/降低处理能力。
高可扩展:系统间耦合低,方便的通过新增/移除方式,增加/减少新的功能/模块。
安全性:提供网站安全访问和数据加密,安全存储等策略。
敏捷性:随需应变,快速响应。
1.2集群和分布式
集群:很多“人”一起 ,干一样的事。
- 一个业务模块,部署在多台服务器上。
分布式:很多“人”一起,干不一样的事。这些不一样的事,合起来是一件大事。
- 一个大的业务系统,拆分为小的业务模块,分别部署在不同的机器上。
早期单机架构
集群
服务拆分
1.3架构演变
1.3.1单体架构
优点:简单:开发部署都很方便,小型项目首选
缺点:
- 项目启动慢
- 可靠性差
- 可伸缩性差
- 扩展性和可维护性差
- 性能低
1.3.2垂直架构
垂直架构是指将单体架构中的多个模块拆分为多个独立的项目。形成多个独立的单体架构。
垂直架构存在的问题:重复功能太多
1.3.3分布式架构
分布式架构是指在垂直架构的基础上,将公共业务模块抽取出来,作为独立的服务,供其他调用者消费,以实现服务的共享和重用。
RPC: Remote Procedure Call 远程过程调用。有非常多的协议和技术来都实现了RPC的过程。比如:HTTP REST风格,Java RMI规范、WebService SOAP协议、Hession等等。
分布式架构存在的问题:服务提供方一旦产生变更,所有消费方都需要变更。
1.3.4SOA架构
SOA:(Service-Oriented Architecture,面向服务的架构)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和契约联系起来。
ESB:(Enterparise Servce Bus) 企业服务总线,服务中介。主要是提供了一个服务于服务之间的交互。ESB 包含的功能如:负载均衡,流量控制,加密处理,服务的监控,异常处理,监控告急等等。
1.3.5微服务架构
微服务架构是在 SOA 上做的升华,微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
特点:
-
服务实现组件化:开发者可以自由选择开发技术。也不需要协调其他团队
-
服务之间交互一般使用REST API
-
去中心化:每个微服务有自己私有的数据库持久化业务数据
-
自动化部署:把应用拆分成为一个一个独立的单个服务,方便自动化部署、测试、运维
2.Dubbo概述
Dubbo 是 SOA时代的产物,SpringCloud 是微服务时代的产物
2.1Dubbo概念
Dubbo是阿里巴巴公司开源的一个高性能、轻量级的 Java RPC 框架。
致力于提供高性能和透明化的 RPC 远程服务调用方案,以及 SOA 服务治理方案。
2.2Dubbo架构
- 注册中心。
协调 Consumer 与 Provider 之间的地址注册与发现 - 配置中心。
存储 Dubbo 启动阶段的全局配置,保证配置的跨环境共享与全局一致性
负责服务治理规则(路由规则、动态配置等)的存储与推送。 - 元数据中心。
接收 Provider 上报的服务接口元数据,为 Admin 等控制台提供运维能力(如服务测试、接口文档等)
作为服务发现机制的补充,提供额外的接口/方法级别配置信息的同步能力,相当于注册中心的额外扩展
3.Dubbo快速入门
3.1Zookeeper安装
ZooKeeper服务器是用Java创建的,它运行在JVM之上。需要安装JDK 7或更高版本。
3.2Dubbo快速入门-Spring和SpringMVC整合
3.3改造
4.Dubbo高级特性
4.1 dubbo-admin 安装
- dubbo-admin 管理平台,是图形化的服务管理页面
- 从注册中心中获取到所有的提供者 / 消费者进行配置管理
- 路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡等管理功能
- dubbo-admin 是一个前后端分离的项目。前端使用vue,后端使用springboot安装 dubbo-admin 其实就是部署该项目
要保证开发环境有jdk,maven,nodejs
-
安装node(如果当前机器已经安装请忽略)
-
进入github,搜索dubbo-admin
-
解压后我们进入
…\dubbo-admin-develop\dubbo-admin-server\src\main\resources
目录,找到 application.properties 配置文件 进行配置修改 -
修改zookeeper地址
# centers in dubbo2.7 admin.registry.address=zookeeper://192.168.149.135:2181 admin.config-center=zookeeper://192.168.149.135:2181 admin.metadata-report.address=zookeeper://192.168.149.135:2181
admin.registry.address注册中心
admin.config-center 配置中心
admin.metadata-report.address元数据中心 -
在 dubbo-admin-develop 目录执行打包命令
mvn clean package
-
启动后端
切换到目录dubbo-Admin-develop\dubbo-admin-distribution\target>
执行下面的命令启动 dubbo-admin,dubbo-admin后台由SpringBoot构建
java -jar .\dubbo-admin-0.1.jar
-
前台后端
dubbo-admin-ui 目录下执行命令npm run dev
-
访问
浏览器输入。用户名密码都是root
4.2 dubbo-admin 使用
4.3序列化
两个机器传输数据,如何传输Java对象?
- dubbo 内部已经将序列化和反序列化的过程内部封装了
- 我们只需要在定义pojo类时实现Serializable接口即可
- 一般会定义一个公共的pojo模块,让生产者和消费者都依赖该模块。
4.4地址缓存
注册中心挂了,服务是否可以正常访问?
- 可以,因为dubbo服务消费者在第一次调用时,会将服务提供方地址缓存到本地,以后在调用则不会访问注册中心。
- 当服务提供者地址发生变化时,注册中心会通知服务消费者
4.5超时与重试
-
服务消费者在调用服务提供者的时候发生了阻塞、等待的情形,这个时候,服务消费者会一直等待下去。
-
在某个峰值时刻,大量的请求都在同时请求服务消费者,会造成线程的大量堆积,势必会造成雪崩。
-
dubbo 利用超时机制(建议在服务提供方设置)来解决这个问题,设置一个超时时间,在这个时间段内,无法完成服务访问,则自动断开连接。
-
@Service(timeout=3000,retires= 2)
-
使用timeout属性配置超时时间,默认值1000,单位毫秒。
- 设置了超时时间,在这个时间段内,无法完成服务访问,则自动断开连接。
- 如果出现网络抖动,则这一次请求就会失败。
- Dubbo 提供重试机制来避免类似问题的发生。
- @Service(timeout=3000,retires= 2)
- 通过 retries 属性来设置重试次数。默认为 2 次。
4.6多版本
@Service(version="v2.0")
@Reference(version="v2.0") //远程注入
private UService uservice;
dubbo 中使用version 属性来设置和调用同一个接口的不同版本
灰度发布:当出现新功能时,会让一部分用户先使用新功能,用户反馈没问题时,再将所有用户迁移到新功能。
4.7负载均衡
@Service(weight=200)
@Reference(loadbalance="random")
4.8集群容错
@Reference(cluster=" ")
集群容错模式:
- Failover Cluster:失败重试。默认值。当出现失败,重试其它服务器 ,默认重试2次,使用 retries 配置。一般用于读操作
- Failfast Cluster :快速失败,只发起1次调用,失败立即报错。通常用于写操作。
- Failsafe Cluster :失败安全,出现异常时,直接忽略。返回一个空结果。
- Failback Cluster :失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
- Forking Cluster :并行调用多个服务器,只要一个成功即返回。
- Broadcast Cluster :广播调用所有提供者,逐个调用,任意一台报错则报错。