vlambda博客
学习文章列表

赠书:聊聊「分布式架构」那些事儿

什么是分布式架构?

分布式架构是分布式计算技术的应用和工具,其中J2EE技术应用较为广泛,它简化和规范多层分布式企业应用系统的开发和部署,它可以给分布式应用软件提供在各种技术间共享资源的平台


分布式架构发展



众所周知,传统架构单一无分层,模块之间耦合性过高导致稳定性和扩展性较差,无法满足互联网高速迭代变化的脚步,技术架构也会发生很大变化。传统架构逐渐分化为分布式架构。提供更稳定、容错、高可用的特质。演变过程如下图所示。


阶段1



赠书:聊聊「分布式架构」那些事儿

阶段2




赠书:聊聊「分布式架构」那些事儿

阶段3




赠书:聊聊「分布式架构」那些事儿

阶段4




赠书:聊聊「分布式架构」那些事儿

阶段5



分布式架构设计理念和目标



设计理念:分布式架构的核心理念按照一定维度(功能、业务、领域)等,对系统进行拆分,通过合理的拆分结构,实现各业务模块解耦,同时通过系统级容错设计,在廉价硬件基础设施上构建起高可用、可扩展的开放技术体系。

目标:设计目标可以明确方向,通过设计驱动和方向的把控,朝着既定方向前行并最终实现目标。设计目标分为以下方面:


系统拆分

  • 以业务为导向,充分了解系统业务模型,按不同层面的业务模型上可以划分为主模型、次模型。业务模型在一定的比例上能够凸显出系统的业务领域及边界;

  • 业务依赖范围,由于业务存在重复依赖,从业务边界中按照业务功能去细分;

  • 把拆分结构图梳理出来,按照系统周边影响从小到大逐渐切换;

  • 拆分过程中尽量不要引入新的技术或者方案,如需讨论评估后再实施。


业务模块解耦

拆分之前可能模块和模块之间、系统和系统之间有非常强的依赖,所以我们在拆分过程中需要思考,哪些模块需要减少依赖,依赖越少,独立性越强


系统容错

  • 架构设计层面(重试、服务降级、熔断和限流)

  • 业务功能层面(幂等、异步处理、事务补偿机制)


高可用

  • 单点系统面临严重高可用问题,所以在设计过程中要尽量避免系统的单点出现,保证系统处于多机状态,俗称冗余。冗余指重复配置系统某些部件,当系统发生故障不可用时,冗余配置的部件介入并承担故障部件的工作,减少系统的故障时间。

  • 通过设计和监控可以提高系统正常提供服务的可靠性,那么,如何才能保障系统的高可用。


赠书:聊聊「分布式架构」那些事儿


赠书:聊聊「分布式架构」那些事儿




分布式架构应用场景


•适用于对数据密集/实时要求比较高的项目或系统•适用于对服务器高可用运用指数较高的系统•适用于大型业务复杂/统计类系统


赠书:聊聊「分布式架构」那些事儿



分布式架构难点


•网络因素

网络延迟:延迟是指在传输介质中传输所用的时间,如部署在同个机房,网络IO传输相对较快,但是很多公司为了增加系统的可用性,有多套机房(线上、线下)等,此时会面临跨机房、跨网络传输。尤其跨IDC,网络IO会存在不确定性,出现延迟、超时等情况,大家都知道宽带有瓶颈可以换网卡,但从根本上不能解决物理延迟。由于这些现象会给整个设计带来整体性的难点,我们在做分布式架构设计的同时需要考虑这些要素,并且提供相关高效解决方案,从而规避此问题

网络故障:若出现网络故障问题,可以先了解数据是以什么协议方式在网络中传输导致丢包、错乱。然后采用比较稳定的TCP网络协议进行传输


•服务可用性

a.由于探针监控是定时去请求访问服务器,通过请求回应来收集服务器状态。定时需设置在合理范围值内,太短会给服务器带来压力,太长会导致不能及时收集报错信息,而错过最佳时机。基于以上情况,可以采用服务器集群化的方式,根据系统场景,设置合理探针请求频率,当发现异常及时剔除替换

b. 为了保证服务器正常运行,可对服务器进行监控,如探针、心跳检测等,而这些仅仅是针对服务器的运行数据和日志分析。为了提高服务器服务的可用性,可进一步实施服务器负载均衡、主从切换、故障转移等


•数据一致性

a. 可以从系统构建层面减少这种现象发生,采用分布式事务进行处理,存在牺牲一部分性能去弥补数据一致性。

