富客户端(Fat Client)，是一个与瘦客户端(Thin Client)对立的概念。常见的C/S架构就是富客户端，B/S架构是典型的瘦客户端。
当然，“瘦”与“富”是相对而言，各有各自的优缺点。
富客户端
优点：
1）有一部分功能在C端可以完成，一定程度上减少了网络交互次数和开销
2）有独立的端，可以独立运行，不依赖其他平台
3）客户端体验好，可以完成复杂的功能
缺点：
1）客户端占用用户资源，有时对用户硬件或者系统要求高
2）如果服务端有更新或者升级，一般情况下C端也要跟着更新，并且更新成本高
瘦客户端
优点：
1）不需要用户单独下载应用C端，对用户硬件和操作系统基本无要求
2）服务端升级，B端完全无感知
缺点：
1）一般B端不适用于完成较复杂的功能
2）浏览器层面的一些全局设置会影响到功能使用
上边简单分析了常见的两种应用架构方式各自的优缺点，接下来进入主题，dubbo实现富客户端。这个概念是不太准确的，现在分布式架构是互联网的主流，所以叫做分布式富客户端更为合适。
那么为什么要在分布式服务中引入富客户端的概念？我们先看一张图：
如上图描述，Web层远程调用Rpc远程服务为B端(浏览器)提供服务,这样做是没有问题的，也符合当前流行的分布式架构方式；但是高并发是所有互联网企业都要面临的问题，当然缓存是解决高并发的神器，那么如果上述架构再做一下改造如下图：
从改造后的图中可以看到，rpc服务暴露给调用放的client很薄，只有简单的接口定义，具体的实现还在provider层，也就是具体的服务实现和提供者。这样上层Web层只需要引用暴露出的client利用Rpc框架就可以调用到具体的服务，在并发查询场景下，虽然引入了缓存，但是不知道有没有人注意到，缓存是和rpc服务提供者不在一个主机甚至可能不在一个机房，Web层和Rpc服务层也可能不在一个机房，也就是说从Web层调用Rpc服务，Rpc操作缓存都有网络开销， 举个例子，如果Web层查询的数据在缓存中已经存在，那么回去直接从缓存中获取，但是调用链路还是Web调用Rpc服务，Rpc服务再从缓存获取数据返回，会有两次网络开销，我们开发者都会有一个概念，调用链路边长会增加失败的概率，在网络环境不好的情况下，一次网络开销和两次网络开销相比，体验优劣是很明显的。所以这种架构方式在流量大的项目中是不太可取的。
根据上述描述，我们对方案再做改进：
图中加了一个步骤，Web层在调用Rpc服务之前，先去缓存拿数据，如果命中直接返回，否则继续调用Rpc服务。也就是说在缓存命中的场景下，减少了一次网络开销。增加的节点，其实是Rpc服务的client提供的，对缓存和rpc服务的一个封装，然后暴露给调用者，也即是我们所说的富客户端的概念。
描述了很多概念和理论性的东西，下边我们使用Dubb框架来实现富客户端。
I 服务端编写
服务端结构如下图（基于上一篇的代码）：
具体实现参考徒手搭建dubbo服务
在dubbo-server-interface中添加两个关键类：
CacheManager
/**
* 缓存操作类
*/
public class CacheManager implements TCache,InitializingBean {
private JedisPool jedisPool;
public void setJedisPool(JedisPool jedisPool) {
this.jedisPool = jedisPool;
}
@Override
public <T> T get(Serializable key, Class<T> type) {
Jedis jedis = null;
try {
jedis = jedisPool.getResource();
byte[] data = jedis.get(key.toString().getBytes());
return SerializationUtil.deserialize(data,type);
} catch (Exception e) {
e.printStackTrace();
} finally {
if(null != jedis) {
jedis.close();
}
}
return null;
}
@Override
public void put(Serializable key, Object val) {
Jedis jedis = null;
try {
jedis = jedisPool.getResource();
byte[] data = SerializationUtil.serialize(val);
jedis.set(key.toString().getBytes(),data);
} catch (Exception e) {
e.printStackTrace();
} finally {
if(null != jedis) {
jedis.close();
}
}
}
@Override
public void afterPropertiesSet() throws Exception {
if(null == jedisPool) {
throw new RuntimeException("jedis没有初始化");
}
}
}
UserReadClient
/**
* 用户信息操作客户端
*
* @author Typhoon
* @date 2018-05-20 16:04 Sunday
* @since V2.0.0
*/
public class UserReadClient implements InitializingBean {
private static final String KEY_PREFIX = "userCachePrefix:";
private CacheManager cacheManager;
private UserService userService;
public void setCacheManager(CacheManager cacheManager) {
this.cacheManager = cacheManager;
}
public void setUserService(UserService userService) {
this.userService = userService;
}
/**
* 查询用户信息
*
* @param id
* @return
*/
public UserDto queryByPK(Long id) {
if(null == id || id <= 0) {
throw new IllegalArgumentException("参数非法");
}
UserDto userDto = this.cacheManager.get(KEY_PREFIX id,UserDto.class);
if(null != userDto) {//走缓存
return userDto;
}
//走DB
userDto = this.userService.queryByPK(id);
try {
this.cacheManager.put(KEY_PREFIX id,userDto);
} catch (Exception e) {
e.printStackTrace();
}
return userDto;
}
@Override
public void afterPropertiesSet() throws Exception {
if(null == cacheManager || null == userService) {
throw new IllegalArgumentException("tCache 或者userService没有初始化 ");
}
}
}
然后把dubbo-server-interface安装到本地maven仓库供其他消费端依赖，并启动服务.
II 消费端编写与测试
消费端redis的配置此处不做赘述，有兴趣可参见源码。
https://gitee.com/ScorpioAeolus/dubbo-consumer
在dubbo-consumer.xml中添加远程服务引用：
<dubbo:reference interface="com.typhoon.service.UserService" url="dubbo://localhost:20289" id="userService" protocol="dubbo" timeout="30000"/>
在主配置文件或者其他配置中增加：
<bean id = "cacheManager" class="com.typhoon.cache.CacheManager">
<property name="jedisPool" ref="jedisPool" />
</bean>
<bean id = "userReadClient" class="com.typhoon.client.UserReadClient">
<property name="cacheManager" ref="cacheManager" />
<property name="userService" ref="userService" />
</bean>
然后再在本地服务中注入UserReadClient:
@Autowired
private UserReadClient userReadClient;
@Override
public ResponseBase doQueryUserById(Long id) {
ResponseBase resp = new ResponseBase();
UserDto userDto = this.userReadClient.queryByPK(id);
resp.setAttach(userDto);
return resp;
}
编写单元测试：
@Test
public void testA() {
try {
ResponseBase resp = this.imitateConsumerService.doQueryUserById(1L);
System.out.println(JSON.toJSONString(resp));
} catch (Exception e) {
e.printStackTrace();
}
}
运行单元测试并debug：
1）第一次运行
可以看到查询没有命中缓存，走DB查询，调用了远程Rpc服务
2）第二次运行
debug代码看到查询命中了缓存不走DB查询，直接返回
总结
经过上述的描述和代码验证，我们使用Dubbo富客户端，其原理就是Rpc服务编写并暴露出一个复合客户端，里边包含了查询缓存和掉服务查DB的逻辑，
但是缓存的具体配置交给调用方，这样服务调用方使用富客户端的时候会优先走自己的缓存逻辑，如果缓存不命中就继续调用Rpc服务查询，这样就解决了
并发场景虽然后走了缓存但是依旧多走一次网络开销的问题。
此篇我们根据真实业务场景讲解了dubbo富客户端实现和引用，希望给大家在日常开发中带来帮助！
