商品，黄金交易流程最基础最核心的环节，没有商品也没有电商。商品数据无处不在。商家（销售、供应商）发布管理、供应商采购订单、仓储配送、促销、搜索、店铺详情页展示、购物支付、财务结算、售后服务等，都离不开商品。商品信息要准确传递到京东整个供应链的各个节点，必须有强大可靠的商品服务体系作为支撑。本来就没有统一的商品服务和仓储。DBA搭建了一套多层次的SqlServer数据库复制结构，每个系统从各个层次的数据库中读取数据。复制延迟严重时，从库超过12小时没有更新，严重影响用户体验。写端口不止一个，拿到写账号就可以写了。erp产品管理系统、POP产品系统、BIP甚至开发了一个产品管理系统，都是在同一个数据库写同一套表，数据的一致性无法保证。在那个阶段，京东的订单量和用户量都比较少，基于数据库的架构也能在一定程度上支撑日常流量，但无法应对大规模的促销活动。在此背景下，2012年3月，产品组从网站组独立出来，孙哥临危受命组队启动产品技术架构升级项目。京东618年中狂欢购物节，系统（尤其是0:00）将承受着平时无法比拟的压力。2012年之前，大促总会出现系统问题。系统经常出问题，甚至在购书活动中直接宕机。基于数据库提供读服务的架构显然无法支撑业务，升级改造势在必行。2012年初，NoSQL还是一个??新生事物。事务架构师龚杰开始实践Redis。他在一封邮件中介绍了自己封装的客户端和API。产品组着手构建基于redis内存数据库的产品阅读服务，对开源Jedis进行深度封装，扩展ShardedJedisPool，实现更细粒度的多分片连接池管理，向同分片redis打一个请求命令由串行改为流水线并行执行，性能大幅提升。Architecture1.0读服务使用Redis存储全量产品数据，作为内存数据库使用。产品信息变更增量更新，一主多备容灾，全量刷新方案作为最终保障。一旦Redis中的数据全部丢失，可以将商品库中的数据恢复到Redis中。交易系统直接面向用户，确保用户选择、下单、结算的顺畅，提升用户体验。交易系统对高性能、高可用的商品阅读服务的需求最为迫切。此时架构升级采用“轻模式”。所谓轻，就是尽量减少外部系统的改造，更有利于工作的快速推进。首先，在通知方式上，各种商品系统写入Sqlserver主库后，会通过HttpHHTTP服务通知Rcat-server（采取尽量做的策略，能通知就通知，并且出现异常不要重试。此策略非常重要，因为相关系统修改很少）。Rcat-server的职责是接收通知，然后在主库中查询商品信息并更新到Redis。因为写作系统是一个尽力而为的模型，并不保证一定会成功，所以需要一个补偿机制来弥补疏漏。异步Worker定时扫描数据库，将当天的更新刷新到Redis。整体架构如图1-1所示：图1-1商品架构V1.0V1.0的架构非常不完善，只修改了阅读服务，但在当年的618完美完成了任务。618，和往年一样，研发工程师守候在售后运维同学身边，时刻准备着！整个过程平安无事，只有少数应用出现过载重启，整个过程非常顺利的通过了大流量的考验。有了这样的经验，研发工程师开始推广Rcat（应用名称，商品阅览服务），从图书馆依赖Sqlserver的系统也逐渐转向阅览服务。架构2.0全业务POP商品系统和自营商品系统均写入Oracle，数据通过异步worker写入Sqlserver。京东的独特之处在于，它本来就是一个自营产品，自己采购、自己销售，有自己的产品型号和相应的erp管理系统。后来就有了POP开放平台。本平台产品模型和系统自主搭建，适用于第三方商户的产品发布管理。并且所有下游系统（单品、搜索、订单生产、仓库等）都是基于原有Sqlserver自营skuSKU模式的系统设计。所以POP产品有自己的Oracle存储，京东必须经过一步一步的异步程序改造，写入Sqlserver产品库。2011年自营商品系统升级时，计划从.Net+Sqlserver技术系统升级到Java+Oracle技术系统。作为研发负责人，基于技术前瞻性和成本考虑，孙哥果断放弃了昂贵且没有DBA团队良好支持的Oracle数据库。而是直接基于SqlServer实现商品全服务，比其他系统的de-O早了整整一年。当时的总体思路是先实现服务，再升级存储（Mysql集群），最后完成一个完整的技术架构升级。综合服务流程：(1)综合阅读服务系统：将下游系统读取的信息刷新到Redis中，阅读服务Rcat统一支持基于skuId的查询需求。对于检索需求，比如根据分类id查询SkuSKU列表，构建Solr索引服务。基于各系统的需求收集和对当前SQL的分析，构建并逐步推广读取服务系统，去除各系统对Sqlserver数据库的读取依赖。（2）写作服务承接所有商品写作业务，提供基础商品相关读写服务，建立商品主数据中心，服务于自营商品管理、POP平台、图书、音像商品管理等系统.京东以3C自营产品和SKU化管理起家。后期开发POP平台为商业发布管理。写入服务必须兼容这两种模型，并平滑过渡。研发工程师最终设计统一产品-skuSKU模型，自营产品与SkuSKU一对一，POP产品与SkuSKU一对多。每个自营商品只有一个SKUSku，爆品商户一个商品可以有多个SKUSKU。自营商品传播通过后期颜色、尺码绑定实现销售关系绑定。这样，给用户看到的效果是一样的。同时，京东商户和POP商户都可以根据自己的习惯来操作产品。架构师游风凯在编写服务设计时充分考虑了扩展性和复用性，实现了模块的可配置性。基于产品介绍、扩展属性、规格参数、特殊属性等基本组件，可以灵活组合不同的业务流程。采用京东自主研发的SAF中间件，支持负载均衡、自动故障转移、流量控制、黑白名单等特性，性能卓越。(3)去除O：去除自营产品系统的Oracle，直接写入Sqlserver，减少延迟，缩短发布到展示给终端用户的时间。(4)异步引擎：建立配送服务体系，统一网站、WMS等下游系统进行消息通知。当初始产品发生变化时，只需要通知WMS系统即可，因为仓库在采购入库时需要核对产品信息。随着整个京东服务流程的推进，搜索、单品页面等系统都希望得到通知。因此，分销服务计划在产品信息发生变化后异步通知这些系统。商品信息入库后，将“操作日志”同步写入Redis队列，然后worker异步从Redis中取日志，获取变化后的skuSKU，组装信息并发送MQ消息出去。此时的消息采用通用化设计，如基本信息MQ、特殊属性MQ等。(5)存储升级：商品主数据存储从Sqlserver单一数据库升级为MySQL集群，划分垂直和水平。自主研发数据中间件，可实现主库路由、从库负载均衡、故障切换等，统一负责数据访问，使底层存储规则对应用层透明.结合当前数据总量和增长率，以及3年的预期数据量，进行存储容量规划，采用预分片的方式，方便后续扩容。对于非分片键之外的查询，使用辅助路由或搜索服务来解决它们。整体结构如图1-2图1-2商品结构v2.0随着商品数量和SKU数量的大幅增加，TPS逐渐提升。编写服务和交付服务耦合的弊端越来越突出。如图1-2中红线圈出的圆圈所示，写服务和投递服务是相互影响的。假设写入Redis变慢，会影响整体的写入性能；如果DB遇到瓶颈，又会影响到deliveryservice，查询回DB变慢，deliveryservice处理速度变慢。所以写服务经常会出现抖动，写慢，延迟交付。架构3.0平台化和精准化始于2015年年中，架构师李帅以解耦、精简的思路推出了3.0架构升级。架构越简单越好。从未接触过的新人也能快速上手；该体系结构还必须是松散耦合的。写入、发送、读取均可独立升级，互不影响，整体性能逐步提升。使用Jingobus根据slave日志识别产品信息变化，发送通知，刷新redis集群。异步引擎消息可配置，商品属性组合对应消息队列。比如你搜索skuSKU的状态变化，那么只有当skuSKU的上下柜状态发生变化时，才会发送消息，消息体只会包含skuSKU编号和状态。可配置任务引擎，快速响应新需求，接近零开发成本；实现按需发送，减轻消费者压力（例如：减少80%+的wms消息量）；与写系统解耦，整体稳定性增强。在推广过程中，还进行了跨部门的技术合作，共同升级技术架构。比如网站单品页面的数据异构升级项目，界面交互减少50%+，节省数百个Docker。商品服务作为超0级系统，必须具备高可用性。任何影响订单的系统故障必须在三分钟内解决。有了统一的交换平台，计划的执行可以非常快。因此，发现问题并提醒他们至关重要。在研发负责人赵享健的带领下，商品组启动了二级监控平台的研发工作。内存级别的监控信息在秒级收集、合并和延迟。并实现了秒级监控的平台化，可以将监控能力输出到其他系统。期间，商品阅读服务也不断升级。由于skuSKU数量多（十亿）且持续增长（每周增长率约105%），Redis存储集群也很大。读服务为很多其他系统提供商品数据查询服务，访问量大，尤其是618和双11期间，需要多套Redis集群来分担流量。NIO的Redis客户端减少了连接数；为了解决多组Redis集群的流量均衡问题，扩展了客户端的NIO版本，实现了对多分片连接的统一管理，使其负载均衡，能够作为一个实例一个分片宕机后，自动从集群中移除，恢复后自动加入集群，达到自动故障转移和恢复的目的。不仅提高了集群的整体吞吐量，还提高了可靠性。同时，由于商品数量的快速增长，Redis集群的规模也翻了一番。为了降低资源的利用率，设计了三级缓存功能，将最热的数据存放在应用内存中，缓存时间更短；热数据放置在较小的范围内。在Redis集群中，将全量数据放在一个更大的集群中，这样全量数据的Redis集群OPS更少，可以减少部署组的数量，从而降低资源利用率。图1-3商品架构图V3.0京东商品系统将在业务创新、数据智能、性能和稳定性提升等方面不断精益求精，努力实现让科技改变生活的愿景。作者：尤丰凯，京东研发-交易平台-商品研发负责人。2010年加入京东，先后参与京东第一代监控、消息、EDM等系统的设计与开发。2012年开始从事商品系统的SOA和商品系统的持续架构演进工作。现主要负责产品中台建设及组件化工作。【本文来自专栏作者张凯涛微信公众号（凯涛的博客）公众号id：kaitao-1234567】点此查看作者更多好文
