图解分布式架构的发展和演进

  • 时间:
  • 浏览:25
  • 来源:阿楠教学网 - 专注共享泼猴博客活动

编注: 架构决定的系统的稳定性,扩展性和并发性,架构的演进是从简单到简化,从单一到复合持续改进的过程,也是经验的积累和技术的结晶。

初始阶段架构

初始阶段的小型系统、应用守护应用应用程序、数据库、文件等所有的资源完整篇 都会一台服务器上。通俗称为LAMP。

形态:应用守护应用应用程序、数据库、文件等所有的资源完整篇 都会一台服务器上。

描述:通常服务器操作系统使用linux,应用守护应用应用程序使用PHP开发,咋样让 部署在Apache上,数据库使用Mysql,汇集各种免费开源软件以及一台廉价服务器就还前要开始英语 了了系统的发展之路了。

应用服务和数据服务分离

好景不长,发现随着系统访问量的再度增加,webserver机器的压力在高峰期会上升到比较高,什儿 时候 开始英语 了了考虑增加一台webserver。

形态:应用守护应用应用程序、数据库、文件分别部署在独立的资源上。

描述:数据量增加,单台服务器性能及存储空间不足英文,前要将应用和数据分离,并发解决能力和数据存储空间得到了很大改善。

使用缓存改善性能

形态:数据库中访问较集中的一小主次数据存储在缓存服务器中,减少数据库的访问次数,降低数据库的访问压力。

描述:系统访问特点遵循二八定律,即1000%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存,本地缓存访问带宽放慢但缓存数据量有限,一块儿趋于稳定与应用守护应用应用程序争用内存的请况。

使用应用服务器集群

在做完分库分表哪此工作后,数据库上的压力可能性降到比较低了,又开始英语 了了过着每天看着访问量暴增的幸福生活了,无缘无故有一天,发现系统的访问又开始英语 了了有放慢的趋势了,什儿 时候 首先查看数据库,压力一切正常,时候 查看webserver,发现apache阻塞了全都的请求,而应用服务器对每个请求也是比较快的,看来是请求数太高导致 前要排队听候,响应带宽放慢。

形态:多台服务器通过负载均衡一块儿向内部内部结构提供服务,解决单台服务器解决能力和存储空间上限的问题图片报告 。

描述:使用集群是系统解决高并发、海量数据问题图片报告 的常用手段。通过向集群中追加资源,提升系统的并发解决能力,使得服务器的负载压力不再成为整个系统的瓶颈。

数据库读写分离

享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始英语 了了放慢了,这次又是哪此请况呢,经过查找,发现数据库写入、更新的哪此操作的主次数据库连接的资源竞争非常激烈,导致 了系统放慢。

形态:多台服务器通过负载均衡一块儿向内部内部结构提供服务,解决单台服务器解决能力和存储空间上限的问题图片报告 。

描述:使用集群是系统解决高并发、海量数据问题图片报告 的常用手段。通过向集群中追加资源,使得服务器的负载压力不在 成为整个系统的瓶颈。

反向代理和CDN加速

形态:采用CDN和反向代理加快系统的 访问带宽。

描述:为了应付简化的网络环境和不同地区用户的访问,通过CDN和反向代理加快用户访问的带宽,一块儿减轻后端服务器的负载压力。CDN与反向代理的基本原理完整篇 都会缓存。

分布式文件系统和分布式数据库

随着系统的不断运行,数据量开始英语 了了大幅度增长,什儿 时候 发现分库后查询仍然会全都慢,于是按照分库的思想开始英语 了了做分表的工作。

形态:数据库采用分布式数据库,文件系统采用分布式文件系统。

描述:任何强大的单一服务器都满足不了大型系统持续增长的业务需求,数据库读写分离随着业务的发展最终也将无法满足需求,前要使用分布式数据库及分布式文件系统来支撑。分布式数据库是系统数据库拆分的最后措施,只有在单表数据规模非常庞大的时候 才使用,更常用的数据库拆分手段是业务分库,将不同的业务数据库部署在不同的物理服务器上。

使用NoSQL和搜索引擎

形态:系统引入NoSQL数据库及搜索引擎。

描述:随着业务这么 简化,对数据存储和检索的需求也这么 简化,系统前要采用全都非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据,减轻应用守护应用应用程序管理诸多数据源的麻烦。

业务拆分

形态:系统上按照业务进行拆分改造,应用服务器按照业务区分进行分别部署。

描述:为了应对日益简化的业务场景,通常使用分而治之的手段将整个系统业务分成不同的产品线,应用之间通过超链接建立关系,也还前要通过消息队列进行数据下发,当然更多的还是通过访问同一个 多数据存储系统来构成一个 多关联的完整篇 系统。纵向拆分:将一个 多大应用拆分为多个小应用,可能性新业务较为独立,这么 就直接将其设计部署为一个 多独立的Web应用系统纵向拆分相对较为简单,通过梳理业务,将较少相关的业务剥离即可。

