随着互联网技术的发展，网站的规模在不断地扩大，单一应用架构已经不再能满足需求，由于架构的原因，系统中某一处如果要进行修改，整个应用就需要重新部署，代价非常大。而在分布式架构中就能很好地解决上述问题，每一个模块就拆分为一个单独的服务，当模块的访问量变大时，就可以将同一个服务部署到不同的机器中同时运行。
RPC框架
当不同的模块之间出现调用关系时就会用到RPC(Remote Procedure Call)，当前最主流的两个框架一个是Dubbo，一个是SpringCloud。这里我们主要介绍Dubbo，Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各层之间解耦(或者最大限度地松耦合)。从服务模型的角度看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色。
注册中心
当需要被调用的模块在不同的多态机器上进行部署时，就会出现调用方不知道该调用哪台机器上的服务，这时候就需要注册中心来帮助我们。注册中心会保存每个模块所在服务器的位置，当调用方需要调用时，首先去注册中心查看被调用模块的位置，然后根据注册中心返回的位置信息，去对应的服务器上进行调用。ZooKeeper就是一个应用非常广泛的注册中心应用，它是一个分布式的应用程序协调服务，它为分布式应用提供一致性服务，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
ZooKeeper+Dubbo组合
Dubbo的服务容器(Container)在启动时会加载和运行服务提供者(Provider)，服务提供者在启动后会将能提供的自身的服务信息注册到注册中心(Registry)，服务消费方(Consumer)在启动后会订阅注册中心中所需要的相关的服务的信息，注册中心会将消费方所需的服务的地址列表提供给消费方，如果服务信息产生变更，注册中心会基于长连接的方式推送给消费方。消费方当需要调用时，根据注册中心提供的地址列表基于配置好的负载均衡机制找到服务提供方的位置进行调用，如果调用失败，会再去找下一个服务提供者进行调用，直到调用成功为止。
Dubbo还提供了监控机制，消费方和服务提供方会定时向监控中心发送调用信息。