博文精选 | 8 张图带你了解大型应用架构演进历程

2021-10-29 10:09:11

F5小安

PHPWord

文章速览:

 

行业:互联网

 

关键字:应用、互联网、运营、应用架构

 

摘要:几乎所有的大型应用都是从一个小应用开始的,好的互联网产品是慢慢运营出来的,不是一开始就开发好的,所以本篇我们来聊聊应用架构的演进历程。

 

阅读时长:5分钟

 

 

以下文章来源于InfoQ!作者:Silently9527

 

 

8张图带你了解大型应用架构演进历程

前言

先点赞再观看,要有好习惯


几乎所有的大型应用都是从一个小应用开始的,好的互联网产品是慢慢运营出来的,不是一开始就开发好的,所以本篇我们来聊聊应用架构的演进历程。


如何打造一个高可用,高性能,易扩展的应用?首先我们了解一下大型应用的特点:

  • 高可用:系统需要不间断的提供服务,不能出现单点故障

  • 高并发:在大流量的冲击下,系统依然稳定提供服务

  • 大数据:应用每天都会产生大量的数据,需要存储和管理好这些数据



最简单的架构

刚开始应用没有太多访问量,所以只需要一台服务器,这时候的架构如下图:



应用程序、文件、数据库往往都部署在一台服务器上。应用程序可以采用 Java 开发,部署在 Tomcat 服务器上,数据库可以使用开源的 MySQL



应用与数据服务分隔

随着应用的业务越来越复杂,应用访问量越来越大,导致性能越来越差,存储空间严重不足,这时候我们考虑把服务增加到三台(能通过加机器解决的问题都不是问题);分离出应用服务器、数据库服务器、文件服务器。

  • 应用服务器需要处理大量的访问,所以需要性能更好的 CPU

  • 数据库服务器需要存储大量的数据以及快速的检索,所以需磁盘的检索速度较快以及存储空间大

  • 文件服务器需要存储上传的文件,需要更大的磁盘;现在通常情况下会选择第三方的存储服务



根据每个服务器对应的场景,配置服务器后应用的性能能够大大提高,更好的支持业务的发展。但是随之业务的发展,访问量的增大,这种架构又将再次面临挑战,应用服务器处理能力下降,存储空间不足



应用服务器集群

在高并发,大流量的情况下,一台服务器是肯定处理不过来的,这个时候增加服务器,部署集群提供服务,来分担每台服务器的压力。部署集群的另一个好处是可伸缩行,比如当遇到了双 11 大流量的场景下,可以增加服务器分摊流量,等双 11 过后,减少服务器节约成本。架构如下:



如果应用服务器是 Tomcat,那么可以部署一个 Tomcat 的集群,外部在部署一个负载均衡器,可以采用随机、轮询或者一致性哈希算法达将用户的请求分发到不同应用服务集群;通常选择的免费的负载均衡是 nginx。在这种架构下,应用服务器的负载将不会是整个应用的瓶颈点;


虽然应用程序的处理速度在这种架构下提升了许多,但是又会暴露一个问题,数据库的压力大大增大,导致访问响应延迟,影响整个应用的性能。

这种架构还有个问题,通常应用是有状态的,需要记录用户的登录信息,如果每次用户的请求都是随机路由到后端的应用服务器,那么用户的会话将会丢失;解决这个问题两个方案:

  • 采用一致性 hash 把用户的请求路由到同一个 Tomcat,如果有一台服务器跪了,那么这台服务器上面的用户信息将会丢失

  • Tomcat 集群之间通过配置 session 复制,达到共享,此方案效率较低


两个方案都不是很好,那么还有其他的方案吗?请继续往下看



缓存

根据二八原则,80%的的业务都是集中访问 20%的数据,这 20%的数据通常称为热点数据,但是这 20%的数据占用的内存也不会小,如果每个应用服务器都存放一份,有些浪费存储空间,所以这时候需要考虑加入分布式缓存服务器(常用的是 Redis);当引入了分布式缓存服务器,再来看上面那个方案的问题,就可以解决了,把用户的会话存放到缓存服务器,不仅可以防止用户数据丢失,效率也不低;架构图如下:



由于分布式缓存服务器毕竟存放在远程,需要经过网络,所以取数据还是要花一点时间;本地缓存访问速度更快,但是内存空间有限,并且还会出现和应用程序争抢资源;所以这种架构搭配了分布式缓存和本地缓存,本地缓存存放少量常用热点数据,当本地缓存中没有命中时在去集中式缓存取


在引进缓存之后,数据库的访问压力可以的一定的缓解



数据库读写分离

虽然在加入了缓存之后,部分数据可以直接走缓存,不需要访问数据库,但是任然会有一些请求,会访问数据库,比如:缓存失效,缓存未命中;当流量大的时候,数据库的访问量也不小。这时候我们需要考虑搭建数据库集群,读写分离



当应用服务器有写操作时,访问主库,当应用程序有读操作时,访问从库;大多数的应用都是读的操作远远大于写的操作,所以可以配置数据库一主多从来分担数据库的压力;为了让应用程序对应主库和从库无感知,通常需要引入一些读写分离的框架做一个统一的数据访问模块。


这种架构通常需要警惕的一个问题是主从延迟,当在高并发的场景下,主库刚写成功,数据库还未成功同步完从库,这时候另一个请求进入读取数据发现不存在;解放方案是在应用程序中高并发的场景下设置强制走主库查询


兄弟们,请不要白嫖哦,文章看一半,请先点个赞



反向代理和 CDN

