物流系统高可用架构案例

作者：Petter Liu

www.cnblogs.com/wintersun

系统可用率

多级缓存

动态分组切换

   

DB物理隔离

服务分组隔离    

跨机房隔离    
 
漏斗模型    
 
 
DB限流    
 

 

 

系统一般可以分为前端应用系统和后端数据库系统，前端应用系统实施分布式集群部署技术上是比较成熟的，后端数据库系统实现异地多活技术难度很大，目前也只有阿里，京东这样的公司才真正实现。

因此，对于大多数应用，前端应用双机房集群部署，后端数据库系统采取成熟的主备从的模式，也就是单个机房作为写入，备库在另外机房，可以快速进行切换，读库双机房部署，是优选的方案。

对于这个架构方案，存在跨机房写延长的问题，可以根据场景利用异步的方式进行解决，一般也是没有问题的。对于系统来讲，也有些特别，利用分拣中心的本地服务器和操作人员的设备，实现离线生产，进一步提高可用性。

大系统小做，服务拆分，是互联网应用的特点，也符合敏捷交付的理念。对于传统软件，如Windows，Office等，都要经过一个漫长的需求，研发，测试，发布周期，在“唯快不破”的互联网时代，这显然是无法满足业务要求的，即使最后上线，也可能因为周期太长而不再适用了。

因此，对一个互联网服务，一般会首先完成最核心的功能，快速进行上线，不断进行迭代，后续再进行辅助功能跟进。对于核心功能，随着用户数的增加，会不断进行服务拆分，如何进行拆分，拆分到什么样的粒度，是不是微服务是解决问题的银弹？这些都要根据实际的应用场景来评估，绝不是越细越好，而是要达到一个优雅的平衡。

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

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

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

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

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

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

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

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

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

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

在对业务能首先是业务数据化，并且具有数据质量保障。系统的支撑下，实现了所有物流操作的线上化，也就是数据化，并且，对每个操作环节都是可以进行实时分析，这就奠定了很好的基础。如果业务都是线下操作，或者系统无法准确及时收集数据，那么，即时数据量够大，缺乏关键数据和数据不准确，也会给大数据处理带来很大的困难。

第二基础就是大数据处理技术，包括收集，传输，存储，计算，展示等一系列技术。够进行实时监控和准确评估后，也就是利用大数据对业务进行预测。预测一直是大数据应用的核心，也是最有价值的地方。

对于物流行业，如果能够提前进行业务量预测，那么，对于资源调度等非常有意义，不仅能够实现更好的时效，而且能够避免浪费。举一个的例子，就是单量预测，根据用户下单量，仓储生产能力，路由情况等，可以进行建模预测。

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

长按订阅更多精彩▼