关于分布式系统的连环炮 为什么要进行系统拆分?拆分后不用dubbo可以吗? 系统越来越复杂,维护起来非常麻烦,各种冲突,各种合并,非常耗费时间,之间依赖复杂,异常处理起来非常麻烦,各种痛苦 拆分后每个服务都是一个单独的模块,一个人维护一个服务,每个机器部署一个服务, 避免了很多冲突,代码清爽 可以,但是我们如果调用其他服务的接口时会有很多问题需要考虑,负载均衡,超时重试等等一系列问题,dubbo是一个rpc框架,就是本地接口 进行调用,底层会帮我们处理负载均衡,服务上下线自动感知,超时重试等,不需要我们自己去考虑,直接使用就可以了 说一下dubbo的工作原理?注册中心挂了可以继续通信吗?说说一次rpc请求流程? ![]() dubbo一共分为10层,provider层,如果一个服务A部署在三台机器上,每台机器有各自的ip,服务会将自己的信息在注册中心进行注册,这样注册中心就有了这个服务的注册信息。 这时一个用户请求发送过来,然后消费者会连接注册中心拉取自己需要调用的服务,消费者就会获取到注册中心里需要调用的服务的信息,这时消费者和服务提供者都会有dubbo 生成的代理,消费者的代理通过负载均衡找到服务A其中的个代理获取需要的数据,服务A返回数据给自己的代理,服务A的代理在返回给消费者的代理,然后返回给消费者,最后返回 给用户,这样就是一个dubbo的执行流程。 如果注册中心挂了还是可以继续通信,第一次从注册中心中获取服务后,他会在本地缓存服务的注册信息,所以还是可以继续通信的 dubbo支持哪些网络协议以及序列化协议 dubbo使用长连接dubbo协议,单一长连接,NIO异步通信,传输数据量小,但是并发量高, 支持hessian,java二进制序列化,json,SOAP文本序列化多种序列化协议,但是hessian是默认的序列化协议。 ![]() dubbo负载均衡策略 (1)dubbo负载均衡策略 1)random loadbalance 默认情况下,dubbo是random load balance随机调用实现负载均衡,可以对provider不同实例设置不同的权重,会按照权重来负载均衡,权重越大分配流量越高,一般就用这个默认的就可以了。 2)roundrobin loadbalance 还有roundrobin loadbalance,这个的话默认就是均匀地将流量打到各个机器上去,但是如果各个机器的性能不一样,容易导致性能差的机器负载过高。所以此时需要调整权重,让性能差的机器承载权重小一些,流量少一些。 跟运维同学申请机器,有的时候,我们运气,正好公司资源比较充足,刚刚有一批热气腾腾,刚刚做好的一批虚拟机新鲜出炉,配置都比较高。8核+16g,机器,2台。过了一段时间,我感觉2台机器有点不太够,我去找运维同学,哥儿们,你能不能再给我1台机器,4核+8G的机器。我还是得要。 3)leastactive loadbalance 这个就是自动感知一下,如果某个机器性能越差,那么接收的请求越少,越不活跃,此时就会给不活跃的性能差的机器更少的请求 4)consistanthash loadbalance 一致性Hash算法,相同参数的请求一定分发到一个provider上去,provider挂掉的时候,会基于虚拟节点均匀分配剩余的流量,抖动不会太大。如果你需要的不是随机负载均衡,是要一类请求都到一个节点,那就走这个一致性hash策略。 (2)dubbo集群容错策略 1)failover cluster模式 失败自动切换,自动重试其他机器,默认就是这个,常见于读操作
3)failsafe cluster模式 出现异常时忽略掉,常用于不重要的接口调用,比如记录日志 4)failbackc cluster模式 失败了后台自动记录请求,然后定时重发,比较适合于写消息队列这种 5)forking cluster 并行调用多个provider,只要一个成功就立即返回 6)broadcacst cluster 逐个调用所有的provider (3)dubbo动态代理策略 |
关于分布式系统的连环炮一
最新推荐文章于 2021-05-24 15:55:56 发布