【供应链架构day11】京东履约系统的演进之路

 

OFC（Order Fulfillment Center）的重要性

2014年的618显得和以往任何店庆促销日都不同，不仅仅是因为电子商务本身在中国不断飞速发展对京东系统带来的挑战，更为重要的是2014年5月22日刚走入美国纳斯达克殿堂的京东聚集了最耀眼的光芒，能不能保持这样的光芒，618则会是一份很有说服力的答卷，当然我们最终给出了满意的结果。作为一个普通的购物者，当我们在浏览器中输入www.jd.com并回车，便可以看到京东商城的首页，根据自己的需要选择喜欢的商品，然后加入购物车，提交订单后，即可享受京东的极速物流体验，最终完成一次简单快乐的购物历程。其实，订单提交后，需要经历多个环节和各个系统的处理才能完成使命。其中有一个环节是订单必须经过的，而且这个环节连接了用户下单和订单在库房的生产，就是订单履约中心（OFC，Order Fulfillment Center），本章我们就为各位解密这个部门。

2014年的618后，京东技术团队分享了如何应对店庆日及以往促销活动在技术方面的经验和探索。其中有一讲“电商海量订单处理OFC系统的关键技术环节”（见京东技术开放日第一期），说的就是这个部门做的事情。

这个部门的职责，用彭青的话讲就是，转换用户订单为各终端系统的生产单，并且按要求送达到相应终端系统。举个例子，就好比我们将采集到的原始食材按照客户的不同口味（不同系统）进行烹制，并且在指定的时间内做好后送到客人（终端系统）那里，整个过程包括订单的拆分转移和订单的下传。其实我们从网站下的订单（也叫原始单）在库房是直接生产不了的，需要经过OFC这个环节的处理后，才能到达各个生产系统。由此可见，这个环节必然会有大量数据需要处理，而且还要保证时间。

想必大家知道关于京东的211、311等配送方式，如果用户选择不同的配送时间，京东的快递就必须在用户指定的时间送达，而如果下游的生产系统收到订单数据比较晚，就会影响后续的配送时间，最终会影响客户体验。现在订单下传，对接的全国库房近150个，需要调用的外部处理订单服务也有近20个，而每个系统的处理能力和响应能力又各不同，这就需要我们进行相应的调节流量的配置，这其中只要有一个系统存在问题，就可能会影响订单的下传。

OFC的形成

2003年京东网站创立之后，迎来全国电商的快速发展，京东的业务随之不断增加，导致相应的业务系统也在持续增加。直到2011年，随着系统增多及业务的需要，逐渐成长出来一个小团队，负责在各个系统之间进行数据的传输，将客户订单数据传到库房，同时需要将非客户订单，如采购单、供应商、内配单等二十多个业务传输到相应的业务系统，至此OFC成形。

初期由于各个系统的不完善，导致数据传输总是存在各种各样的问题，订单总会卡在这一环节，而作为传输环节又必须保证数据能正确传输完毕，这就需要我们必须了解上下游系统的业务及数据处理的过程，只有这样才能知道问题产生的原因，才能知道该如何去处理问题。但是由于上下游的系统是需要经常上线新需求的，我们每天需要及时了解上下游系统业务的处理，才能保证我们的环节没有问题。

那段时间兄弟们真的很辛苦，每天需要处理上千个工单，加班更是常事，以至于一个同事说睡梦中都在处理问题单。由于业务领域划分存在问题，系统边界不明确，导致出现许多莫名其妙的问题，兄弟们干得很苦很累，直到彭青来了之后。彭青带着一个厚厚的黑色全框眼镜，个子不算太高却有个小肚腩，学生族的发型让人感觉很亲切。彭青根据他多年的工作经验和对系统的理解，对这块业务进行重新划分，逐渐将非客户工单的数据传输工作交接给对应系统进行处理，将兄弟们解放出来，开始客户订单处理的新征程。

到2011年底的时候，在彭青的带领下我们已经成为了二十多人的团队。为了更进一步拓展在客户订单方面的业务领域，我们主动接手了订单拆分系统和订单转移系统。这两套元老级系统是用.Net编写的，由于前辈们大都不在职了，文档也不完善，对于系统内部业务了解的人很少，修改非常难。而此时每天由于系统问题导致的事件单多达上百，也就是说每天运维带来的工作量都是可观的，在这样的情况下，接手这两个系统自然全无阻力。

技术的改造

.Net到Java

系统接过来了，第一步要做的事情当然是重写。对技术的选取，根据当时公司技术发展战略以及Java的普及，我们选用了Java。重写过程中需要梳理已有的业务，自然少不了不断和原来系统的人员进行交流，去确认业务流程和技术处理细节。经过一个多月，系统的重写总算完成，接下来的工作就是上线了。

开始小流量地切，我们通过开关进行控制，通过省市县区域分流，到2012年2月系统算是上线了，而之