前言
今天学习Spring Cloud的时候，看到目前主流的微服务架构有两套解决方案：Dubbo + Zookeeper与SpringCloud。
两种方案都可以很方便的进行微服务开发，其中的区别在于SpringCloud组件多，功能完备，全家桶式，基本微服务中会遇到的问题都有相应的解决方案，在通信方面SpringCloud使用的是http。
Dubbo+Zookeeper使用的是RPC，组件较少，功能非完备（但是可以自己去找相应的解决方案），并且现在交由Apache进行孵化，后面应该会实现功能的完备。就个人来说，认为Dubbo+Zookeeper的侵入性更少，且调用过程更简单，更加类似服务之间的调用，两种方案后续就会进行学习。
回顾了一下，突然发现已经记不清Dubbox + Zookeeper了，于是借此机会整理一下。
一、Dubbox 框架
1.1、Dubbox 简介
Dubbox是一个分布式服务框架，其前身是阿里巴巴开源项目Dubbo ，被国内电商及互联网项目中使用，后期阿里巴巴停止了该项目的维护，当当网便在Dubbo基础上进行优化，并继续维护，为了与原有的Dubbo 区分，故将其命名为Dubbox。
Dubbox致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbox 就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有 dubbox 这样的分布式服务框架的需求，本质上是个远程服务调用的分布式框架。
SOA 是 Service-Oriented Architecture的首字母简称，它是一种支持面向服务的架构样式。
从服务、基于服务开发和服务的结果来看，面向服务是一种思考方式。SOA 架构多应用于互联网项目开发。
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明：
- 服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，服务运行容器Container会加载服务提供方以启动它，服务提供方启动后向注册中心注册自己所有能提供的服务。
IP PORT 协议dubbo 服务名称 - 服务消费方在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供方地址列表给消费方。如果服务提供方发生服务的修改变更，服务提供方会继续注册给注册中心，注册中心主动将基于长连接异步推送变更数据给消费方。
- 第一种情况，服务消费方直接调用服务提供方的服务，服务提供方将结果返回（同步的过程）
- 基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 第二种情况，如果找不到需要的服务（如 网络问题等），服务消费方默认会每个一秒重试一次，默认重试3次，如果还找不到服务报错no server。
- 服务消费者和提供者，会将服务的健康状态、调用次数等信息发送给监控中心。定时每分钟发送一次统计数据到监控中心。
注册中心宕机：
开发环境：现有的服务不会受影响，如果是新添加或者修改服务，无法完成注册，有影响。
生产环境：宕机没有影响，因为生产环境所有服务已完成，已全部注册到注册中心，注册中心会缓存服务信息。
二、注册中心 Zookeeper
官方推荐使用 zookeeper 注册中心。注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。 Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbox 服务的注册中心，工业强度较高，可用于生产环境。
dubbo原理图：
三、 概念说明
1、RPC
2、分布式和集群
