image

系统可用率

image

image

多级缓存

image

动态分组切换

image

DB物理隔离
image
服务分组隔离
image
跨机房隔离
image
漏斗模型
image

image
DB限流
image

image

image

image 

   

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

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

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

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

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

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

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

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

  • 实时&强一致场景:这个在大数据技术成熟之前,是非常棘手的,但是,现在解决方案已经比较成熟了。典型应用是生产系统的实时监控,例如实时生产量,各个生产环节差异量等,其实是作为生产系统的一部分。利用当前主流的大数据处理架构是可以解决的,例如线上生产库binlog实时读取,Kafaka进行数据传输,Spark进行流式计算,ES进行数据存储等。如果利用传统的ETL抽取方案来解决,频繁对生产数据库进行抽取,并不是可行的方案,因为,这样会极大的影响线上OLTP系统的性能。还可以举一个生产系统实时监控案例,架构方案是应用系统完成写数据库的同时,把内容通过消息发送,后面的大数据处理系统接收消息来进行处理,这个架构方案,对于实时性某种程度上可以保障,但是,也存在效率问题,但是,对于强一致性就非常不合适了,因为消息系统如ActiveMQ等不仅无法保障消息数据不能丢失,而且对应消息顺序也是无法保障,项目实施后,虽然采取了很多补救措施,也无法满足强一致性需求,不得不重起炉灶。
  • 实时&弱一致性场景:典型的应用场景是消息通知,例如电商的全程跟踪消息,如果个别数据出现丢失,对于用户的影响并不大,也是可以接受的,因此,可以采用更加廉价的解决方案,应用完成对应的动作后,将消息发出即可,使用方订阅对应的消息,按照主键,如订单号,存储即可。
  • 离线&强一致场景:这是典型的大数据分析场景,也就是众多的离线报表模式。从技术上,传统的ETL抽取技术也能满足要求,数据仓库对应的技术也能够解决。
  • 离线&弱一致场景:对于抓取互联网数据,日志分析等进行统计系统,用于统计趋势类的应用,可以归为此类,这类应用主要是看能够有足够廉价的方案来解决,是不是可以巧妙的利用空闲的计算资源。这个在很多公司,利用晚上空闲的计算资源,来处理此类的需求。
      在对业务能首先是业务数据化,并且具有数据质量保障。系统的支撑下,实现了所有物流操作的线上化,也就是数据化,并且,对每个操作环节都是可以进行实时分析,这就奠定了很好的基础。如果业务都是线下操作,或者系统无法准确及时收集数据,那么,即时数据量够大,缺乏关键数据和数据不准确,也会给大数据处理带来很大的困难。第二基础就是大数据处理技术,包括收集,传输,存储,计算,展示等一系列技术。够进行实时监控和准确评估后,也就是利用大数据对业务进行预测。预测一直是大数据应用的核心,也是最有价值的地方。对于物流行业,如果能够提前进行业务量预测,那么,对于资源调度等非常有意义,不仅能够实现更好的时效,而且能够避免浪费。举一个的例子,就是单量预测,根据用户下单量,仓储生产能力,路由情况等,可以进行建模预测。

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

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

希望对您系统架构,软件项目开发,运维管理,系统架构与研发管理体系, 信息安全, 企业信息化等有帮助。 其它您可能感兴趣的文章:
DevOps的基本原则与介绍
Docker与CI持续集成/CD
持续交付中高效率与高质量
持续集成CI与自动化测试
软件研发工程基础设施
容器化实践金融业案例一
云计算参考架构几例
微服务与Docker介绍
互联网直播平台架构案例一
高可用架构案例一
某互联网公司广告平台技术架构
某大型电商云平台实践
云计算参考架构几例
移动应用App测试与质量管理一
全面的软件测试
著名ERP厂商的SSO单点登录解决方案介绍一
软件项目风险管理介绍
企业项目化管理介绍
智能企业与信息化之一
由企业家基本素质想到的
敏捷软件质量保证的方法与实践
构建高效的研发与自动化运维
IT运维监控解决方案介绍
IT持续集成之质量管理
人才公司环境与企业文化
企业绩效管理系统之平衡记分卡
企业文化、团队文化与知识共享
高效能的团队建设
餐饮连锁公司IT信息化解决方案一

如有想了解更多软件研发 , 系统 IT集成 , 企业信息化,项目管理,企业管理 等资讯,请关注我的微信订阅号:

MegadotnetMicroMsg_thumb1_thumb1_thu[1]

 


作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog

posted on 2017-03-25 10:40  PetterLiu  阅读(3683)  评论(0编辑  收藏  举报