dubbo笔记

最新推荐文章于 2023-02-14 10:27:26 发布

原创最新推荐文章于 2023-02-14 10:27:26 发布

· 166 阅读

版权

1.架构分类

1)单一应用架构 1-10
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
2)垂直应用架构 10-1000
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
3)分布式服务架构 1000-10000
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
4)流动计算架构 10000+
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

2.Dubbo功能

软负载均衡、故障切换Failover、自动画出应用间的依赖关系图、辅助容量规划。
容量规划方法：，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

3.Dubbo架构

1)角色：provider/consumer/registry/monitor/container
服务容器负责启动，加载，运行服务提供者。
服务提供者和消费者只在启动时与注册中心交互。
注册中心使用长连接推送提供者变更数据给消费者。
服务消费者，基于软负载均衡算法选取提供者。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外。
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复.
2)升级流式计算架构
Deployer   自动部署服务的本地代理
Repository   仓库用于存储服务应用发布包
Scheduler   调度中心基于访问压力自动增减服务提供者
Admin   统一管理控制台
Registry   服务注册与发现的注册中心
Monitor   统计服务的调用次数和调用时间的监控中心

4.策略

1)注册中心
Dubbo 支持多注册中心。
Multicast注册中心：去中心化，不需要安装注册中心 multicast://224.5.6.7:1234
Zookeeper注册中心 zookeeper://224.5.6.7:2181
Redis注册中心：要求服务器时间同步，用于检查心跳过期脏数据
2)协议
Dubbo 允许配置多协议。
Dubbo协议：采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用）；在大文件传输时，单一连接会成为瓶颈。
Rmi协议：可与原生RMI互操作，基于TCP协议
Hessian协议：可与原生Hessian互操作，基于HTTP协议，需hessian.jar支持，http短连接的开销大
3)NIO框架
Netty Transporte，JBoss的NIO框架，性能较好（推荐使用）；一次请求派发两种事件，需屏蔽无用事件
Mina Transporter，待发送消息队列派发不及时，大压力下，会出现FullGC
Grizzly Transporter，Sun的NIO框架，应用于GlassFish服务器中；线程池不可扩展，Filter不能拦截下一Filter
4)序列化
Hessian Serialization 性能较好，多语言支持（推荐使用）；Hessian的各版本兼容性不好
Dubbo Serialization 通过不传送POJO的类元信息，在大量POJO传输时，性能较好；当参数对象增加字段时，需外部文件声明
Json Serialization 缺省采用FastJson解析，性能较差
Java Serialization Java原生支持，性能较差
5)代理
Javassist ProxyFactory、Jdk ProxyFactory
6)故障转移策略
Failover Cluster：失败自动切换，当出现失败，重试其它服务器，通常用于读操作（推荐使用）；重试会带来更长延迟。
Failfast Cluster：快速失败，只发起一次调用，失败立即报错,通常用于非幂等性的写操作；如果有机器正在重启，可能会出现调用失败
Failsafe Cluster：失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作；调用信息丢失
Failback Cluster：失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作；不可靠，重启丢失
Forking Cluster：并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作；需要浪费更多服务资源
Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错，通常用于更新提供方本地状态；速度慢，任意一台报错则报错
7)负载均衡策略
Random LoadBalance：随机，按权重设置随机概率（推荐使用）；在一个截面上碰撞的概率高，重试时，可能出现瞬间压力不均。
RoundRobin LoadBalance：轮询，按公约后的权重设置轮询比率；存在慢的机器累积请求问题，极端情况可能产生雪崩
LeastActive LoadBalance：最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差，使慢的机器收到更少请求；不支持权重，在容量规划时，不能通过权重把压力导向一台机器压测容量
ConsistentHash LoadBalance：一致性Hash，相同参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动；压力分摊不均
8)容器
Spring Container：自动加载META-INF/spring目录下的所有Spring配置
Jetty Container：启动一个内嵌Jetty，用于汇报状态；大量访问页面时，会影响服务器的线程和内存
Log4j Container：自动配置log4j的配置，在多进程启动时，自动给日志文件按进程分目录；用户不能控制log4j的配置，不灵活
9)配置覆盖关系
方法级优先，接口级次之，全局配置再次之。
如果级别一样，则消费方优先，提供方次之。
建议由服务提供方设置超时。