b. 由于数据架构需要提供多节点部署,不同节点之间通信存在数据差异,在很多场景下会往往产生脏数据、异常数据,让业务不能正常运转。数据一致性指,关联数据之间的逻辑关系是否正确和完整,那么分布式情况下如何让不同模块之间的数据保证完整性、一致性。



赠书:聊聊「分布式架构」那些事儿



分布式架构解决痛点


•系统宕机

系统业务量逐渐增多,导致系统压力增大,通过监控和各方面指标发现系统频繁报警,通过优化让系统变的稳定,降低负载。最直接的方式是增加系统容量,调整系统参数,但是通过硬件扩展并非解决问题的最优方式,会存在以下弊端

硬件设备费用高额后续会带来更大的维护代价

进一步优化过程需要垂直或者水平拆分业务系统,按照一定维度拆分成多个模块,降低耦合性,通过合理的设计方案,从端到端、点到点优化,让系统变得健壮,为后续复杂业务提供模块化管理和运营。

分布式的架构体系具有良好的横向扩展性,通过横向扩展机器能够快速高效提高系统的并发量和吞吐量,为复杂的业务系统提供良好支撑。而分布式架构体系调用过程较长,从外界流量入口分发、代理服务、网络传输、容器、应用服务、数据存储,存在很高的优化空间,通过合理的设计方案能让系统承载更多更高的指标,从而稳定运行.


•系统瘫痪

很多外部因素也会导致系统瘫痪,如机房停电、线路关闭、网络堵塞等,因此需要一套完整的分布式架构方案(高可用、监控、故障转移等)来支撑。

系统在构建时期需要考虑这些外在因素,然后构思设计相应的处理方案,通过设计方案然后落地,在测试环境中演练外在因素导致系统瘫痪场景,不断探索、改进、完善,这样,当外部因素真的出现时,系统可以从容面对,从侧面凸显出系统的健壮。

分布式架构体系中针对以上场景有众多解决方案,会从设计之初就会考虑这些因素,确保系统是可用的、可靠的。而多机房部署就能从根源上解决由机房停电引起的事故.


•系统故障

当系统发生故障,因系统构建庞大,维修排查故障时间过久,影响用户群体使用。

分布式架构中讲究系统拆分模块化,使用更轻量级的模块、可用的部署策略,从一定程度上规避掉故障风险,如出现故障,通过有效的故障转移方式能让系统在短时间之内正常服务


•系统臃肿

分布式架构中可拆分模块化,模块细化后可读性、维护性会变得简单明了,针对细化后的模块可更专注开发和优化,系统庞大内核聚集多,导致臃肿。迭代维护运营成本高额,风险过大






技术大厂使用状况


•阿里巴巴

初级阶段阿里巴巴已拥有规模庞大的用户,业务体系复杂,业务之间相互依赖较高,不能给客户提供好的服务和体验。

阿里巴巴规划使用分布式架构,通过多条业务线的拆分,让业务模块之间相互解耦,减低依赖,提高系统间的容错和稳定性。

阿里巴巴在此期间研发了多项分布式技术和框架,如:Dubbo(微服务)、Rocketmq(消息队列)、OSS(资源存储)、Tair(缓存)、Xdb(数据库)等等。其中面对国内每年的’双11‘,淘宝/天猫等商城系统每年都会面对较大的压力,压力多方面来自于用户数的增加(多用户的请求频率和次数),之所以能够提供给用户良好的体验和使用量,阿里的技术体系尤为重要,每年的’双11‘都是阿里的自家技术的实战和分析。技术创新、技术沉淀让阿里在国内首屈一指

•百度

百度是一家做搜索引擎及其人工智能的企业,搜索业务场景复杂多变,搜索涉及信息较广。最初搜索体验不好,搜索结果不太准确。

百度拥有’独立搜索引擎核心技术‘,每天面对来自百余个国家和地区的数十亿次搜索请求,为了满足用户需求和提高体验,不断坚持技术创新、优化分布式搜索引擎、分布式存储(Tera)


总结



分布式发展过程经历了传统单体结构、集群化结构等。它的发展都离不开业务场景,业务场景是驱动技术架构变革的载体。本章重点讲述了大型系统在分布式环境中面临的问题,分布式环境中存在诸多不确定性因素,系统从构建到发展成型,会经历很多阶段,而不同阶段需要关注点不同,所以设计之初需考虑全面。从而让系统在面临诸多不确定因素时有多种容错方式,整体提高系统的稳定性。



RECOMMEND

推荐阅读

 
   
   
 

抽奖赠书


截止时间:2020年8月2日 17:00