青龙系统发展历程

京东物流系统架构演进中的最佳实践_应用场景

青龙系统从2012年开始1.0的封闭开发,到2016年规划的6.0智慧物流,基本打造了一套完善的电商物流系统。

青龙系统1.0,主要实现了电商物流基础功能,满足了但是的核心业务诉求。青龙系统1.0上线,被京东当年评为优秀项目,成功之处就是比较好的遵循了MVP原则,也就是最初的版本只实现最有价值的部分。在著名的《人月神话》中,多次提到第二次开发系统失败的案例,最重要的原因就是,大家对于第二次开发的系统寄予了太多的希望,而项目负责人也给予了太多的承诺,时间等诸多问题,让项目走向失败,这个在中国互联网系统重构的案例中也可以找到。当时,青龙项目和业务负责人,都还是有比较清醒的认识,基本没有增加特别多的需求。项目组利用半年封闭完成开发,再用半年完成全国推广上线,完全替代了老系统。青龙系统是基于Java的SOA理念来开发,而老的系统是.net ,这也就是造成是完全重新开发,而不是平滑升级,付出代价也是很大的。

青龙系统2.0,起于2013年,主要是追赶功能。因为2012年开发新系统,业务方的新需求较少支持,也积压了非常多的需求,也非常感谢业务方的支持。团队利用一年的时间,完成了两年业务开发,也是非常给力,和业务方也构建了非常信任的伙伴关系,为后续系统健康发展,奠定了很好的基础。到2.0完成开发时,青龙系统已经成为完善的自营电商物流系统。

2014年,我们规划3.0时,也有些迷茫,因为系统已经比较完善了,该向何处去是个问题。这时候,公司推动了物流开放的战略,希望利用京东物流的优势,来带动POP平台体验的提升,因此,我们抓住机会,确立了以外单开放为主题。我们开发了青龙开放平台,接单系统,和主流的ISV软件完成对接,以及改造现有分拣,运输,配送等环节,来支持外单。因为符合公司战略,业绩还是不错,当年双十一的时候,外单量也突破了60万单。这给我们很大的经验就是研发的方向,要符合公司战略,获得运营团队支持,才能形成合力,共同推动业务成功,否则,即使做出很炫的系统,也会因为没有用户而夭折。

2015年,团队也比较成熟,公司的战略是渠道下沉,3F等,我们也据此确定5.0主题是渠道下沉,配合公司战略,从零开始,构建了京东乡村推广员系统和校园派系统。年底,乡村和校园业务,都成为年会的明星,我们也获得了很大的认可。

从2015年开始,互联网+提升到国家战略层面,物流也越来越受到重视,互联网+物流,能做的事情越来越多。因此,到2016年,我们规划青龙系统6.0的时候,把主题确定为智慧物流,也就顺理成章了。

青龙系统发展到今天,已经包含了分拣中心,运输路由,终端,对外拓展,运营支持等五十余个核心子系统,构建了完善的电商物流体系。


青龙系统架构最佳实践

京东物流系统架构演进中的最佳实践_互联网服务_02

青龙系统架构演进过程中,从高可用,高性能,数据一致性,用户体验四个方面,积累了丰富的经验,确保了青龙系统在发展过程赢得了公司内外的口碑。


高可用

每年“双十一”都是网购狂欢节,假设当天哪个电商系统出现系统不可用,那几乎是灾难性的,不仅会导致用户快速流失,而且,公司将承受重大损失,甚至在未来竞争中失败。即使对于创业公司,在当前获取用户如此昂贵和竞争如此激烈的情况下,系统不可用的代价也是非常大的,会遭到用户的抛弃而失败。

青龙系统作为京东后台物流系统,系统高可用也同样重要,因为,即使在平时,物流系统出现不可用的情况,会造成订单时效履约失败,极大影响用户体验,这也是无法接受的;同时,系统不可用也会导致数十万员工无法正常工作,对于效率极大影响,公司损失也非常大。我们在研发过程中,对于系统高可用,也积累了丰富经验,主要包括:合适的架构方案;大系统小做,服务拆分;并发控制,服务隔离;灰度发布;全方位监控报警;核心服务,平滑降级。

