中台实践:通用化黑名单平台

业务定义

黑名单平台,泛指在业务流程当中,需要对特定用户进行管控的方式,通常会有黑名单、白名单两种用户类型。

业务场景

在风控识别、业务运营等流程当中,会涉及到对于某类用户进行“特殊对待”,比如恶意用户、高风险用户,在业务流程中可能会增加对用户的使用功能的限制,这类用户就属于黑名单用户。在不同的业务场景中,会基于不同规则去定义黑名单用户,并这种符合这类特种的用户进行统一化的管控。

当然还有一类特殊的用户群体,他们因为使用场景的特殊化也可能命中黑名单用户的规则。但是业务场景中又是允许这类用户存在的,那么这类用户就属于白名单用户,属于凌驾于黑名单规则之上的一类特殊用户群体。

业务问题

目前在现有中台架构下,不同业务模块都维护各自的黑名单体系,存在同一个业务场景的黑名单维护多套,或者同一套黑名单可以多个业务团队共用的问题。这就导致各团队开发既可能产生数据冗余,重复开发资源浪费的问题。

基于当前的问题,通过搭建中台黑名单平台,由各业务团队介入黑名单平台,针对各业务场景维护统一黑名单,可以由不同业务团队共享黑名单数据资源进行业务使用。

业务边界

既然做通用化,那么黑名单平台尽可能不做具备业务属性的逻辑,即通用户平台负责提供黑名单/白名单数据的统一使用服务,也就是针对数据的增、删、改、查能力。同时,为了保证各业务使用方可以实时获取数据,平台提供一套消息广播机制,可以让业务使用方可以快速获取数据的更新状态,即时针对不同状态做出业务响应。

业务架构

基于上面提到的业务场景、业务边界,设计了业务架构模式如下:

产品经理,产品经理网站

业务设计

(1)通用化平台由业务方接入,针对不同业务场景和业务规则,由业务方(如上图中业务方A、B)定义什么是黑名单用户、什么是白名单用户;由通用化平台提供黑名单数据的统一服务,这个服务包含增删改查能力。

(2)业务方(如上图中业务方A、B)可以通过通用户平台提供的前端可视化页面,通过给不同业务方配置不同权限体系,支持业务方进行数据的增删改查。同时也支持基于系统调用的API接口方式,进行数据的使用。

(3)为保证数据更新后的即时响应,在数据更新后,如数据的新增、删除,通用化平台通过消息广播机制,向业务使用方(如上图中业务方C、D)进行广播,如果业务方关系数据更新消息,可基于业务场景做出相应的业务动作,保证数据更新与业务的同步性。

中台化设计的关键

(1)统一化

在设计数据的使用方式方面,做了尽可能的统一化设计。在设计底层数据接口方面,针对增删改查的数据接口,先对尽可能全的业务场景进行梳理,针对不同颗粒度的业务进行规划,保证数据接口服务的统一性,后续各业务团队接口,都是统一的接入流程和接口服务。

(2)个性化

针对不同业务场景,数据的表现形式终归会有不同的地方,除了对整个业务流程中没有异议的数据内容进行标准化定义外,为满足不同团队的业务需求,在数据存储方面,数据结构中增加了可扩展的json字段。这个字段的数据内容由各业务方自助定义数据的业务含义,在数据查询时基于各业务的团队的场景进行解析后使用,既保证了各业务团队数据使用的个性化需求,由保证了中台通用化模块的通用能力。

(3)扩展性

对于黑名单/白名单数据存储,数据存在多维度属性,通过数据业务类型分类进行区分,例如用户维度类型,可通过枚举区分身份证号、会员卡号、手机号等类型,字段的类型设计相对兼容,在后续数据类型扩展上,可以做到减少底层逻辑的重新开发带来的时间、资源成本。

(4)如何做到上述3点呢?

关键是要对业务有充分的了解,这样才能更好的把握统一化和个性化的平衡。例如,针对于用户维度的黑名单设计,要对当前业务场景中标识用户的方式有相对全面的了解:手机号、会员卡号、微信账号、支付账号等等,只有对实际业务的了解,才能设计符合业务方需求的功能。

综上

所有的中台化产品设计都是在对业务充分了解的基础上,将统一化、个性化、扩展性进行设计与权衡,当然在方案落地过程中不可避免的要做出各种各样的妥协与让步,但是作为业务中台设计者,要坚守产品设计的边界与底线,这才是中台产品存在的意义与价值。

#作者#

记小忆,公众号:PM龙门阵,OTA中后台产品经理。

本文

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部