谈谈自己对分布式的理解

现在常用的开源分布式框架一个是阿里开源的dubbo，还有一个就是Spring cloud

最初的服务化解决方案是  相同服务提供一个统一的域名，然后客户端发送http请求，由Nginx负责请求分发和跳转，耦合了服务调用逻辑，相当于一个重量级的ESB；有以下几个缺点：

1：作为消费者不知道由哪个服务实例提供服务

2:  无法观测到服务消费者和服务提供者之间的通信频率和调运行状况

3：消费者的失败重发，加大了服务开发难度，Nginx没有统一的管理策略

综合种种原因，分布式框架诞生，dubbo就是一款很优秀的开源框架；他集成了服务注册中心和服务监控中心

服务提供者通过服务注册中心注册自己需要提供的服务，消费者则从注册中心订阅自己需要的服务；监控中心则是

统计消费者和提供者之间的通信频率、调度时间、运行状况

从框架的自身结构来看，dubbo也有其缺点

1：服务提供者和服务消费，很依赖第三方组件（zookeeper,redis）,一旦该组件出了问题，框架本身也会启不起来

2：消费者严重依赖服务提供者，双方代码耦合度较高，一旦服务提供者在导jar包的过程中出错，程序就会出现问题

分布式框架系统定理 ： C —— 数据一致性   A ——  服务可用性  P —— 服务对网络分区故障的容错性，分布式框架很难都满足，一般符合其中两者;包括dubbo在内的其它使用zookeeper的分布式框架是满足CP，因为当客户端发送请求时，集群正在进行master选举或者半数以上的机器宕掉，服务可用性就很难做到；而对于持续集成，快速演化微服务来说，可用性就显得尤为重要，spring cloud由此诞生

spring cloud和dubbo的区别

两者的区别也是各自的优劣

1：dubbo的服务注册与发现是用的zookeeper，spring cloud服务注册与发现用的是Eureka 后者各个节点之间都是平等的不存在主从关系，只要一个节点还在，就能保证服务正常调用，即使全部节点都死掉，服务与服务之间也能通过缓存调用信息，这就保证了微服务之间的调用足够的健壮

2：对于调用方式dubbo采用rpc的方式，代码耦合度高，spring cloud中的提供方和消费方通过http  rest方式，不存在代码的强依赖显得更为灵活