5.特性

1)dubbo支持多注册中心，多协议。(registry,protocol)
2)服务分组，分组聚合(group，merger)
当一个接口有多种实现时，可以用 group 区分。
接口一样，但有多种实现，用group区分，现在消费方需从每种group中调用一次返回结果，合并结果返回，可以使用分组聚合。
3)支持多版本以方便升级(version)
建议升级步骤：
在低压力时间段，先升级一半提供者为新版本
再将所有消费者升级为新版本
然后将剩下的一半提供者升级为新版本
4)线程策略(dispatcher,threadpool)
<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />
Dispatcher
all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
ThreadPool
fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
cached 缓存线程池，空闲一分钟自动删除，需要时重建。
limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)
5)负载均衡策略(loadbalance)
a.Random LoadBalance(默认)
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
b.RoundRobin LoadBalance
轮询，按公约后的权重设置轮询比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
c.LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
d.ConsistentHash LoadBalance
一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
6)支持参数验证(validation)
7)可以通过url参数，直连某一提供者。(url)
8)集群容错(cluster)
Failover Cluster(默认)
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
9)启动时检查(check)
Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true"。
10)协议
dubbo://
Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
因 dubbo 协议采用单一长连接，假设网络为千兆网卡，根据测试经验数据每条连接最多只能压满 7MByte(不同的环境可能不一样，供参考)，理论上 1 个服务提供者需要 20 个服务消费者才能压满网卡。
hessian://
Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，短连接，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现。
适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。
适用场景：页面传输，文件传输，或与原生hessian服务互操作
webservice://
基于ApacheCXF实现，可以和原生 WebService 服务互操作。
rest://
实现的REST调用支持
REST服务中虽然建议使用HTTP协议中四种标准方法POST、DELETE、PUT、GET来分别实现常见的“增删改查”，
但实际中，我们一般情况直接用POST来实现“增改”，GET来实现“删查”即可（DELETE和PUT甚至会被一些防火墙阻挡）。
11)注册中心
zookeeper 注册中心
服务提供者启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址
服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址
监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。
12)优雅停机
Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果用户使用 kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。
13)支持粘性服务

6.升级到Dubbo

1)XML方式
原有xml配置文件

<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />  
<bean id=“xxxAction” class=“com.xxx.XxxAction”>  
    <property name=“xxxService” ref=“xxxService” />  
</bean>

升级后的配置文件

remote-provider.xml:  
<!-- 用dubbo协议在20880端口暴露服务 -->  
<dubbo:protocol name="dubbo" port="20880" />  
<!-- 和本地服务一样实现远程服务 -->  
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />   
<!-- 增加暴露远程服务配置 -->  
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” />

remote-consumer.xml:  
<!-- 增加引用远程服务配置 -->  
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />  
<!-- 和本地服务一样使用远程服务 -->  
<bean id=“xxxAction” class=“com.xxx.XxxAction”>   
    <property name=“xxxService” ref=“xxxService” />  
</bean>

完整配置文件

<?xml version="1.0" encoding="UTF-8"?>  
<beans xmlns="http://www.springframework.org/schema/beans"  
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
    xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"  
    xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans-4.3.xsd        http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">  
    <!-- 提供方应用信息，用于计算依赖关系 -->  
    <dubbo:application name="hello-world-app"  />  
    <!-- 使用multicast广播注册中心暴露服务地址 -->  
    <dubbo:registry address="multicast://224.5.6.7:1234" />

    <!-- 用dubbo协议在20880端口暴露服务 -->  
    <dubbo:protocol name="dubbo" port="20880" />  
    <!-- 声明需要暴露的服务接口 -->  
    <dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" />  
    <!-- 和本地bean一样实现服务 -->  
    <bean id="demoService" class="org.apache.dubbo.demo.provider.DemoServiceImpl" />  
</beans>

2)注解方式
@Configuration
@EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.simple.annotation.impl")
@PropertySource("classpath:/spring/dubbo-provider.properties")
static public class ProviderConfiguration {...}