关于商家数据中台设计思考与总结

序言

最近入职了一家新的公司，公司要启动一个商品数据中台项目，需要与老板汇报一个架构设计，在设计过程中，有所心得，在此记录一下，本文不会和大佬们的中台架构文章一样，大谈概念与理论，本文主要还是以功能设计与落地过程为主。如有不足或错误欢迎指正🙏

项目背景

1. 目前公司已有两条业务先建立了商家及商品的标准的电商化的数据体系，包括服务商，商家，商品，类目，规格，套餐等。
2. 新的业务线同样需要此数据体系。

目前痛点

1. 已有的两条业务线的商家商品数据体系融在一个项目当中，需求迭代的影响范围，项目上线的部署复杂度，上线后需要验证的功能范围，发生问题排查的复杂度，难度都非常的大，显然整个大项目已显得十分的臃肿。
2. 新业务线仍需要标准化的电商商品数据体系，如果要再次的建设，无疑是重复造轮子，烟囱式开发，浪费人力。

解决方案

构建一套，以商家数据，商品数据，套餐数据，为主体的标准化的电商数据体系结构中台，将数据层与业务进行解藕，提升业务的响应效率，降低企业数据维护成本，沉淀数据化产品，为企业发展做好决策与分析。

商品数据中台

全景图

功能设计

 

技术难点

对于数据中台初期建设来讲，需要解决的问题比较多，比如规则的制定，服务的编排，但是本人认为最突出的两个问题。

• 扩展问题

        如何解决不同业务方的飞速发展所带来的新的数据属性的存取。

• 效率问题

        如何解决快速响应业务方调用的快速应答，快速应答包括数据的存与读两个过程，如果中台处理时间过长的话，那再加上业务系统的业务逻辑规则，整个流程的操作耗时对用户来讲将是难以接受的。

高扩展

例：创建商家门店接口，请求对象为：CreateStoreRequest类图如下:

中台只提供了基础的属性，但是如果以到家门店为力，需要保存门店的经纬度，详细地址，门店电话等到店的门店特有的数据属性，如下图：

这时该如何进行灵活的扩展呢？

如果客户端创建了新的对象，继承基类，在子类中定义新的属性，调用服务端接口时将子类传递给方法；这种方式服务端不引用客户端的对象，在反序列化时，扩展的属性将会丢失，无法获取。

如果在每一个请求信息都加一个Map，存储扩展信息，那么是可以实现灵活扩展，但是可读性将会无法保障。

经分析与调研后，中台对外提供出了一套SDK，SDK中提供了参数解析器，在请求时，客户端可调用SDK的数据操作方法，传递自定义的子类，SDK中的解析器会对请求参数进行解析，将扩展的字段与数值采用反射的方式进行处理，将解析出来的内容存储到key-value的容器当中，调用接口，中台接收到数据后，会将扩展的属性信息，存储到属性表中。

• 请求流程

 

在查询功能中，数据由中台返回到SDK时，SDK会对响应参数进行解析，将属性信息设置到子类VO对象的属性字段中。VO图：

 

• 响应流程

采用这种反射的方式，做到中台对外最终的高扩展。

高效率

在本次中台的建设过程中，在数据的操作，采用了读写分离的方式，写动作，先写入Mysql，写入成功后，将数据同步至ES当中，如失败在用：重试+消息通知的方式，达到数据最终的一致性，实现提高检索的效率的目的。为解决ES刷盘的延迟问题，写入ES同时会写入redis中一份；在读的时候会先读ES，如果ES中无数据，则读取redis，如redis无数据则读数据库，并返回，同步数据至redis。

• 数据同步流程

 总结

在架构设计中，不只是功能的简单罗列，更加应该关注的是业务底层的逻辑关系，未来的走势；更不应该过度的设计，要从实际业务场景出发，设计一套符合当前业务场景，满足当前业务需求，支撑未来扩展的架构即可。