1、问题与挑战

到店综合有很多bu，有很多本地生活的类目。到综的商品形态有电商零售类，更多的是服务类。同一个类目也经常会做不同的产品，对应商品的形态和功能都不太一样。到综商品系统为了满足不同类目个性化的商品需求、同时保证接入的高效，我们搭建了商品配置中心，在不同层次大量采用了配置化的技术去解决这些问题。

一般而言，软件的配置，包含几个层面：包括数据，功能，流程，界面，角色权限，安全等等。

从业务需求来看，第一个最基本的要求是根据类目对商品数据结构化定制，几乎每个业务都是如此。其次是对一些核心功能模块的配置需求，譬如审核，因为商品数据的结构不一样，要转换给运营看的模板也不一样。最后是界面配置化的强烈诉求。在整个商品交易链路里面，商品编辑页和商品详情页，是耗时最久、个性化最强的有两处。每一个页面长的样子跟背后的数据都不一样，这里的前后端工作量都非常大。

从技术挑战来看，有三个方面技术复杂度都比较大。一是怎么将商品结构化做到灵活扩展，二是怎么做上单配置化提高研发效率，三是怎么建立完整的配置体系、整合所有层次的配置。

第一个复杂度是商品结构化。从商品的信息层次上，核心的商品模型，我们有SPU、商品、交易单元、服务单元，这些模型对应着商品信息的不同粒度和职责。商品信息包括描述类信息和交易类信息，商品描述类的信息，2c的平台一般都要求针对类目做信息结构化，一方面是提高商品的一个信息质量、给消费者更多的标准化信息决策，另一方面系统可以更好的理解这些数据，优化很多商品c端流量曝光场景，譬如营销、搜索等。

这里就带来两个比较大的挑战。一个挑战是，针对不同行业、不同类目，他们的商品模型结构化不一样。第二个更大的挑战是，除了商品模型，我们的交易单元、服务单元、SPU，这些不同粒度的商品信息都要求做结构化。业内其他商品系统面临的场景比较固定、一般只有商品模型的结构化，不同粒度的结构化、这是到综实践的大难题。

第二个复杂度是上单配置化。对于c端商品详情页，通过组件化的方式，个性化的诉求还比较容易解决。但商品上单页，由于ui与数据交互的复杂性，以及功能的个性化，像商品数据校验、数据可选项、数据转换等。单纯用组件化的方式，没有办法去解决问题。如何用技术手段去快速开发上单页，是一个亟待解决的挑战。

第三个复杂度是完整配置体系。整个商品系统我们做的配置项非常多，层次也非常杂，散落在系统的每一个角落。配置化也会导致系统的复杂度飙升几倍。怎么系统化的去建设配置体系，去降低这些复杂度。这是一个重要且长期要考虑的大难题。

2、核心思路与解法

商品结构化的核心思路与解法。业内大的方案都比较固定。即便是早期的淘宝，做这件事儿，也是有能从像CMS系统借鉴一些经验。大的方案都是根据商品的类目，去做一套元数据模型。元数据模型就像mysql的table schema、去定义数据的结构，背后的理论以国际组织 OMG元数据体系为指导。商品数据本身的存储，再用列式存储的方式去解决数据字段的扩展性问题，我们称之为eav架构，eav架构其成形于关系数据库的发展阶段、有优势也有劣势、不多展开，之所以选eav架构、除了其扩展性、还有一点是mysql关系数据库本身的稳定。

虽然大的方案都类似、但具体到落地层面，还是有很多考虑的一些点。譬如元数据模型描述语言怎么实现，怎么通用、易于扩展。我们有很多不同粒度的信息结构，针对这些不同信息粒度，我们首先抽象和定义一套统一的数据结构，让spu、商品、交易单元等数据结构归一化。我们在针对这个统一的数据结构，再定义一套统一的元数据模型，用于描述这个统一数据结构。最后我们有了统一数据格式和统一数据描述，我们就有了统一的数据理解和处理能力，在此基础上去抽象和沉淀很多的应用场景，譬如商品合法性校验，默认数据填充，审核模板自动转换，自动构建搜索索引字段等。

上单配置化的核心思路与解法。首先是业内调研。新美大做的最为成熟的上单配置是点评和美团团购两套系统，因为上单的速率在团购大战里面起着一个非常核心的因素，要迅速扩充很多品类、做很多类目的结构化，对研发效率极高要求。这中间有很多设计成功的经验可以借鉴，当然也有很多失败的经验。最大的一个问题是商品的数据定义和上单模板耦合在一起，上单界面是经常变化、很多个性化，但数据本身是最核心的、要做严谨抽象，两者的耦合导致商品数据落地了很多非商品相关的界面元素，上单界面也因为数据的限制导致功能难以扩展。我们通过和商业级的表单配置产品做对比分析，定下了几两个原则。

第一个原则是上单配置化的数据边界，对上单页及其描述、属于前端界面的范畴，对于商品数据及数据描述、属于后端数据的范畴。用于解决团购系统实践中遇到的界面与数据耦合的问题。譬如上单的下拉框，应该由后端下发可选数据、因为这是对数据的一个描述。前端界面通过搭建前端模板去解决，后端数据通过元数据模型、以及抽象一套数据集用于约束数据，给前端模板提供去做数据值绑定、数据可选项等数据信息。当你的数据边界划错了，整套系统马上就会达到一个无法演进的地步。

第二个原则是上单配置化的能力边界，我们只解决80%的配置需求，还有20%的需求我们通过可扩展的方式去解决。大部分需求是简单的，但也要有清醒的认知：配置化不能解决所有的问题。譬如一个KTV的价目表，团购原先做的非常复杂、还拿了创新奖，为了把它配置出来，将整个配置系统的复杂度飙升几个档位、得不偿失。配置不出来的组件，系统一定要提供扩展性去解决他们的个性化问题，譬如组件系统就是一个很好的扩展方案。配置化的阴暗面是系统的复杂度，一定要做好克制。

完整配置体系的核心思路和解法。首先，搭建完整的一套配置体系的关键前提在于：系统应用架构做的非常好。系统的功能和层次职责一定要非常明确，因为所有的配置都依赖系统功能本身的稳定性。譬如模型基础层没有出现好，那针对领域模型的结构化，就没有办法有一个统一的场景做校验。譬如审核模块，如果组件化程度做得不够好，那逻辑散落在各处，那配置化审核的配置化也无从谈起。其次，是针对这些应用架构的层次，分轻重缓急的去做实施。所谓的缓急就是哪一块是开发效率最低、急需配置化解决的；轻重就是就是层次，先从底层做起、再做上层，因为越底层功能越稳定，只有功能稳定、才能让配置方案稳定。最后是从整个产品的层次去做，强调产品配置的一个完整性，通过产品级的配置，商品从上单到展示核心环节都能出来，细节再定制开发。商品系统目前还在重点做第一和第二件事、打基础做抽象，个别业务做了下探索、复对前者的依赖极高。