Dubbo是一款Java RPC框架
如何将应用打包并部署到服务器上？
之前的单一应用架构，可以部署到多个服务器上，每次修改或扩展某一处功能都要将整个应用重新打包并部署到多台服务器上；协同开发时都改这一个应用，不利于开发与维护；当应用规模不断扩大，一台服务器无法支撑整个单体应用，仅仅依靠增加服务器也不能带来效率上的显著提升。
垂直应用架构：
将整个应用拆分成多个子应用，每个子应用都包括页面、业务逻辑、和数据操作。开发人员分工合作时可以互不干扰；可以对访问量较多的子应用进行服务器扩展，而不是整个应用增加服务器。垂直架构的问题就是界面与业务逻辑之间没有分离；各个子应用之间需要交互，不可能完全独立。
分布式服务架构：
将界面与业务逻辑进行抽离，可以单独更改界面或单独更改业务。界面可以调用各个业务，各业务之间也可以相互调用。在之前的架构，用户web与用户业务在同一个服务器上，相互之间可以进程内通讯，而分布式架构下，界面与业务在不同的服务器下，就需要RPC(远程过程调用)。如何拆分业务以及如何进行远程调用就是分布式服务架构需要关注的问题。随着应用规模扩大，成千上万个服务器应用于各个业务之中，资源浪费也就随之出现，就需要一个基于访问压力的调度中心，实时监控服务器数据，动态调度，提高资源利用率。
RPC：
远程过程调用，当进行不同服务器通讯时，例如A服务器调用B服务器的方法：1A服务器客户端调用，2将A传入的参数序列化，3发送要传递的信息给B服务器的小助手，4小助手反序列化传入的消息成对象，5小助手调用B服务器的方法，传入反序列化的对象，5B服务器服务处理并返回值，6返回值给小助手，8B服务器小助手将返回结果序列化，9返回给A服务器的小助手，10A服务器的小助手反序列化结果，11返回给A服务器调用结果。综上：RPC框架需要建立连接，序列化数据与反序列化数据两大步。
注册中心：
存储各个业务分别部署在哪些服务器上，RPC通过注册中心找到合适的服务器并建立连接，传递数据，进行远程调用
dubbo的注册中心采用zookeeper，到官网下载。
Dubbo流程：
蓝色虚线初始化，绿色虚线异步，绿色实线同步。
首先，Dubbo框架容器启动，提供者将业务信息注册到注册中心；消费者也就是web页面，将从注册中心订阅所需要的服务；当服务提供者有了变更，注册中心将通过长连接的方式将服务变更通知给消费者，让消费者实时的知道哪些服务不能再调用；注册与订阅之后，消费者就可以调用所需要的服务，如果服务有多台服务器，消费者就可以根据负载均衡算法，选择一个合适的服务器进行调用；每次的服务调用信息都会定时发送到监控中心，监控中心就可以监控服务的运行状态。