首先是选择合适的架构方案。互联网系统一般可以分为前端应用系统和后端数据库系统,前端应用系统实施分布式集群部署技术上是比较成熟的,后端数据库系统实现异地多活技术难度很大,目前也只有阿里,京东这样的公司才真正实现。因此,对于大多数应用,前端应用双机房集群部署,后端数据库系统采取成熟的主备从的模式,也就是单个机房作为写入,备库在另外机房,可以快速进行切换,读库双机房部署,是优选的方案。对于这个架构方案,存在跨机房写延长的问题,可以根据场景利用异步的方式进行解决,一般也是没有问题的。对于青龙系统来讲,也有些特别,利用分拣中心的本地服务器和操作人员的设备,实现离线生产,进一步提高可用性。

大系统小做,服务拆分,是互联网应用的特点,也符合敏捷交付的理念。对于传统软件,如Windows,Office等,都要经过一个漫长的需求,研发,测试,发布周期,在“唯快不破”的互联网时代,这显然是无法满足业务要求的,即使最后上线,也可能因为周期太长而不再适用了。因此,对一个互联网服务,一般会首先完成最核心的功能,快速进行上线,不断进行迭代,后续再进行辅助功能跟进。对于核心功能,随着用户数的增加,会不断进行服务拆分,如何进行拆分,拆分到什么样的粒度,是不是微服务是解决问题的银弹?这些都要根据实际的应用场景来评估,绝不是越细越好,而是要达到一个优雅的平衡。

并发控制,服务隔离。并发控制,现在已经成为互联网服务基本要求,在应用程序端和数据库端,也都有成熟的方案,如果忽略,可能造成灾难性的后果。对于重要的服务,还要进行隔离,例如同一个服务,要提供给内部调用,公司级调用和公司外开放服务调用,开放服务调用者我们一般认为是不可靠的,甚至有可能是恶意的,如果不进行隔离,开放服务调用有可能使得服务资源占满,对内也无法提供服务。从技术上,可以是硬件级隔离,全部隔离,也可以是前端应用的隔离。

灰度发布也是互联网服务的一大利器,有了灰度发布,才使得快速迭代成为可能,并且,很多服务因为各种原因线下也是很难测试的,只能在线上测试。如果没有灰度发布,只能全量发布,就存在较长测试周期问题,如果没有重复勉强上线,就存在很大的系统崩溃的风险。按照用户,区域进行灰度发布是比较常用的方法。

全方位监控报警,可以分为技术层面和业务层面,技术层面包括对CPU,内存,磁盘,网络等的监控,业务层面,包括对处理积压量,正常的业务量等。做到全方位监控,才有可能在影响用户之前,提前解决问题,提升系统可用性。否则,等用户发现问题,在很大的压力下,技术团队更难处理,导致系统不可用时间加长。

最后就是,核心服务,平滑降级。任何技术手段,都不可能保障100%可用,并且,即使能够做到,其代价也是巨大,不经济的,因此,对于核心服务来讲,能够平滑进行降级,提供基础的服务,也是非常重要的。对于青龙系统来讲,就利用分拣中心本地服务器和操作人员的设备,研发了离线生产系统,来应对集中服务万一不可用的情况。

举两个案例来做简单说明。

第一个是电子签收的案例。电子签收对于京东物流意义重大,不仅提升效率降低成本,而且实现了所有业务数据化,为智慧物流奠定基础。我们最早做的时候,也是遵循了MVP原则,开发了一个很简单的原型系统,内部测试可行后,才进行第二步,也就是和京东云合作,接入京东云图片处理系统,支持百亿张图片存储,找到安全认证伙伴,接入安全认证服务。这些完成后,我们就开始线上测试,不断提升用户体验。第三部,在大规模推广之前,我们完成了系统降级服务,也就是确保京东云,安全认证服务,甚至,我们自身的电子签收管理系统不可用的情况下,如何保证配送员的业务不受到影响。

