物流系统的设计总结

       本人供职于某电商公司的物流部门,负责相关物流信息系统的开发,其中最重要的系统就是为了对接各大快递公司,从各家快递公司获取订单的物流轨迹。刚开始公司为了省事是通过付费方式统一从快递100获取各大家物流公司的物流轨迹,但由于订单数量比较大,每个月都要支付一笔不小的费用给快递100,费用是不超过10万则每单0.1元,超过则每单0.05元,系统每天调用快递100的单量大概是100万,这样每天就需要支付5.5万的费用。为了节省费用,选择直接对接各大快递公司,这样每年可以为公司省下2000万的费用。

     该物流系统具有以下特点

1.对接的快递公司数量多

    目前主流的快递公司有差不多30家,包括申通、圆通、汇通、中通、邮政等快递公司,商家发货单量最多的快递公司是四通一达。

2.各家快递公司的接口各异

    有些是使用JAVA接口,比如京东,但大部分是使用HTTP接口,比如申通。接口的返回格式也不同,有些是使用XML格式数据,大部分是使用JSON字符串。物流轨迹的状态不一样,物流轨迹的状态主要有揽收、在途、送货、签收、拒收、异常件。但有些快递公司是没有揽收、拒收或异常件的,需要对物流轨迹的状态进行统一转换。有些快递公司是没有轨迹的状态,只有描述,这样我们就需要从描述中识别出状态,由于各种状态不统一,有些随意,所以经常会出现错误识别的问题,比如轨迹是拒收状态的,但我们识别成签收,或签收状态我们识别成拒收,这会影响业务,比如财务退款就是根据拒收判断的。为了解决这种频繁的错误识别问题,我们使用JS脚本来识别轨迹状态,再把JS脚本放入JAVA中的JS引擎里面执行,这样系统升级时不需要频繁启动,只需要更新数据库里面的JS脚本就可以了。

3.系统数据量庞大

    公司每天的订单量有一百多万,每个订单产生的物流轨迹大概是5~10条,每天产生的轨迹数量有几百万。按每天一百万单,每单5条物流轨迹,每个月就是1.5亿的数据。

4.系统并发量较大

    每个订单会对应一条运单号,我们使用运单号去快递公司摘取物流轨迹,一般是后台使用定时任务去摘取(也有个别是快递公司推送过来的),根据业务对物流轨迹的实时性要求、系统的并发容量以及快递公司服务器的限流量做调整,刚开始定时器是8小时去拉取一次物流轨迹,后面调整成3小时。目前总共有24台服务器在跑,每天总共要拉取800万次物流轨迹。为了存放海量的物流轨迹,需要进行分表,分表的方式是根据快递公司的编码和运单号取哈希值,最后分成32个表。存放运单号的主表则不需要分表。同时订单号、运单号、快递公司编码、时间等字段加了索引,这样确保即使是上亿数据的表,在查询时也能很快就出来。

5.系统的稳定性要求较高

    如果系统挂掉了,或者没有及时从快递公司拉取到物流轨迹,就会影响业务的使用,甚至会影响订单结算(退货情况下)。但由于对接的各大快递公司的接口经常会出现各种状况,比如接口访问不了(对方系统升级或系统挂掉)、接口访问异常(HTTP响应超时)、接口限流、接口返回格式错误或出现变更、接口没有返回数据等问题都会导致轨迹拉取失败。虽然有日志告警系统对相应的问题进行告警,但处理起来依旧费时费力。

你可能感兴趣的:(工作总结,问题总结)