我们之前做的商品中心属于基础服务几乎所有业务都会调用它。首页要商品名称和主图商品详情页要完整信息下单要价格和库存搜索又只关心类目和标签。如果给每个业务单独提供接口接口数量会越来越多维护成本也会越来越高。但如果所有人都调用同一个全量接口又会产生另外一个问题大量字段根本用不到却依然要查询、组装、序列化再通过网络传输给调用方。所以我们后来采用了 Option 模式。接口增加一个 Option 参数由调用方自己决定需要哪些维度的数据。例如BASE商品基础信息如名称、状态、类型、主图等PRICE价格相关数据SKU规格及库存信息BRAND品牌信息CATEGORY类目信息IMAGE图片列表ATTRIBUTE动态属性EAVDESCRIPTION商品详情ALL返回全部数据。如果不传默认返回 BASE。购物车一般只需要 BASE PRICE订单确认页需要 BASE SKU搜索服务通常只关心 BASE CATEGORY商品详情页则直接传 ALL。这样每个调用方只获取自己真正需要的数据服务端也只查询对应维度的数据不查、不组装、不返回无用字段。另外我们还提供了批量查询能力不过单次最多支持查询 50 个商品。原因不是数据库查不出来而是需要控制一次请求的处理成本。如果一次查询几十甚至上百个商品并且每个商品又要加载多个维度的数据那么服务端的数据组装、对象创建、序列化以及网络传输都会明显增加。限制批量大小可以保证接口的响应时间和资源消耗始终保持在可控范围内。还有一个细节我们返回给调用方的 DTO 使用的是扁平结构而不是层层嵌套的 JSON。这样做最大的好处是接入成本低。无论 Java、Go 还是 PHP都可以直接反序列化成自己的对象不需要额外解析复杂的数据结构。Option模式真正解决的是可以避免接口随着业务增长不断膨胀。当一个基础服务开始面对越来越多的调用方而不同业务需要的数据差异越来越大时与其不断增加新的接口不如把数据拆成多个维度把选择权交给调用方。最终一个接口就可以支撑十几个甚至几十个业务系统而每个系统拿到的都是自己真正需要的数据不多也不少。