横向拆分:将复用的业务拆分出来,独立部署为分布式服务,新增业务只前要调用哪此分布式服务横向拆分前要识别可复用的业务,设计服务接口,规范服务依赖关系。

分布式服务

形态:公共的应用模块被提取出来,部署在分布式服务器上供应用服务器调用。

描述:随着业务越拆越小,应用系统整体简化程度呈指数级上升,可能性所有应用要和所有数据库系统连接,最终导致 数据库连接资源不足英文,拒绝服务。

分布式服务应用会面临哪此问题图片报告 ?

  • (1) 当服务太久时,服务URL配置管理变得非常困难,F5硬件负载均衡器的单点压力也这么 大。
  • (2) 当进一步发展,服务间依赖关系变得错踪简化,甚至分不清哪个应用要在哪个应用时候 启动,架构师完整篇 都会能完整篇 的描述应用的架构关系。
  • (3) 接着,服务的调用量这么 大,服务的容量问题图片报告 就暴露出来,什儿 服务前要哪几只机器支撑?哪此时候 该加机器?
  • (4) 服务多了,沟通成本也开始英语 了了上升,调某个服务失败该找谁?服务的参数完整篇 都会哪此约定? 
  • (5) 一个 多服务有多个业务消费者,咋样确保服务质量?
  • (6) 随着服务的不停升级,总全都意想只有的事趋于稳定,比如cache写错了导致 内存溢出,故障不可解决,每次核心服务一挂,影响一大片,人心慌慌,咋样控制故障的影响面?服务算是还前要功能降级?可能性资源劣化?

Java分布式应用技术基础

分布式服务下的关键技术:消息队列架构

消息队列通过消息对象分解系统耦合性,不同子系统解决同一个 多消息。

分布式服务下的关键技术:消息队列原理

分布式服务下的关键技术:服务框架架构

服务框架通过接口分解系统耦合性,不同子系统通过相同的接口描述进行服务启用服务框架是一个 多点对点模型服务框架面向同构系统适合:移动应用、互联网应用、内部内部结构系统。

分布式服务下的关键技术:服务框架原理

分布式服务下的关键技术:服务总线架构

服务总线同服务框架一样,均是通过接口分解系统耦合性,不同子系统通过相同的接口描述进行服务启用服务总线是一个 多总线式的模型服务总线面向同构、异构系统适合:内部内部结构系统。

分布式服务下的关键技术:服务总线原理

分布式系统间交互5种通信模式

  • Request/Response模式(同步模式):客户端发起请求无缘无故阻塞到服务端返回请求为止。
  • Callback(异步模式):客户端发送一个 多RPC请求给服务器,服务端解决后再发送一个 多消息给消息发送端提供的callback端点,此类请况非常大概以下场景:A组件发送RPC请求给B,B解决完成后,前要通知A组件做后续解决。
  • Future模式:客户端发送完请求后,继续做我本人的事情,返回一个 多带有消息结果的Future对象。客户端前要使用返回结果时,使用Future对象的.get(),可能性此时这么 结果返回说说,会无缘无故阻塞到有结果返回为止。
  • Oneway模式:客户端调用完继续执行,不管接收端算是成功。
  • Reliable模式:为保证通信可靠,将借能助 消息中心来实现消息的可靠送达,请求将做持久化存储,在接收方在线时做送达,并由消息中心保证异常重试。

通信模式的实现措施

  • 同步点对点服务模式
  • 异步点对点消息模式1
  • 异步点对点消息模式2
  • 异步广播消息模式

分布式架构下的服务治理

服务治理是服务框架/服务总线的核心功能。所谓服务治理,是指服务的提供方和消费方达成一致的约定,保证服务的高质量。服务治理功能还前要解决将全都特定流量引入某一批机器,以及限制全都非法消费者的恶意访问,并在提供者解决量达到一定程度是,拒绝接受新的访问。

基于服务框架Dubbo的服务治理-服务管理还前要知道你的系统,对外提供了哪几只服务,还前要对服务进行升级、降级、停用、权重调整等操作还前要知道你提供的服务,谁在使用,因业务需求,还前要对该消费者实施屏蔽、停用等操作基于服务框架Dubbo的服务治理-服务监控还前要统计服务的每秒请求数、平均响应时间、调用量、峰值时间等,作为服务集群规划、性能调优的参考指标。

基于服务框架Dubbo的服务治理

  • 服务路由
  • 服务保护

基于服务总线OSB的服务治理

功能描述

说明:以上内容来自网络,作者佚名,仅供学习参考,版权归原作者所有。

本文由

架构师技术联盟

发布在

ITPUB

,转载此文请保持文章完整篇 性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/05/07/110002/