| 关于分布式系统的连环炮 为什么要进行系统拆分？拆分后不用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动态代理策略 |
来源：https://www.cnblogs.com/zhuxiaopijingjing/p/12298059.html