分布式应用中客户端的设计

一个分布式的系统一般都会有很多的节点，节点和节点之间的通讯采用远程调用的方式，而当在实现业务逻辑的时候，我们可以通过客户端的实现方式实现，目前实现客户端的方式有两种方式，瘦客户端和富客户端。

 

第一种方式 瘦客户端：

 

所谓瘦客户端类似于之前EJB那种方式，瘦客户端本身不具有业务逻辑，瘦客户端通过业务接口调用服务端逻辑，这个时候逻辑运算还是跑那个被多个系统共用的服务器，这样当存在大量的请求的情况下，负责逻辑运算的服务器就会成为瓶颈，这个时候可以有两种方式来解决这种瓶颈问题：

 

第一水平伸缩负责逻辑运算的服务器，这个时候涉及到客户端请求的负载均衡，每次将远程调用采用负载均衡算法将其分配到逻辑端服务器，采用这种方式以后，可能就需要远程调用框架内部支持一些比如流量控制，负载均衡等的机制，这样使得调用方本身不需要关心服务器端的物理部署。

 

第二种方式 富客户端

富客户端是将运算逻辑以客户端包的形式提供给调用方来使用，这样可以分摊逻辑运算服务器的压力，将压力分担到调用方服务器。这种方式非常适合调用方服务器本身负责的逻辑很简单，运算量很小的情况下，采用富客户端以后可以合理利用调用方服务器的资源来分摊掉被调用方服务器的压力。另外一方面，富客户端也适用于当需要将一些非核心的业务从核心业务中剥离出来，然后让非核心的业务跑到调用方的服务器中，同时富客户端还可以做其它的一些事情，比如缓存调用结果，实现调用方的local cache等。

 

当然了采用富客户端也会带来一个明显的问题，那就是客户端的升级，假如逻辑有变化需要让调用方升级客户端包，当然这也有解决办法，就是将业务逻辑进行抽象，每一步都采用动态脚本的方式比如Groovy脚本去执行，每次客户端服务器启动的时候，中心服务器推送最新的Groovy脚本到web客户端服务器，这样客户端服务器就可以获取到最新的执行逻辑,当然这对客户端的设计要求严格，客户端可能要设计的具有插件式的灵活功能。

 

采用富客户端另外一个问题就是富客户端的状态和服务器端的如何进行同步，假如服务器端的一些数据变化了，而客户端需要感知这些变化怎么办？这也有解决办法，一种方式是拉模式，另外一种模式推模式。

 

拉模式就是每次服务端有变化的时候，给富客户端发条指令，然后富客户端会主动向服务器端来拉数据，这种方式对于客户端服务器量比较大的情况下比较方便，比如富客户端被前端数百台机器使用，这个时候可以显著减少服务端的工作量。

 

推模式就是当服务器端发生变化的时候，主动推送给每个客户端，这种情况适合客户端服务器数量不多的情况，当然无论是采用拉还是推模式都需客户端和服务端保持一定的联系，这可能需要客户端在启动的时候主动的向服务端去注册一下，客户端注册以后，中心服务器端可以监控客户端的一些运行状况等信息。

 

以上是在分布式应用中，多个应用之间如何通信的