管理后台服务通用化设计拙见

小灰灰 2024-04-18 10:40 46阅读 0赞

## 前言 ##

在公司实习两个多月，主要接手的都是管理后台的需求。一般情况下，管理后台很容易和CRUD联想到一起，这一类操作的特点就是代码基本相似，做一些简单的增删改查接口，不同的只是对于不同数据表的更改。不过针对这样的一个管理后台，相当于业务配置中心的服务，功能简单但又十分重要，往往会花费较多的经历在写一些重复相似的代码上，本文就来讲讲相关的改进工作。  
为了避免涉及商业隐私，我们依然以上一篇文章[大型工程微服务架构设计拙见][Link 1]的情景来引入。

## 需求 ##

祺平咖啡馆生意越来越火爆，业务也越来越庞大。为了支持整个咖啡馆系统的正常营运，管理后台服务需要支撑所有的配置信息，比如所有的商品信息，优惠券信息，抽奖奖品信息等等，整个服务需要配置的数据渐渐扩大。每次需要在管理后台配置的数据，都需要前后端实现一套操作系统，用于管理整个配置数据。同时配置数据还要提供RPC或者HTTP的接口用于其他上游微服务的调用。

## 思考 ##

对于一个新来的配置数据需求，按照流程我们需要做以下几件事：

*  设计并新建数据源（包括db/es等）
 *  后端新增对数据源的增删改查接口（可能会包含一些业务特有的逻辑）
 *  前端实现操作数据页面，调用后端接口（可能会有一些个性化展示数据的需求）

对于第一步来说，可能无法避免，我们必须针对特殊的业务新建特殊的数据源来存储，无论是关系型数据库MySQL，还是搜索数据库ElasticSearch。但创建数据源对我们的工作复杂度来说还算OK。  
对于第二步来说，后端的增删改查接口其实对应于数据源来说就是一些基本固定的代码，比如数据库就是sql，ES就是操作API，只是其中的一些参数不一样，例如不同的库表/不同的索引，但增删改查语句的大致结构还是不变的。  
对于第三步来说，前端会调用后端的增删改查接口进行操作数据，屏蔽后端的差异，其实每个操作数据页面模样是一样的，只是对应的按钮触发的请求是不一样的，不一致的部分标记了唯一要操作的数据源。

## 通用化设计 ##

经过上一块对于整个流程的思考，我们可以如下方式对整个实现流程进行改造，着重抓住通用步骤，剥离变化的部分。

#### 创建数据源 ####

对于数据库，我们往往先设计好关系型的库表结构，然后书写数据库表创建SQL语句。有一些图形化工具也能够让我们创建出库表。对于ES，也非常相似，通过相关的API代码我们便可以创建Index和Type。所以，这一块的通用化设计，我们可以仿照Navicat这样的图形化界面，用于创建修改删除数据源，针对不同的存储类型可以生成对应的数据源。  
当然在公司不同的环境，可能有对应的权限限制，对应的数据源增删改查可能需要工单审批等等。根据实际情况，我们可以考虑是否实现数据源的通用操作功能。

如下图所示，我们可以先选择好数据源的存储类型，然后选择填好对应的级别设置即可，在后端我们会利用数据库表管理所有的数据源信息。  
![创建修改数据源][20190905184517143.png]  
后端数据表设计成下面所示意的结构。`datasource` 主要用于管理数据源，包括了上图中出去表格部分以外的所有信息，一个数据源有多列，比如数据库的一张表有很多列，ES的一个Type里包含很多Field。  
![数据库表设计][20190905190742919.png]  
这样我们就能将所有可用的数据源信息管理起来。便于之后操作具体某个数据源数据时，获取到数据源所有的详细信息。

当然，前面主要说的是新增数据源的时候我们是如何利用页面操作方式操作的。**那么对于已有的数据源信息我们如何接入呢?**

MySQL中可以利用JDBC拿到所有的表、字段信息，ES中也有对应的API可以获取所有Index、Type以及Field信息。通过这种方式，我们也可以实现获取所有的元数据信息后进行落库管理起来。

#### 后端接口 ####

后端可以设计一套通用的增删改查接口，用于操作配置数据。我们可以简单的设计如下的HTTP接口：

<table> 
 <thead> 
  <tr> 
   <th align="left">接口名称</th> 
   <th align="left">接口形式</th> 
   <th align="left">备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">新增数据</td> 
   <td align="left">/generic/add/{id}</td> 
   <td align="left"></td> 
  </tr> 
  <tr> 
   <td align="left">删除数据</td> 
   <td align="left">/generic/del/{id}</td> 
   <td align="left"></td> 
  </tr> 
  <tr> 
   <td align="left">修改数据</td> 
   <td align="left">/generic/edit/{id}</td> 
   <td align="left"></td> 
  </tr> 
  <tr> 
   <td align="left">查询数据</td> 
   <td align="left">/generic/query/{id}</td> 
   <td align="left"></td> 
  </tr> 
  <tr> 
   <td align="left">发布数据</td> 
   <td align="left">/generic/publish/{id}</td> 
   <td align="left">数据的修改可能需要通知上游</td> 
  </tr> 
 </tbody> 
</table>

接口路径上的 `id` 用于区分具体是哪个数据源，它能够和上面所说的 `datasource` 表中的主键 `id` 一一对应。当前端请求HTTP接口时，我们可以知道需要操作哪个数据源，然后对相应的数据源进行数据操作即可。

针对不同的存储类型，数据操作层的实现也是不一样的。上面其实相当于定义了 `controller` 层的实现，`service` 层可以使用**策略模式**，针对不同的存储类型，实现不同的数据操作。

