关于分布式系统的连环炮

为什么要进行系统拆分？拆分后不用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模式
失败自动切换，自动重试其他机器，默认就是这个，常见于读操作

• failfast cluster模式
  
  

一次调用失败就立即失败，常见于写操作
3）failsafe cluster模式
出现异常时忽略掉，常用于不重要的接口调用，比如记录日志
4）failbackc cluster模式
失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种
5）forking cluster
并行调用多个provider，只要一个成功就立即返回
6）broadcacst cluster
逐个调用所有的provider
（3）dubbo动态代理策略

关于分布式系统的连环炮

为什么要进行系统拆分？拆分后不用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模式
失败自动切换，自动重试其他机器，默认就是这个，常见于读操作

• failfast cluster模式
  
  

一次调用失败就立即失败，常见于写操作
3）failsafe cluster模式
出现异常时忽略掉，常用于不重要的接口调用，比如记录日志
4）failbackc cluster模式
失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种
5）forking cluster
并行调用多个provider，只要一个成功就立即返回
6）broadcacst cluster
逐个调用所有的provider
（3）dubbo动态代理策略