概念：
Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。
Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
第一阶段
最近学dubbo，为什么学呢？因为想做个APP。服务端怎么实现呢？
关于java，我以前只知道webservice。
那么java关于soa都有什么解决方案呢，搜索到了dubbo。于是学了，按照我的学习习惯，先学关系。
于是做了一个整整，方便记忆。
第二阶段：上面的图能体现面向服务的调用关系。
但是分布体现在哪里呢？目前还不清楚。先把结构图弄过来，然后在继续分析
节点角色
Provider：服务提供方，在启动时向注册中心注册服务；
Consumer：服务消费方，向注册中心请求服务提供方列表，在本地做负载均衡调用服务；
Register：注册中心，提供服务注册与发现(一般由Zookeeper担当)，通过长连接与Provider和Consumer保持连接，负责监控Provider的上下线并及时通知Consumer；
Monitor：**监控中心，负责统计服务的性能数据；**
Container：服务运行容器。
调用关系
“0.start”：服务运行容器启动、加载、运行服务提供方，一般由Spring容器启动Jar运行；
“1.register”: 服务提供方在启动时，向注册中心注册自己的IP、服务接口等信息；
“2.subscribe”: 服务消费方向注册中心订阅自己感兴趣的服务提供方;
“3.notify”: 注册中心在服务提供方发生变更时将基于长连接向消费方推送消息；
“4.invoke”: 服务消费方在本地对服务列表做软负载均衡算法，选择最优的服务提供方进行RPC调用；
“5.count”: 消费方和提供方向监控中心 定时异步推送服务调用次数和时间，消费方的包括网络耗时，提供方不包括网络耗时。
上面的"统计服务的性能数据"到底有上面作用呢？在分析吧。
第三阶段 RPC的演进
上面是一个rpc的演进过程，从图上看，rpc是把机能切割为分布式的调用。那么分布式，体现在哪里呢。
注册中心是服务和消费的枢纽，那么注册中心装载在哪里呢？是一个机器承载了该机能，还是分布式的装载呢？
服务注册，注册给谁了？给那台机器了。注册给了框架，框架做的分布处理？这有可能，那么这里就是我们要找的分布式体现。
再看如下这句话
“服务消费方在本地对服务列表做软负载均衡算法，选择最优的服务提供方进行RPC调用”
我关系负载均衡谁做，服务消费方做，他会选择合适的服务。那么就是说同样的服务，比如syhello这个服务的提供者，不只一个，或者说不只装载在一个机器上。对这个服务的选择是可以在调用的时候做负载均衡的选择的。
哦，找到了。这就是分布式的体现，和负载均衡的体现。但是细节和原理，还需要进一步分析，想现在分析的方向是对的。
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
地四阶段：基础知识补充
Java RMI 简介
Java RMI （Remote Method Invocation）- 远程方法调用，能够让客户端像使用本地调用一样调用服务端 Java 虚拟机中的对象方法。RMI 是面向对象语言领域对 RPC （Remote Procedure Call）的完善，用户无需依靠 IDL 的帮助来完成分布式调用，而是通过依赖接口这种更简单自然的方式。
Java RMI 工作原理
一个典型的 RMI 调用如下图所示：
服务端向 RMI 注册服务绑定自己的地址，
客户端通过 RMI 注册服务获取目标地址，
客户端调用本地的 Stub 对象上的方法，和调用本地对象上的方法一致，
本地存根对象将调用信息打包，通过网络发送到服务端，
服务端的 Skeleton 对象收到网络请求之后，将调用信息解包，
然后找到真正的服务对象发起调用，并将返回结果打包通过网络发送回客户端。
引用来源：http://jm.taobao.org/2018/06/13/应用/
第五阶段 dubbo对系统动态升级的支持
当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力：
第六阶段:分布是模式设想
上面的图，没有太认真的分析呢，先进行一个分布式软件的假设。
还是用图说明把，我的理解分布式的一个特性，一个服务挂掉了，系统正常运行不受影响。
基于以上的特性那么就一定有重复的东西。那么重复的东西在那呢？
还记得前面有一句话吗： Consumer：服务消费方，向注册中心请求服务提供方列表，在本地做负载均衡调用服务
这里就是重复，也就是说，每个“服务消费方”都有全部的服务列表，“服务消费方”会收到全部服务的状态，及每个服务的负载状态。这样“服务消费方”就可以根据一个算法去选择服务，这及是负载均衡的关键，到这里我的这个假说应该可以理解，分布式的整个设计思路了。
是否是这样，还得需要深入的学习验证，但这里我有一种舒服的感觉，不在困惑了，尽管是假设，但我有一个清晰完整的思路了。
即使真正的设计和我这个假说不同，我一定也会有一个很舒服的收获，“豁然开朗”吧。学习我就喜欢这种感觉。
引用来源：https://blog.csdn.net/uniqueweimeijun/article/details/79896551