dubbo

系统拆分：流程系统，拆分为画图系统(画图系统，流程文件系统)，单点登陆系统，后台管理系统，订单系统，基础模块系统，ELK系统，搜索系统，论坛系统

为什么要将系统拆分？

一个大系统几十万行代码，N个人维护一份代码，merge耗时；

每次上线都要做复杂的检查，很多异常要处理；

技术升级可能导致有些部分不能用；

发布时每个人都要看自己那块有没有问题

怎么拆，怎么分？

一个人负责2-3个系统，拆分系统不是一次成功的，慢慢拆。

Dubbo层次

1. service层，接口层，给服务提供者和消费者来实现的(namespaceHandller->Paser->service->ServiceBean)
2. config层，配置层，主要是对dubbo进行各种配置(ConfigBean)
3. proxy层,代理层，ref代理为Invoker，透明生成客户端的stub和服务端的skeleton
4. registry层，服务注册层，负责服务的注册与发现     zookeeper
5. cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例注册一个服务 FailOverCluster @Spi
6. monitor层，监控层，对rpc接口订单调用次数和调用时间的监控，重试超时，mock，降级
7. protocol层，远程调用层，封装rpc调用 @Spi DubboProtocol dubbo协议，netty(主从nio)，hessian序列化
8. exchange层，信息交换层，封装请求响应模式，同步转异步

注册中心挂了可以继续通信吗？

可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信

Dubbo协议

dubbo协议：默认就是走dubbo协议的，单一长连接，NIO异步通信，基于hessian作为序列化协议；适用的场景就是：传输数据量很小（每次请求在100kb以内），但是并发量很高

rmi协议：走java二进制序列化，多个短连接，适合消费者和提供者数量差不多，适用于文件的传输，一般较少用

dubbo负载均衡策略

默认情况下，dubbo是random load balance随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。

如何基于dubbo进行服务治理

1.调用链路自动生成
对各个服务之间的调用自动记录下来，然后自动将各个服务之间的依赖关系和掉哟个链路生成出来，做成一张图，显示出来
2.服务王文压力及时长统计，访问多少此，延时

服务降级

比如服务A调用服务B，结果服务B挂掉了，服务A重试几次失败就降级，dubbo有mock机制