现在常用的开源分布式框架一个是阿里开源的dubbo，还有一个就是Spring cloud
分布式系统总结来说是将数据存储能力和计算能力分布到不同的服务器上，作为一个整体对外服务。分布式的概念可以理解成一种解决方案。
目的在于解决单台机器的故障问题，单机计算和 IO 性能问题，以及单机存储空间不足的问题。
系统可用性提升
传统的集中式计算或集中式存储，在遇见单点故障时，很容易造成整个服务不可用，分布式下的服务体系，单台机器有故障，不致于造成整个服务不可用。
系统并发能力提升
请求通过 Nginx负载均衡被分发到不同的服务器上，运行同样代码的服务器可以有 1 台 或 N 台，通常情况下会根据实际用户访问量随时增加机器。无论是数据库或者服务，都可以做到随时水平扩展。
系统容错能力
低延时
北京的用户请求自动分发到北京，上海的用户请求被分发到上海，服务器会根据用户的 IP 选择距离自己最近的机房，降低网络延时。
依赖网络
服务器间通信依赖网络，不可靠网络包括网络延时、丢包、中断、异步，一个完整的服务请求依赖一连串服务调用，任意一个服务节点网络出现问题，都可能造成请求失败。
维护成本高
传统单机式服务只需要维护一个站点就可以。分布式服务系统被拆分成若干个小服务，服务从 1 变为 几十个上百个服务后，增加运维成本
一致性，可用性，分区容错性无法同步
C —— 数据一致性 A —— 服务可用性 P —— 服务对网络分区故障的容错性，分布式框架很难都满足，一般符合其中两者;包括dubbo在内的其它使用zookeeper的分布式框架是满足CP，因为当客户端发送请求时，集群正在进行master选举或者半数以上的机器宕掉，服务可用性就很难做到；而对于持续集成，快速演化微服务来说，可用性就显得尤为重要，spring cloud由此诞生。
两者的区别也是各自的优劣
1、dubbo的服务注册与发现是用的zookeeper，spring cloud服务注册与发现用的是Eureka 后者各个节点之间都是平等的不存在主从关系，只要一个节点还在，就能保证服务正常调用，即使全部节点都死掉，服务与服务之间也能通过缓存调用信息，这就保证了微服务之间的调用足够的健壮
2、对于调用方式dubbo采用rpc的方式，代码耦合度高，spring cloud中的提供方和消费方通过http rest方式，不存在代码的强依赖显得更为灵活
