前置
衡量网站性能指标:
- 响应时间:一次请求花费时间
- 并发数:同时处理请求数
- 并发连接数:每秒建立总TCP数量
- 请求数:QPS一秒请求数
- 并发用户数:单位时间用户
- 吞吐量:单位时间处理请求数
- QPS:每秒查询数
- TPS:,每秒事务数
- 一个事务指一个客户机向服务器发送请求然后服务器完成响应的事务个数。
- 一个页面一次访问,只会一个TPS,但一次页面请求,会产生多次服务器的请求,多尔衮QPS
- QPS>=并发数>=TPS
大型互联网架构目标:
- 高性能:快速
- 高可用:保证正常访问
- 可伸缩:通过硬件增加/减少,提高/降低处理能力。
- 高可扩展:系统间耦合低
- 安全性:网站安全访问和加密数据
- 敏捷性:应变
集群和分布式: - 集群:很多人干一样的事
- 分布式:很多人干不一样的事。
1.0 什么是Dubbo
基于java的高性能,轻量级RPC框架,SOA(面向服务架构)=RPC+服务治理,18年更名为Apache Dubbo,成为一个易用,高性能的web和rpc框架,同时提供微服务的服务发现,流量治理,可观测,认证鉴权,工具与最佳实践。依托Dubbo,阿里提出了自己的DNS(Dubbo,Nacos,Sentinel(服务降级,限流))
官网:https://dubbo.apache.org/zh-cn/
github:http://github.com/apache/dubbo
2.0 SOA与微服务
单体架构问题:
- 热点问题:某子系统访问量大,导致其他子系统的访问出现问题。
- 扩展性差,新资源的分配力度不精确(文虎系统访问量,增加机器,增加服务器tomcat,但系资源不能精确到门户)
- 子模块耦合度高
- 维护部署成本高
- 技术栈受限,开发语言必须相同
水平扩展(集群):
优点:提高稳定性,并发能力
问题:同上
垂直架构+水平:
优点:每个子模块都地理部署在自己的tomcat(JVM进程)中,部分解决单体架构问题。
RPC(Remote Procedure Call)架构
由垂直结构演变而来,解决子系统模块功能调用(service - service)。跨进程(虚拟机)之间通过网络(通信方式[http(tomcat,Jetty,Resin),TCP(BIO,NIO,Netty,Mima)],协议[TCP需自定义协议],序列化[JDK,Protobuf])调用。
优点:可以复用其他系统功能。
问题:
- 某个子接口出现问题,整个调用链失败。
- 某个子接口访问量大怎么办?
SOA(Serivce-Oriented Architecture)面向服务架构
由RPC架构演化而来,代表框架Dubbo。SOA=RPC+服务治理
RPC:将多个模块共用的子接口抽取出来做成一个服务,独立部署并做水平扩展。
服务治理:注册中心,负载均衡,容错,配置中心,限流
进阶:企业服务总线ESB(解决跨语言调用,中间形态(Grpc,Probuf,Thrift IDL)
Dubbo快速入门
前置
安装zookeeper
实现步骤
- 创建服务提供者Provider模块
- 创建服务消费者Consumer模块
- 在服务提供模块编写UserServiceImpl提供服务
- 在服务消费者中UserController远程调用UserServiceImpl提供的您服务
- 启动测试
代码
https://gitee.com/xuyu294636185/dubbo-pro.git
Dubbo高级特性
dubbo-admin管理平台
dubbo-admin管理平台是一图形化管理界面。从注册中心中获取服务提供者/消费者进行配置管理。前端使用vue,后端使用springboot实现。
- 安装node.js
- 下载dubbo-admin:github.com/apache/dubbo-admin
- 修改dubbo-admi-server包下application.properties文件中zookeeper地址
- 在dubbo-admin-develop下重新打包:mvn clean package
- 在dubbo-admin-server下启动后端jar:java -jar .\dubbo-admin-0.1.jar
- 在dubbo-admin-ui下启动前端:npm run dev
- 访问localhost:8081
dubbo高级配置
序列化和反序列化
地址缓存
坑:注册中心挂了,服务是否可以正常访问?
可以,dubbo服务消费者在第一次调用时,会将服务提供方地址缓存到本地,以后在调用则不会访问注册中心。当服务提供者发生变化时,注册中心会通知服务消费者。
超时 重试
- 服务消费者在调用服务提供者的时候发生了阻塞,等待的情形,这时,服务消费者会一直等待下去。
- 在某个峰值时刻,大量请求都在同时请求服务消费者,会造成线程的大量堆积,势必会造成雪崩。
- dubbo利用超时机制来解决这个问题,设置一个超时时间,在这个时间段内,无法完成服务访问,则自动断开连接。
- 使用timeout属性配置超时时间,默认值1000,单位毫秒。建议配置在服务提供者这边。
@Service(timeout = 1000,retries = 0)
@Reference(timeout = 1000)
多版本
灰度发布:当新功能上线,会让一部分用户先使用新功能,用户反馈没问题再将所有用户迁移至新功能。
- dubbo使用version属性来设置和调用同一个接口的不同版本。
@Service(version = "v1.0")
负载均衡
- Random:按权重随机,默认值。
- RoundRobin:按权重轮询。
- LeastActive:最少活跃调用数,相同活跃数的随机。
- ConsistentHash:一致性hash,相同参数的请求总是发到同一提供者。
@Service(weight= "100")
@Reference(loadbalance = "random")
集群容错
- Failover Cluster:失败重试。默认2次,使用retries配置。一般用于读操作。
- Failfast Cluster:快速失败,只发起一次调用,失败立即报错,通常用于写操作。
- Failsafe Cluster:失败安全,出现异常时,直接忽略,返回一空结果。
- Failback Cluster:失败自动恢复,后台记录失败请求,定时重发。
- Forking Cluster:并行调用多个服务器,只要一个成功即返回。
- Broadcast Cluster:广播调用所有提供者,逐个调用,任意一台报错则报错。
服务降级
- mock=force:return null 消费方对该服务的方法调用都直接返回null值,不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
- mock=fail:return null 消费方对该服务的方法调用在失败后,再返回null,不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
@Reference(mock="force:return null")