供应商治理中心 主要针对供应商的行为进行扣罚和奖赏，目前开放了7种类型 1）用户退货退款 2）仓库推送 3）月缺 4）发货时效 5）物流变更次数 6）五天入库率 7）重量填写过轻 整体的业务流程就是，数仓（大数据团队）会像B端和C端拉取数据，把正确的数据回流到我们治理中心的原始表里面，治理中心定时任务拉取原始表数据（供应商+日期维度），验证是否需要扣罚或者奖赏，需要的生成对应的违规单和明细，同时给供应商系统发送违规站内信通知商家。系统中也存在申诉的流程，申诉成功最终不扣罚，申诉超时或者失败就会下发结算系统，生成结算单，请款单向供应商申请打款。结算系统给治理中心回执，下发和回执是通过kafka消息机制做的。

业务背景：在我进公司前，采购系统也经历了4年多的心路历程，所以整个项目遗留了很多问题，PO单表当时有70多个字段，还有一张扩展表ext,数据量大概在4000万左右，项目内部也存在复杂的SQL，整体看优化必不可免。 优化历程： 我刚进来的时候领导就提出整体采购的诟病，表字段过多，数据量很大，然后项目中用的是mybatis,复杂sql过多，针对新业务需求宽展缓慢。所以我第一版设计的方案是按照领域垂直拆分（采购单正向，逆向退货退款，结算，基础数据），然后各自数据库独立，分布式结构，但是面临的问题就是小公司的版本迭代不可能太久，一般开发+测试的时间再一个自然月左右，否则不可控，所以方案被否定，第二套方案就是PO单表做垂直拆分，分成4张表（主表，供应商维度，SKU维度，操作人维度）+一张索引信息表（取得了4张表中可用的字段做关联使用），也就是内部数据库拆分，然后java代码层做双写+慢慢切读的逻辑+es新表同步，分版本的形式迭代优化。 目前进度： 目前进度在二期，项目流程稳定，就是痛点也不少，老代码导致。

供应商平台主要思想在于降本增效，给采购系统提供基本信息以及推荐最优解的数据支持，由外部系统（1688，PDD，淘宝）来做真实的数据同步。 系统遇到的问题： 1.由于外部平台当时只提供了查询接口，所以无法感知商品价格，起批量，运费的变化，只能全量查询，造成性能会有很大阻碍。 2.业务推进困难，公司背景造成的技术话语权不大，所以很多业务想推荐系统自动化非常困难，导致系统对人工的依赖度很高，无法做到人工降本。 3.历史代码问题严重，系统最初期，采购，调拨，订单，库存，商品商家等模块代码和数据库全部偶合在一起，导致当时解耦困难，而且随着新业务的迭代，任重而道远。 4.数据库遇到的瓶颈，数据库中表的数据量很大，当时业务的增删改基本都在PDB中，但是由于一些错误索引的创建，导致很多表索引占用空间巨大，碎片化严重，增加了很多运维的工作。很大程度上影响了开发效率。 项目业绩： 1.供应商平台根据起批量*数量+运费取最优解的模式，提供了更幼稚的供应商推荐，每日的降本能达到5%-20%左右。 2.支持了10万左右并发量的压测操作，保证了该接口的推荐效率 3.优化了获取供应商信息的批次数据，是每天的性能更高，比之前快800% 4.优化了各个系统的慢SQL，使得PDB性能提供500%。