分享

1 分钟抗住 10 亿请求!某些 App 是怎么做到的? | 原力计划

 长沙7喜 2020-03-31

某些App怎么扛住1分钟10亿请求?

架构的演进路线
百万级并发:1秒100万次请求。
千万级并发:一分钟6亿次请求,差不多就是需求的极限。
架构的设计和架构优化要符合需求本身,不能无限制优化。
基本概念
(1)分布式(系统中,多个模块在不同服务器上部署)
(2)集群(一个软件部署在多台服务器,并作为一个整体,提供一类服务)
(3)高可用(系统中部分节点失效,其他节点能够接替它继续工作或有相应的处理预案)
(4)负载均衡(把请求均匀的发到多个节点上)
架构演进:

单机架构


DNS服务器,做域名解析的服务器,作用是,经过DNS将www.taobao.com这类的域名转换为实际IP地址,浏览器转而访问这个IP对应的tomcat。
瓶颈:用户增长,tomcat和数据库之间竞争资源,单机性能不足以支撑业务。

第一次:Tomcat和数据库分开部署(最常见架构)


Tomcat和数据库分别独占服务器资源,显著提高两者各自性能(tomcat服务器找一个内存大的,DB服务器找一个硬盘大的,带宽更宽的)。
瓶颈:用户量增长,数据库并发读写,尤其是读,成为瓶颈。
注意,不会通过数据库集群解决。

第二次演进:引入本地缓存甚至分布式缓存


在Tomcat服务器上(Java程序所在的地方)加入缓存,可以把绝大多数请求(尤其是查询)在访问数据库前拦截掉。

Redis放在Tomcat服务器上,如果不够用。
那么Redis可以自己放在一个服务器,也可以多弄几台Redis服务器,配置成主从同步(提升可用性可以加上哨兵)。
瓶颈:用户数量增长,并发压力主要在单机的tomcat上,响应逐渐变慢。

第三次演进:引入反向代理和负载均衡


使用反向代理,将大量的用户请求,均匀分发到每个Tomcat中(一般来讲,Tomcat对应100个并发,nginx对应5万个并发,具体的要看服务器性能)。
瓶颈:应用服务器可支持的并发量大大增加,缓存能力也可以轻易扩展,并发量增长意味着更多请求穿透到数据库,单机的数据库最终成为瓶颈。

第四次演进:数据库读写分离

把数据库划分为读库和写库,读库可以有多个,通过同步机制把写库的数据同步到读库,使用数据库中间件(Mycat),通过它来组织数据库的分离读写。
瓶颈:业务逐渐变多,不同业务之间的访问量差距较大,不同业务直接竞争数据库,相互影响性能。

第五次演进:数据库按业务分库

把不同的业务数据保存到不同的数据库中,业务之间的资源竞争降低,访问量大的业务可以部署更多的服务器。
瓶颈:用户数量增长,单机的写库会逐渐达到性能瓶颈。

第六次演进:把数据库的大表拆成小表

其他环节同上。

比如针对订单生成,可以按照月份,甚至小时创建表。
这种做法可以称作分布式数据库,但逻辑上仍然是一个完整的数据库整体,现在有一种架构叫MPP(大规模并行处理),针对于各种这类问题的使用场景。
瓶颈:数据库和tomcat都可以大规模水平扩展,最终单机的nginx会成为瓶颈。

第七次演进:使用LVS让多个Nginx负载均衡


LVS是软件,运行在操作系统内核态,可以对TCP请求或高层网络协议进行转发,分发的性能远高于Nginx,大概十几万。
F5是硬件,跟LVS做的事情类似,但性能更高,而且价格昂贵。
这种方式,用户可达千万或上亿级别。
瓶颈:LVS达到瓶颈,或用户分布在不同的地区,与服务器机房的距离不同,导致访问延迟的不同。
第八次演进:DNS轮询实现机房间的负载均衡

在DNS中配置一个域名对应多个IP。
每个IP地址对应到不同的机房里的虚拟IP。
做到机房级别的水平扩展,已经是从请求并发量来讲,过亿的处理方案,十几亿或几十亿的并发,暂时没人考虑。
瓶颈:检索,分析的需求越来越多,单靠数据库无法解决各种各样的需求。

第九次演进:引入NoSQL数据库和搜索引擎

数据量多到一定规模的时候,关系型数据库不再适用,而且数据量较大的查询,MySQL不一定能运行出结果,对于海量数据的处理,通过分布式文件系统HDFS来存储,对于key-value类型的数据,通过HBase、Redis等处理,对于抓取查询,可以通过ES等解决,对于多维分析,通过kylin、Druid等解决。
引入更多的组件同时必然极大的提高系统复杂度,不同的组件的数据还需要同步,需要考虑一致性问题。

第十次演进:大应用拆为小应用

结构图中上下不变:

按照业务板块来划分应用,使单个应用的职责更清晰,相互之间可以做到独立升级迭代,甚至可以做到部分功能关闭。
瓶颈:不同应用之间,存在公用的模块,导致包含公共功能的部分在升级时,全部相关代码都要跟着升级。

第十一次演进,抽离成微服务

类似于我们现在写的SpringCloud的项目结构,尤其是当用户,支付等功能在多个应用中都存在,抽离出来效率更高
现在想实现这种效果,可以用现成的框架。
再往下演进,ESB服务总线做接口管理,容器化技术实现运行环境隔离,云平台承载大型系统
云平台中的几个概念:
IaaS:基础设施即服务,可申请硬件资源的层面。
PaaS:平台即服务,提供云平台常用的技术组件的开发和维护。
SaaS:软件即服务,开发好一个应用,部署之后,按照功能或要求付费。

总结

(1)架构调整是否必须按照上面的路线演变?
不一定!!!上面讲的是电商方向,已有的演化线路。
(2)对于即将实施的系统,架构要设计到什么程度?
够用就行,问清楚什么叫够用,设计要满足下一阶段用户量和性能指标的要求。
(3)微服务和大数据架构?
这俩架构,解决的是同一个系统中,不同环节的问题。
不用比好坏,也不用分开处理。
版权声明:本文为CSDN博主「阿凡博客」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多