dubbo

框架设计理念




实战

服务端必须配置的 serviceConfig appcationConfig protocolConfig
客户端必须配置的 referenceConfig appcationConfig

dubbo 依赖 自带包

总结

timeout 优先级 由低到高

redis hash 存储 ,每个值都有效期,默认60秒,一般redis 有个心跳检测 30秒刷新一次.(用了一个定时线程池,有效期/2)
利用消息订阅的方式, ,客户端会检测服务状态 防止当服务断了之后调用失败.

服务端默认消失时间 是40秒(sesseion 会话时间)

dubbo 调用模块

异步调用 方法上面加 asyc=ture(<dubbo:method name=“**” async=‘true’/>)

dubbo 调用模块 rpc 网络传输

![在这里插入图片描述](https://img-blog.csdnimg.cn/9a4f8b70a91547338b0bf6d1a3d7968d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5Yev5a2QX2tpbmc=,size_20,color_FFFFFF,t_70,g_se,x_16

总结 重点 重点
1.spi 机制 就是在resouce 目录下面 创建一个 meta-inf 文件夹 dubbo(dubbo spi) service(java spi) dubbo.internal(dubbo 内部 spi) ,原理就是根句 接口名称创建文件夹 ,然后把实现类放进去.(根据接口找实现类) ServiceLoader serviceLoader = ServiceLoader.load(Animal.class);
final Iterator iterator = serviceLoader.iterator();
dubbo spi 增加扩展点的话 就多了一个key vlaue 形式 (负载均衡策略就是基于这种) ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(name)

区别:dubbo spi 可以 根据定义的key 获取,不需要轮巡

2. dubbo 服务注册发现流程: zookeeperRegister dosubscrbe里面有个 childChange 方法,当子节点发生改变的时候 ,会去在 registerDirectory 类里面调用 notify 方法(实现类 notifyListener) 还有就是当你启动时候也会取调用notify 方法/,去修改map 里面的url ,消费端会referenConfig依赖invoker接口 里面的invoke 方法,通过实现类 failbackClusterInvoker list方法去 directory取,也就是实现类 registerDirectory取.
   referenConfig 调用接口之前会去做一次检测 无效的url 会报错 提供者不存在 (dubooInvoker isAvailable)
   <referren check =“true”

3, rpc 调用层
rpc 框架 透明代理(javassist(默认的) .jdk), 负载均衡 , 容错机制, 调用方式 (异步调用, 同步调用《默认 true》,直接返回 作用域在方法上 dubbo -methed asnyc=“**” null 是直接返回)
rpc 调用(调用层 《传输协议 netty ,序列化(hessian 容错性 多一个少一个字段都可以,可以interge 转String 但是不支持 String 转Interge) ,编码》服务暴露层 《传输协议netty, 反序列化 ,解码》
)
4. dubbo 服务治理
划分界限

1. 将系统中独立的业务抽取出来，按业务的独立性进行垂直划分，抽象出基础服务层。
   2.基础服务为上游业务的功能 实现提供支撑，基础服务应用本身无状态，可随着系统的负荷灵活伸缩来提供服务能力。
   服务子系统的数量把控过多:可能划分过细，破坏业务子系统的独立性(如支付订单、退款订单、用户、账户),部署维护工作量大，独立进程占用内存多
   服务子系统的数量把控过少:没能很好地解耦,开发维护不好分工,升级维护影响面大
   服务子系统划分注意事项:

   不要出现A服务中的SQL需要链接查询到B服务中的表等情况，这样在A服务与B服务进行垂直拆库时就会出错
   服务子系统间避免出现环状的依赖调用 (A依赖B，B依赖C,C依赖A)
   服务子系统间的依赖关系不要过长（A服务依赖B服务,B服务依赖C服务，C依赖D服务…,最好不要超过三个,可能划分不好，或者过细）
   尽量避免分布式事务（尽量把做的事情放在一个服务内，即同一事务内）
   服务治理
   1. 调用链路自动生成

一个大型的分布式系统，或者说是用现在流行的微服务架构来说吧，分布式系统由大量的服务组成。那么这些服务之间互相是如何调用的？调用链路是啥？说实话，几乎到后面没人搞的清楚了，因为服务实在太多了，可能几百个甚至几千个服务。

那就需要基于 dubbo 做的分布式系统中，对各个服务之间的调用自动记录下来，然后自动将各个服务之间的依赖关系和调用链路生成出来，做成一张图，显示出来，大家才可以看到对吧。

dubbo-service-invoke-road.png
2. 服务访问压力以及时长统计

需要自动统计各个接口和服务之间的调用次数以及访问延时，而且要分成两个级别。

一个级别是接口粒度，就是每个服务的每个接口每天被调用多少次，TP50/TP90/TP99，三个档次的请求延时分别是多少；
第二个级别是从源头入口开始，一个完整的请求链路经过几十个服务之后，完成一次请求，每天全链路走多少次，全链路请求延时的 TP50/TP90/TP99，分别是多少。

这些东西都搞定了之后，后面才可以来看当前系统的压力主要在哪里，如何来扩容和优化啊。
3. 其它
服务分层（避免循环依赖）
调用链路失败监控和报警
服务鉴权
每个服务的可用性的监控（接口调用成功率？几个 9？99.99%，99.9%，99%）

5.失败重试和超时重试 ,服务降级

所谓失败重试，就是 consumer 调用 provider 要是失败了，比如抛异常了，此时应该是可以重试的，或者调用超时了也可以重试。配置如下：
<dubbo:reference id=“xxxx” interface=“xx” check=“true” //检查连接 async=“false” 异步调用 retries=“3” 失败重新尝试 timeout=“2000” 超时时间 mock=“return null” token =true //不能直连/>

RpcContext rpcContext = RpcContext.getContext(); 隐示传餐 可以判断调用链
rpcContext.setAttachment(key,value);

mock 服务 泛话提供

6.rpc 协议 包含 端口 ip 网络传输,序列化/反序列化 ,编码/解码

谈谈对Spring cloud 了解
Spring cloud 是一个微服务框架 经常和dubbo 比较,我的对他的认真 是sping boot的一个集合,他基于5大核心组件 来成为微服务框架 核心组件有 Eureka注册中心 他在服务启动的时候 会把 Eureka client里面的 服务 注册到Eureka server 里面,同时它也能拉去其他服务注册到服务,第二个核心组件 就是ribbon 他就是实现负载均衡到 从众多服务中选择一个服务进行调用.
第三个核心组件就是 regin他是动态代理的机制 利用注解 和选择的服务 动态拼接一个url 发起请求
第四个核心组件 也就是 hrystrix ,他主要提供里服务降级 服务熔断 ,以及限流.
第五个 核心组件 就是zuul 前端 移动端的调用都是经过 这个zuul 网关 ,然后在由网关转发给对应的服务
这个是我对Spring cloud 大概的了解

dubbo (网关 公司用的是 restExpress 继承 AbstractRoutes 重写 define 方法 )
(1)dubbo 是阿里开发的框架,底层就是一个rpc 远程调用的框架,只不过增加了 负载均衡,容错,异步调用,透明代理等 ,后来贡献给了apache ,他的设计模块 主要分为四大部分 provider 服务提供 ,consumer服务消费register 注册中心 我们公司用的zookeeper ,还有一个montier 监控 就是 dubbo admin 管理后台,源码里有,只要打包编译 ,再配置一个zk服务器 ip,就可以使用了,那里面配置都是永久节点 ,他的大致流程就是 服务启动的时候 provider 会把 请求的url 注册到 注册中心 ,在zk里面创建一个临时节点 ,然后 consumer 通过订阅 或者 provider 发生节点改变 被通知到方式 去注册中心获取 请求url
然后发起调用.

(2)我之前也看过部分源码 大概到看了一下调用流程 ,provider提供方 通过 serverconfig 里面的 erxport 这个方法 经过一系列的参数封装 走到 registerPotocol export 方法 里面调用 regiter 方法会创建一个 zookeeperRister对象 (会把url 放在 root 常量里) 然后调用 register 方法创建临时节点，还会掉用 dosubcribe 方法 (这个方法 新增 还有子节点修改都会调用) 获取 root 长量值, 通过里面的 notify 方法 走到 实现 NotifyListener 接口的 registerDirectory 类 的 重写的notify 方法 ,然后调用 setRouters 在。在abstractDirectory 的 routers 集合里面 进行保存.
consumer 方,通过reffernceConfig 依赖 invoker 接口 的实现类AbstractClusterInvoker的 invoker里面 ,以及在 list() 方法里获取 我们保存的url
还有进行负载均衡 和容错 类型的获取 返回 invoker ,通过 reffernceConfig .get 方法 init方法 创建代理对象返回这是一大概的注册 和发现流程.

(3)dubbo服务发现大概可以分为 两块 第一个服务调用模块 主要有负载均衡 ,服务容错,透明代理 异步调用,这些都是可以在 consumer.xml 里面配置, , 第二个是rpc 调用. 他的rpc 调用里面就是 序列化 编码 ,网络传输.我们公司是用的netty 网络传输协议,以及hessain 序列话的方式 .然后通过 socket 进行 请求返回.

这个就是我对dubbo 的一些了解.

dubbo Rpc

其中 Dubbo 支持的服务治理能力包括：服务发现注册、服务监控、集群容错、负载均衡、黑白名单、标签路由、条件路由、权重调节、服务降级等等。
调用模块主要分为 :负载均衡,容错,透明代理 ,异步调用(通过 future 自行获取《wait notiy》,同步交给IO Thread 请求返回)
长连接 是共享连接,如果服务I/o 多,可以增肌短连接