《京东物流系统架构演进中的最佳实践》阅读笔记

青龙系统架构最佳实践

 

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

 

高可用

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

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

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

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

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

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

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

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

高性能

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

  如何提高性能,接口数据缓存化是非常重要的手段。青龙系统属于后台操作型系统,业务逻辑复杂,如果不能缓存,完全依靠数据库操作,那么,响应会超过数十秒。如何进行缓存,需要设计缓存系统进行支撑,青龙系统在演进过程中,依托公司的缓存服务,并且结合应用内存,包括Redis消息通知体系,构建了具有自己特色的缓存体系,很好的支撑了业务发展,大型互联网服务,一般都微服务化了,这样意味着一个用户操作,都是由多个服务接口支持,如果按照传统的同步接口设计,那么,不仅面临性能问题,而且,QPS也是无法满足的,因此,需要将同步接口调用异步化。在2012年左右,eBay就提出所有系统调用异步化,后面,几乎所有大型互联网公司,都对自身系统进行了异步化改造,并且,取得了很好的效果,在和腾讯CTO Tony交流中,他就提出即使支付这种服务,也是有办法进行异步化设计的。同步接口异步化,也是需要系统工具支持的,青龙系统在发展过程中,也发展了基于Redis的分布式调度系统,做大了缓存和异步化,系统性能会有很大的提升。对应青龙系统这样的大型互联网服务,对应核心服务要求是非常高的,同时,又有数量非常多的非核心服务,如果不能进行主次服务分离化,那么意味着如果要提升核心服务水平,增加服务器,那么,就需要为所有的服务进行扩容,这样是不经济的。因此,系统需要精心设计,做到核心服务和非核心服务分离,给核心服务提供充足的资源,确保核心服务的性能。

 

数据一致性

  数据服务,对于大型互联网应用,已经变为非常核心,称为系统的大脑也不为过。
我们一般需要考虑实时性和一致性,这两个最重要的维度,当然,数据量也是一个维度,一般我们认为是大数据的应用场景。

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

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

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

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

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

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

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

 

用户体验

  京东是非常重视用户体验的公司,老刘就明确指出任何人不能对用户体验提升的意见说No。青龙系统在研发过程中,我们认为MVP原则和动态运营是非常重要的。
MVP原则,也就是敏捷开发中的迭代思路。对应一个大的项目,按照传统的瀑布模型,一般经历设计,研发,测试到最后上线阶段,这对于互联网应用来说,很多情况下是不能接受的,因为业务需求变化太快,如果上线周期太长,也许上线后发现情况已经变化了,或者,上线后发现不能落地推广。因此,对应一个大项目,一般会进行迭代分解,最核心的需求,会优先开发,并完成上线,上线验证后,继续开发优先级低的需求。
  动态运营,其实也和MVP原则有很强的联系,也就是功能上线后,要真正运营起来,看具体数据,如果发现和设计不符合,那么,就要进行调整,到符合用户需求。这也是互联网服务的用户体验,要优于传统的软件开发系统,传统软件开发基本上上线后就不在优化了,而对于互联网服务来说,上线只是开始,只有将这个功能运营好,才叫好,并且,这个过程一直是持续的。


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

猜你喜欢

转载自www.cnblogs.com/iCheny/p/11057050.html
今日推荐