0

物流系统高可用架构案例

ADMIN 2019-07-02
211


系统可用率


多级缓存


动态分组切换

   

DB物理隔离


服务分组隔离    


跨机房隔离    
 
漏斗模型    

 
 
DB限流    

 

 

 


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


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


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


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


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


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

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


数据一致性    
我们就能分为四个基本的场景:高实时性/高一致性,高实时性/低一致性,低实时性/高一致性,低实时性/低一致性。针对具体的业务,我们可以匹配到具体的数据场景,这样,我们就能找到对应的解决方案

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

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

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

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


在对业务能首先是业务数据化,并且具有数据质量保障。系统的支撑下,实现了所有物流操作的线上化,也就是数据化,并且,对每个操作环节都是可以进行实时分析,这就奠定了很好的基础。如果业务都是线下操作,或者系统无法准确及时收集数据,那么,即时数据量够大,缺乏关键数据和数据不准确,也会给大数据处理带来很大的困难。第二基础就是大数据处理技术,包括收集,传输,存储,计算,展示等一系列技术。够进行实时监控和准确评估后,也就是利用大数据对业务进行预测。预测一直是大数据应用的核心,也是最有价值的地方。对于物流行业,如果能够提前进行业务量预测,那么,对于资源调度等非常有意义,不仅能够实现更好的时效,而且能够避免浪费。举一个的例子,就是单量预测,根据用户下单量,仓储生产能力,路由情况等,可以进行建模预测。


智慧物流,以大数据处理技术作为基础,利用软件系统把人和设备更好的结合起来,让人和设备能够发挥各自的优势,达到系统最佳的状态。


出处:www.cnblogs.com/wintersun

版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。


架构文摘

ID:ArchDigest

互联网应用架构丨架构技术丨大型网站丨大数据

更多精彩文章,请点击下方:阅读原文

最后修改时间:2020-05-08 17:11:24
「喜欢文章,快来给作者赞赏墨值吧」
文章转载自ADMIN,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

关注
最新发布
暂无内容,敬请期待...
数据库资讯
最新 热门 更多
本月热门
近期活动
全部
暂无活动,敬请期待...
相关课程
全部