Dubbo的背景以及搭建

一.分布式应用架构(RPC)

    1.简单阐述: 通俗思想就是本地函数去调用远程的函数。

    2.三个必要条件: 

       (1). Call ID映射:  如果是本地调用函数的时候，编译器会自动帮助我们调用相应的函数体指针。但在远程调用时，函数指针        就不可用了，两个进程的地址空间完全不一样，在RPC中所有的函数必须有一个对应的ID，这个ID在所有进程中(包括客户          端，服务器端)是一致的。客户端在远程调用时，必须附上该ID.(在客户端以及服务器端都维护一个函数与CallID的对应表)。        在服务端查询客户端给到的CallID，查找对应表查找对应的函数，然后执行函数。

     (2). 序列化和反序列化: 在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用           时，客户端跟服务端是不同的进程，不能通过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（比如服     务端用C++，客户端用Java或者Python）。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。

    (3). 网络传输:     远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需 要有一个网络传输层。网络传输层需要把CallID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也可以.

二.  流动计算架构(SOA)

      1.产生背景: pc端，ios端，app端如果都有相同的查询，就需要写三次相同的的业务代码，效率不高。

     2.SOA思想: 写一个查询的方法，其他人可以通过某一个连接(Http或者Socket),访问这个方法，得到返回数据(json或者           xml)。 把上述所有的操作做成接口，当作一个'服务'。

     3.SOA服务治理(越来越多的服务，越来越多的服务方治理，他们之间的关系变得特别混乱，需要服务治理)

     服务治理框架:     dubbo + zookeeper  或者    SpringCloud

三.    Dubbo与Zookeeper、Spring框架的整合搭建。

        1. 安装Zookeeper，详情可参考博文： 
        http://blog.csdn.net/tlk20071/article/details/52028945

        2.创建多模块的maven项目

        创建过程请参考        https://blog.csdn.net/subuser/article/details/18988813

        项目整合过程参考    https://blog.csdn.net/zgsdzczh/article/details/78664561

         3. 安装Dubbo-admin，实现监控。

          安装过程请参考      https://blog.csdn.net/xinshui151/article/details/79181786