第二个案例是去IOE的案例。青龙系统最初也是基于IOE开发,后来,随着系统规模的扩大,去IOE成为必然,在整个过程中,我们也是遵循了很多架构实践。例如,第一步,我们是先去IE(IBM小型机和EMC存储),将核心业务系统库拆到Oracle PC服务器上,并且,将数据进行同步,在验证服务完成后,把读服务迁到小型机,稳定后,再迁全部服务,并且,保证服务可以随时迁回。第二步,我们开发了双写服务,逐步将Oracle,迁移到MySQL集群。第三步,完成MySQL的数据聚合,确保数据服务。在整个过程中,都确保了系统在任何情况下,都可以会退,确保业务正常。


高性能

对应互联网服务来说,高性能是必须的,用户的响应一般都要求是秒级,而一个用户操作都包含多个服务调用,对应服务接口响应的要求都是毫秒级。对应青龙系统来讲,支持物流操作人员有十万余人,每个操作提升一秒,那么就能节约三个人员,意义是非常大的。

如何提高性能,接口数据缓存化是非常重要的手段。青龙系统属于后台操作型系统,业务逻辑复杂,如果不能缓存,完全依靠数据库操作,那么,响应会超过数十秒。如何进行缓存,需要设计缓存系统进行支撑,青龙系统在演进过程中,依托公司的缓存服务,并且结合应用内存,包括Redis消息通知体系,构建了具有自己特色的缓存体系,很好的支撑了业务发展,案例结构如下图。

京东物流系统架构演进中的最佳实践_数据_03

大型互联网服务,一般都微服务化了,这样意味着一个用户操作,都是由多个服务接口支持,如果按照传统的同步接口设计,那么,不仅面临性能问题,而且,QPS也是无法满足的,因此,需要将同步接口调用异步化。在2012年左右,eBay就提出所有系统调用异步化,后面,几乎所有大型互联网公司,都对自身系统进行了异步化改造,并且,取得了很好的效果,在和腾讯CTO Tony交流中,他就提出即使支付这种服务,也是有办法进行异步化设计的。同步接口异步化,也是需要系统工具支持的,青龙系统在发展过程中,也发展了基于Redis的分布式调度系统,架构参考下图:

京东物流系统架构演进中的最佳实践_数据_04

做大了缓存和异步化,系统性能会有很大的提升。对应青龙系统这样的大型互联网服务,对应核心服务要求是非常高的,同时,又有数量非常多的非核心服务,如果不能进行主次服务分离化,那么意味着如果要提升核心服务水平,增加服务器,那么,就需要为所有的服务进行扩容,这样是不经济的。因此,系统需要精心设计,做到核心服务和非核心服务分离,给核心服务提供充足的资源,确保核心服务的性能。


数据一致性

数据服务,对于大型互联网应用,已经变为非常核心,称为系统的大脑也不为过。

我们一般需要考虑实时性和一致性,这两个最重要的维度,当然,数据量也是一个维度,一般我们认为是大数据的应用场景。

京东物流系统架构演进中的最佳实践_数据_05

这样,我们就能分为四个基本的场景:高实时性/高一致性,高实时性/低一致性,低实时性/高一致性,低实时性/低一致性。针对具体的业务,我们可以匹配到具体的数据场景,这样,我们就能找到对应的解决方案。在这个过程中,客观的进行业务分析非常重要,并不是,选择高实时性/高一致性是最优方案,因为这个方案的实现成本是最昂贵的,可能是不经济,也没有必要的。

实时&强一致场景:这个在大数据技术成熟之前,是非常棘手的,但是,现在解决方案已经比较成熟了。典型应用是生产系统的实时监控,例如实时生产量,各个生产环节差异量等,其实是作为生产系统的一部分。利用当前主流的大数据处理架构是可以解决的,例如线上生产库binlog实时读取,Kafaka进行数据传输,Spark进行流式计算,ES进行数据存储等。如果利用传统的ETL抽取方案来解决,频繁对生产数据库进行抽取,并不是可行的方案,因为,这样会极大的影响线上OLTP系统的性能。还可以举一个生产系统实时监控案例,架构方案是应用系统完成写数据库的同时,把内容通过消息发送,后面的大数据处理系统接收消息来进行处理,这个架构方案,对于实时性某种程度上可以保障,但是,也存在效率问题,但是,对于强一致性就非常不合适了,因为消息系统如ActiveMQ等不仅无法保障消息数据不能丢失,而且对应消息顺序也是无法保障,项目实施后,虽然采取了很多补救措施,也无法满足强一致性需求,不得不重起炉灶。