假如随着业务的不断扩大,全国各地都会使用到我们的应用,由于各地区的网络情况不同,所以有的人请求响应速度快,有的人请求响应速度慢,这会严重的影响到用户的体验。为了提高响应速度需要引入反向代理和 CDN;CDN 和反向代理都是采用的缓存,目的:

  • 尽可能快的把数据呈现给用户

  • 减轻后端服务器的压力


架构图如下:



CDN: 部署在网络提供商的机房,当用户来访问的时候,从距离用户最近的服务器返回数据,尽快呈现给用户;通常情况下在 CDN 中缓存的是静态资源(html,js,css),达到动静分离;但是有时候遇到了某些数据访问量特别大的时候,后端会生成静态资源放入到 CDN,比如:商城的首页,每个用户进入都需要访问的页面,如果每次请求都进入到后端,那么服务器的压力肯定不小,这种情况下会把首页生成静态的文件缓存到 cdn 和反向代理服务器


反向代理:部署在应用的中心机房,通常也是缓存的静态资源,当用户通过 CDN 未请求到需要的数据时,先进入反向代理服务器,如果有缓存用户访问的数据,那么直接返回给用户;这里也有特殊情况,对于有些场景下的热点数据,在这里根据用户的请求去分布式缓存服务器中获取,能拿到就直接返回。


这种架构已经把缓存做到了 4 级


  • 第一级:CDN 缓存静态资源

  • 第二级:反向代理缓存静态资源以及部分热点数据

  • 第三级:应用服务器的本地缓存

  • 第四级:分布式缓存服务器


通常情况下经过了这 4 级缓存,能够进入到数据库的请求也不多了,很好的释放了数据库的压力



搜索引擎和 NoSQL

随着业务的不断扩大,对于数据的存储和查询的需求也越来越复杂,通常情况我们需要引入非关系型数据库,比如搜索引擎和 NoSQL 数据库



有时候我们的查询场景很复杂,需要查询很多数据表,经过一系列的计算才能完成,这时候可以考虑通过数据同步工具(比如 canal)拉去数据到大数据平台,使用批处理框架离线计算,把输出的结果存放到搜索引擎或者 NoSQL 数据库中,应用程序直接查询计算的结果返回给用户。也有可能我们需要汇总多个表的数据做一张宽表,方便应用程序查询


由于引入的数据存储方式增多,为了减轻应用程序的管理多个数据源的麻烦,需要封装统一数据访问模块,如果使用的时 Java,可以考虑 spring-data



业务纵向拆分

互联网公司通常的宗旨是小步迭代试错快跑,当业务发展到足够大,对于单体应用想要达到这个宗旨是有难度的,随着业务的发展,应用程序越来越大,研发、维护、发布的成本也越来越大,这时候就需要考虑根据业务把单体应用拆分为多个服务,服务之间可以通过 RPC 远程调用和消息队列来一起完成用户的请求。


由于业务的拆分,通常情况下也会相应的对数据库进行拆分,达到一个服务对应一个数据库的理想状态



引入 MQ 的好处:

  • 提高系统的可用性:当消费服务器发送故障时,消息还在消息队列中,数据不会丢失

  • 加快请求的响应:当用户请求到达服务器后,把请求中可以异步处理的数据放入到 MQ,让系统逐一消费,不需要用户等待,加快了响应速度

  • 削峰填谷:当大量请求都同时进入到系统之后,会全部放入到消息队列,系统逐一消费,不会对系统造成很大的冲击



总结

还有一个情况未谈及到,就是数据库的水平拆分,这也是数据库拆分的最后手段,只有当单表数据特别大,不能满足业务的需要才使用。使用最多的还是进行数据库的业务纵向拆分,把数据库中不同业务的数据放到不同的物理服务器上。


应用当前到底选择什么架构,一定要根据实际业务的需求进行灵活的选择,驱动技术架构发展的主要动力还是在于业务的发展,不要为了技术而技术。



写在最后

  • 首先感谢大家可以耐心地读到这里。点关注,不迷路

  • 当然,文中或许会存在或多或少的不足、错误之处,有建议或者意见也非常欢迎大家在评论交流。

  • 最后,白嫖不好,创作不易,希望朋友们可以点赞评论关注三连,因为这些就是我分享的全部动力来源?


原创不易 转载请注明出处:https://silently9527.cn/archives/64


参考资料《大型网站技术架构》

 

 

以上是针对应用架构演进历程的分享,希望对大家有帮助!

 

 

 

阅读原文

 

声明:本文章版权归原作者及原出处所有 。凡本社区注明“来源:XXX或转自:XXX”的作品均转载自其它媒体,转载目的在于传递分享更多知识,内容为作者个人观点,仅供参考,并不代表本社区赞同其观点和对其真实性负责。本社区转载的文章,我们已经尽可能的对作者和来源进行了注明,若因故疏忽,造成漏注,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本社区拥有对此声明的最终解释权。

 

 

 

你还不能错过:

 

打造容器云新技术架构,加速数字化转型

 

F5社区好文推荐:软件定义一切的当下看可编程架构

 

加速架构转型,应对互联网运维挑战 —— F5助力民生银行网络智能流量编排探索

发布评论 加入社群

发布评论

相关文章

博文精选 | 亿级流量架构之服务器扩容思路及问题分析

F5小安

2022-04-22 15:45:59 14

博文精选 | 详解 | 大型分布式电商系统架构

F5小安

2021-10-12 11:00:11 102

博文精选 | 微信朋友圈架构设计

F5小安

2021-09-28 09:39:38 125

Login

手机号
验证码
© 2019 F5 Networks, Inc. 版权所有。京ICP备16013763号-1