银河配置平台自我总结

一、项目背景

App资源融合，好医生App分配保险业务配置页由北京团队开发与运营。

运营要求：

1、动态楼层配置

2、千人千面

3、实验对照ABT

4、楼层定时上下线

5、分平台（安卓、ios、小程序）、版本（v1.0、v1.2）展示

6、白名单预发部

 

二、需求分析

经过多次与业务、产品、测试同学进行头脑风暴，我们将系统进行了详细的拆分

需求原子单位是素材，多个素材组成模版，一个模版填充一个楼层，多个楼层组成版面，一个完整的版面构成如下：

 

因每个模版的格式、组成素材都不一样，所以对模版进行拆解后，得到如下图：

 

素材：

　　1、静态素材：仅需配置名称、图片、跳转地址

　　2、动态素材：需配置素材名称，素材对应接口，例如有的素材上要现实实时保单数，就需要调接口获取 

模版：

　　多个素材组成，有资源位

楼层：

　　1、楼层可设置定时上下线时间

　　2、楼层可设置安卓、ios、小程序是否展现

　　3、选择楼层类型：默认楼层 or 指定人群画像的楼层（例如：30岁-年入百万-男）

　　4、同一人群的楼层下可设置实验组与对照组，例如：实验组1-1资源位选的素材A，对照组1-1资源位选的素材B

版面：

　　由多个楼层组成

 

三、技术选型

好医生号称4亿用户，DAU百万，故需应用支持高可用高并发。

系统分为TOB配置端与TOC展现端。

　　TOB端职责：

　　　　与后台H5对接，素材创建、定制模版、预发布、发布等后端配置工作

　　　　数据库事务后，删除缓存

　　TOC端职责：

　　　　与大前端（安卓、ios、小程序）对接，版面实时组装，三方接口对接等版面展示工作

 　　　　查询缓存、DB组装

系统架构设计：

　　1、springboot + mybatisplus

　　2、redis集群+mysql

　　3、配置中心

表结构ER图设计：

 

缓存与快照表设计：

　　设计一张专属存储缓存结构数据的快照表，将版面、楼层、楼层明细、模版、素材组、素材直接的关联关系及明细数据放入快照表，C端在查询组装时将版面数据查出，即可将版面依赖的所有元素组装完毕。

描述	key	JSON数据
预发布版面key	stage_page_key_A00001
正式发布版面key	release_page_key_A00001
楼层key	floor_11
楼层明细key	floor_info_20
素材key	material_11

 

缓存处理抽象流程图：

　　上述表格内所有的key的缓存查询都适用下图的多级缓存框架。

　　设计主备二级缓存机制，两个缓存的内容相同，过期时间不同，例如版面key 一级缓存过期时间2天，二级缓存过期时间7天。

　　先查主缓存，主缓存不存在，则竞争锁查询db组装，未竞争到锁的线程查备缓存组装。

 

 

 

 

 

 

 

 

注意，为提升效率，一个版面下的楼层在组装时为串行，楼层内多个素材组装时为并行。且可以将整个楼层的组装好的数据进行缓存。

 

四、项目复盘

系统设计初衷是配置中台，提供可复用的页面配置，避免重复造轮子。

但是随着版本需求的迭代，人员更替，更多定制化的小需求将部分模版修改的面目全非，最终配置中台变为配置平台，所有需求case by case，可复用性大大降低。

对于这样大而全的系统，业务、产品非常满意，认为有需要去银河改，在配置即可，小改动耗时短，迭代快。

开发很头痛，原本模版模式的设计，子模版下全是定制化代码，人员无法简单交接。

 

可优化点：

　　素材要按照类型分组，与模版不再是强耦合关系

　　模版是否可以动态组装，避免一个模版一次开发

　　依赖三方接口的素材，需要对三方接口的效率、格式有严格约束，避免定制化接口对接

　　缓存预热处理