实时&弱一致性场景:典型的应用场景是消息通知,例如电商的全程跟踪消息,如果个别数据出现丢失,对于用户的影响并不大,也是可以接受的,因此,可以采用更加廉价的解决方案,应用完成对应的动作后,将消息发出即可,使用方订阅对应的消息,按照主键,如订单号,存储即可。

离线&强一致场景:这是典型的大数据分析场景,也就是众多的离线报表模式。从技术上,传统的ETL抽取技术也能满足要求,数据仓库对应的技术也能够解决。

离线&弱一致场景:对于抓取互联网数据,日志分析等进行统计系统,用于统计趋势类的应用,可以归为此类,这类应用主要是看能够有足够廉价的方案来解决,是不是可以巧妙的利用空闲的计算资源。这个在很多公司,利用晚上空闲的计算资源,来处理此类的需求。

以上讨论的都是大数据应用,也就是从数据量大的应用场景。但是,对应现实中很多数据处理系统来讲,例如很多B2B业务系统,或者传统行业,其实是数据量并大,那么采用更加廉价的OLTP的方法,例如复制读库等,也是可以完成对应的工作的。

因此,架构设计应当针对具体应用场景的,满足当前业务的发展需求,可以考虑两年的需求,最合适的架构就是最好的,而不存在放之四海都是最好的架构设计。不分析清楚自己的应用场景,盲目照抄大公司的技术架构,显然也是不合适的。当然,如果选择的架构本身,不能满足应用场景的需求,后续,不论进行多少补救,依然无法满足需求,并且,架构会变得异常复杂,替换的成本也将是非常高昂,不得不慎重。


用户体验

京东是非常重视用户体验的公司,老刘就明确指出任何人不能对用户体验提升的意见说No。青龙系统在研发过程中,我们认为MVP原则和动态运营是非常重要的。

MVP原则,也就是敏捷开发中的迭代思路。对应一个大的项目,按照传统的瀑布模型,一般经历设计,研发,测试到最后上线阶段,这对于互联网应用来说,很多情况下是不能接受的,因为业务需求变化太快,如果上线周期太长,也许上线后发现情况已经变化了,或者,上线后发现不能落地推广。因此,对应一个大项目,一般会进行迭代分解,最核心的需求,会优先开发,并完成上线,上线验证后,继续开发优先级低的需求。

动态运营,其实也和MVP原则有很强的联系,也就是功能上线后,要真正运营起来,看具体数据,如果发现和设计不符合,那么,就要进行调整,到符合用户需求。这也是互联网服务的用户体验,要优于传统的软件开发系统,传统软件开发基本上上线后就不在优化了,而对于互联网服务来说,上线只是开始,只有将这个功能运营好,才叫好,并且,这个过程一直是持续的。
小结

对于如何打造一个高可用的互联网系统,上面很多点大家都知道,包括高可用,高性能,数据一致性和用户体验,关键是如何落实和做到极致,就如大家都学习乔布斯,但是,能够真正把产品做到极致的还是凤毛麟角。


京东物流系统架构演进中的最佳实践_数据_06

欢迎关注“互联网架构师”,我们分享最有价值的互联网技术干货文章,助力您成为有思想的全栈架构师,我们只聊互联网、只聊架构,不聊其他!打造最有价值的架构师圈子和社区。

本公众号覆盖中国主要首席架构师、高级架构师、CTO、技术总监、技术负责人等人 群。分享最有价值的架构思想和内容。打造中国互联网圈最有价值的架构师圈子。

  • 长按下方的二维码可以快速关注我们
  • 京东物流系统架构演进中的最佳实践_数据_07