系统可用率

多级缓存

动态分组切换

DB物理隔离

服务分组隔离

跨机房隔离

漏斗模型

DB限流

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

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

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

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

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

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

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

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

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

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