01-分布式基础知识
由于我对分布式系统学习接触的稍微较晚，因为一直在打基础，在我认为基础有所起色的时候，我顺便系统学习了一下spring cloud技术栈，然后再回过头来学习看以下dubbo怎么用的时候，会发现还是spring cloud比较厉害，因为它是一站式的解决方案，但是dubbo仅仅解决了服务治理功能，其他的所有都要借助其他的框架来实现。但是看到国内用dubbo这么广泛，并且阿里重新对dubbo进行维护，因此学习它也是非常必要的。这样对于spring cloud的理解可能也会有帮助吧！并且我想理解dubbo这款优秀的RPC框架的基本原理，日后以自己造出小轮子为目标。本文还是从基本的说起。
一、什么是分布式系统
《分布式系统原理与范型》定义：
“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”
这里注意集群和分布式的区别，打个比方，青椒炒肉丝，如果是两个厨师各自炒半碗青椒肉丝，最后合起来一碗青椒肉丝，这两个厨师集群；一个厨师炒青椒，一个厨师炒肉丝，合起来又是一碗青椒肉丝，这两个厨师是分布式。在软件系统中，一个系统可能有很多的业务，比如京东，有商品业务，订单业务，支付业务，物流业务等等，一个服务器肯定是无法支撑的，那么这些业务就需要分散到不同的机器集群上，这些集群分别对外提供各自的业务功能，整个分布式系统对外提供京东商城的服务。
引入分布式，那就引入了及其复杂的问题，因为服务与服务之间肯定是需要互相通信的，这属于进程间的通信，所以需要一个东西可以帮助我们实现这个功能，这就是RPC框架解决的事情。
二、发展演变
我们去看看dubbo的官网。以下内容为对官方文档部分介绍的解释。
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
缺点十分明显：
- 性能扩展比较难
- 协同开发问题
- 不利于升级维护
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
优点：通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。
缺点：公用模块无法重复利用，开发性的浪费
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
三、RPC
RPC【Remote Procedure Call】是指远程过程调用，是一种进程间通信方式，他是一种技术的思想，而不是规范。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。
下面这张图简单说明了RPC的基本原理，左边进程要调用右边进程中某个方法，那么左边首先通过client stub这样的小助手将要调用的方法名称参数都包装好，通过socket将消息发送到右边，右边接受之后也通过小助手拿到要调用的方法和参数，处理完毕将结果再返回给左边进程。
具体一点的细节，就是需要将调用的方法名以及参数等序列化，然后进程间通信，最后反序列化，处理。
这里就体现了RPC的两个核心模块：通讯，序列化。两者速度决定了这个RPC框架的优劣。
Dubbo
我们先来看看dubbo的优秀特性。第一条是面向接口，以接口为粒度，这对于java开发来说是天生的优势。第二条支持智能负载均衡，因为可能有多台服务器符合条件，快速找出一台比较空闲一点的来执行也是关键点。第三条是支持多种注册中心服务，比如大名鼎鼎的zookeeper。第四条是可扩展，内部的模块也可以扩展。第五条是运行期流量调度，其中提到灰度发布，就是从一部分的机器慢慢提供新服务开始逐渐到所有机器提供新服务，这个过程就是灰度发布。最后一条是可视化，dubbo提供可视化界面方便查看和操作。
下面我们来看看dubbo的架构图：
我们看到，主体是四个部分，最上面是注册中心，这个注册中心有什么用呢？由于服务众多，如果不用注册中心，一台主机调用另一台主机上的服务，我不知道这个服务在哪，也不知道这个服务有没有挂，如果是每个主机都维护这个关系那就比较麻烦了，注册中心帮助我们解决这个问题，所有的服务都注册到注册中心上，那么调用方就订阅这个注册中心，它就知道要调用的服务在不在工作，在哪台机器工作等，十分方便。
介绍完了注册中心，右边是Provider，它像注册中心注册自己。左边是Consumer，它向注册中心订阅相关服务(自己感兴趣的服务)。这个Provider建立在dubbo容器之上，这样一个服务才拥有RPC功能，可以让别人调用也可以去调用别人。
最下面是监控器，就是监控服务之间的状态。
那么启动顺序是什么呢？第一步就是启动dubbo容器，启动完成，Provider就可以向注册中心注册自己的服务了，下面Consumer在启动的时候就会去注册中心订阅相关的服务。以上是初始化过程。
如果注册中心里面，Provider 列表有变化的话，Consumer 也会得到通知。这是异步调用的过程。所有服务的状态信息也都会异步传给监视器。
Consumer要调用服务了，从订阅消息中就可以拿到感兴趣的Provider信息，就可以直接与Provider建立通信了。这是一个同步调用过程。如果Provider有多个，再根据一定的负载均衡策略，精确地调用到某台 Provider 上去。
以上就是分布式的基础知识以及dubbo的基础知识，其中dubbo的基础架构要了然于心，这是学习dubbo贯穿始终的基本点。