在实现过程中，我们发现对于MySQL的数据操作，我们可以使用**Spring JDBC**。Spring JDBC支持直接的sql操作，而且对于数据类型（java.sql.Types）的支持非常到位。至于sql，我们可以根据HTTP请求参数拼装成sql，表名列名之类的信息我们都保存在了之前的数据源信息表中。当然，数据库的写操作往往需要事务，事务也依赖于数据源，我们可以利用Spring编程式事务自定义一个事务注解AOP，这样能达到不同的数据源管理各自的事务。而对于ES的数据操作，我们可以直接利用Java API即可，十分方便。

前面主要说的是要读写的数据已经准备好，我们常常在写数据的时候需要校验数据内容，包含数据本身属性限制的，例如日期、数字等，也包含业务上的含义限制，比如优惠券批次号、奖品id号、活动时间等。关于数据的校验，我们可以单独为每一列绑定好一些预设的校验器，这些校验器我们可以**参考Spring的拦截器**，一层层校验，一旦不通过就直接返回。

我们可以给 `datasoruce_columns` 表添加一个字段 `check_list`，存放所有的 `checker` 的 `id` 数组。  
![校验器][20190905211228337.png]

#### 前端页面 ####

对于前端来说，不同数据的操作数据的基本相似。数据的展示可能需要一些个性化定制，对于这些个性化的设置，前端可以保存一份页面样式配置，保存在后端。在展示页面之前，需要先从后端获取配置文件，然后渲染页面即可。

所有的页面信息，我们也可以用一张数据表来进行管理。其中 `page_style` 用于存储前端特有的样式配置，`datasource_id` 表示该页面绑定的数据源。这样前端的每一个动作，后端根据其传来的页面 `id` 知道绑定的数据源，这样所有的页面动作都能反应的正确的数据源上。  
![页面信息][20190905212742284.png]

## RPC/HTTP服务 ##

上一部分，我们实现了通用管理服务配置数据的实现，包括增删改查功能。但是数据是为其他微服务进行服务的，我们必须要将数据暴露出去。由于管理服务基本数据的操作直接操作数据源本身，QPS不能过高。但是其他服务的调用量往往非常大，所以我们需要着重设计好这一块。

引入缓存是解决读性能瓶颈的重要手段之一，缓存的中间件有很多，常见的如Redis等，但考虑该场景下，我们并不需要分布式缓存。单机缓存足够应付这种场景，我们只需要将配置数据缓存到本地即可，每次读取数据先走缓存。一旦数据发生变更，我们要通知其他服务，数据发生更新，更新缓存。

当然，这样做的弊端是，每个从通用管理服务获取数据的上游来说，都需要实现自己的缓存逻辑，以及处理缓存更新问题。我们可以写一个SDK工具，让各个业务方进行使用。在SDK中我们实现基本的缓存，缓存更新逻辑，而特有的逻辑比如如何获取数据、筛选数据、校验逻辑等则交给业务方自定义实现。这样我们可以很容易利用模板模式来实现。

缓存更新问题，涉及到通知事件。现有的一些配置中间件例如携程的Apllo、ZooKeeper等都可以实现实时更新操作，我们可以利用配置中间件充当中间人。当管理服务数据更新时，通过配置中间件**推送**上游服务数据更新。为了防止配置中间件挂掉，我们可以设置上游服务每隔一段时间主动**拉取**管理服务数据，**推拉结合**保证数据的更新。

伪代码如下：

public abstract class AbstractGenericCache { 
    
        private String NOTIFY_KEY;
    	private Integer POLLING_INTERVAL;
    
    	private volatile Map cache = new HashMap<>();
    
    	private GenericRpc rpcServer;
    
    	public AbstractGenericCache(GenericRpc rpcServer, String notifyKey, Integer pollingInterval) { 
    		this.rpcServer = rpcServer;
    		this.NOTIFY_KEY = notifyKey;
    		this.POLLING_INTERVAL = pollingInterval;
    		init();
    	}
    
    	/** * 初始化方法 */
    	private void init() { 
    		// 实现好缓存推拉结合代码
    		
    		// 更新缓存通过下面这句话
    		updateCache();
    
    	}
    
    	private void updateCache() { 
    		Map cache = getConfigDataFromDataSource();
    		if (!CollectionUtils.isEmpty(cache)) { 
    			this.cache = cache;
    		}
    	}
    
    
    	/** * 获取数据——供其他服务调用 * @param condition * @return */
    	public Map getConfigData(Condition condition) { 
    		return getConfigDataFromCache(condition);
    	}
    	
    	private Map getConfigDataFromCache(Condition condition) { 
    		// 具体实现缓存中获取数据
    		return cache;
    	}
    
    	/** * 模板方法——通过rpc获取全量配置数据 * @return */
    	protected abstract Map getConfigDataFromDataSource();	
    }

对于其他服务来说，只需要继承该抽象缓存类，实现对应一些特殊的方法即可，便可以方便的实现配置数据的获取。

## 总结 ##

在整个实习过程中，后面主要参与了这一块服务的设计与实现，最终实现了大致本文的效果。其实整个实现技术难度不是特别难，做出来的效果也还是可以的，应对新需求的来临，基本消除了代码的编写，思想还是很不错的。

[Link 1]: https://wangguoping.blog.csdn.net/article/details/97694134
[20190905184517143.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/29fcd12592534bedaf70a98594a8086a.png
[20190905190742919.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/6f90dba8f1074d5cb18a609a656d79c9.png
[20190905211228337.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/280d0b07f6de4a868e396e887b6428fa.png
[20190905212742284.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/9be5785ba1314fcea0afd01f31afe81b.png