作者 | 阿凡博客
出品 | CSDN博客
封图 | 视觉中国
某些App怎么扛住1分钟10亿请求&＃xff1f;
架构的演进路线
百万级并发&＃xff1a;1秒100万次请求。
千万级并发&＃xff1a;一分钟6亿次请求&＃xff0c;差不多就是需求的极限。
架构的设计和架构优化要符合需求本身&＃xff0c;不能无限制优化。
基本概念
&＃xff08;1&＃xff09;分布式&＃xff08;系统中&＃xff0c;多个模块在不同服务器上部署&＃xff09;
&＃xff08;2&＃xff09;集群&＃xff08;一个软件部署在多台服务器&＃xff0c;并作为一个整体&＃xff0c;提供一类服务&＃xff09;
&＃xff08;3&＃xff09;高可用&＃xff08;系统中部分节点失效&＃xff0c;其他节点能够接替它继续工作或有相应的处理预案&＃xff09;
&＃xff08;4&＃xff09;负载均衡&＃xff08;把请求均匀的发到多个节点上&＃xff09;
架构演进&＃xff1a;
单机架构
DNS服务器&＃xff0c;做域名解析的服务器&＃xff0c;作用是&＃xff0c;经过DNS将www.taobao.com这类的域名转换为实际IP地址&＃xff0c;浏览器转而访问这个IP对应的tomcat。
瓶颈&＃xff1a;用户增长&＃xff0c;tomcat和数据库之间竞争资源&＃xff0c;单机性能不足以支撑业务。
第一次&＃xff1a;Tomcat和数据库分开部署&＃xff08;最常见架构&＃xff09;
Tomcat和数据库分别独占服务器资源&＃xff0c;显著提高两者各自性能&＃xff08;tomcat服务器找一个内存大的&＃xff0c;DB服务器找一个硬盘大的&＃xff0c;带宽更宽的&＃xff09;。
瓶颈&＃xff1a;用户量增长&＃xff0c;数据库并发读写&＃xff0c;尤其是读&＃xff0c;成为瓶颈。
注意&＃xff0c;不会通过数据库集群解决。
第二次演进&＃xff1a;引入本地缓存甚至分布式缓存
在Tomcat服务器上&＃xff08;Java程序所在的地方&＃xff09;加入缓存&＃xff0c;可以把绝大多数请求&＃xff08;尤其是查询&＃xff09;在访问数据库前拦截掉。
Redis放在Tomcat服务器上&＃xff0c;如果不够用。
那么Redis可以自己放在一个服务器&＃xff0c;也可以多弄几台Redis服务器&＃xff0c;配置成主从同步&＃xff08;提升可用性可以加上哨兵&＃xff09;。
瓶颈&＃xff1a;用户数量增长&＃xff0c;并发压力主要在单机的tomcat上&＃xff0c;响应逐渐变慢。
第三次演进&＃xff1a;引入反向代理和负载均衡
使用反向代理&＃xff0c;将大量的用户请求&＃xff0c;均匀分发到每个Tomcat中&＃xff08;一般来讲&＃xff0c;Tomcat对应100个并发&＃xff0c;nginx对应5万个并发&＃xff0c;具体的要看服务器性能&＃xff09;。
瓶颈&＃xff1a;应用服务器可支持的并发量大大增加&＃xff0c;缓存能力也可以轻易扩展&＃xff0c;并发量增长意味着更多请求穿透到数据库&＃xff0c;单机的数据库最终成为瓶颈。
第四次演进&＃xff1a;数据库读写分离
把数据库划分为读库和写库&＃xff0c;读库可以有多个&＃xff0c;通过同步机制把写库的数据同步到读库&＃xff0c;使用数据库中间件&＃xff08;Mycat&＃xff09;&＃xff0c;通过它来组织数据库的分离读写。
瓶颈&＃xff1a;业务逐渐变多&＃xff0c;不同业务之间的访问量差距较大&＃xff0c;不同业务直接竞争数据库&＃xff0c;相互影响性能。
第五次演进&＃xff1a;数据库按业务分库
把不同的业务数据保存到不同的数据库中&＃xff0c;业务之间的资源竞争降低&＃xff0c;访问量大的业务可以部署更多的服务器。
瓶颈&＃xff1a;用户数量增长&＃xff0c;单机的写库会逐渐达到性能瓶颈。
第六次演进&＃xff1a;把数据库的大表拆成小表
其他环节同上。
比如针对订单生成&＃xff0c;可以按照月份&＃xff0c;甚至小时创建表。
这种做法可以称作分布式数据库&＃xff0c;但逻辑上仍然是一个完整的数据库整体&＃xff0c;现在有一种架构叫MPP&＃xff08;大规模并行处理&＃xff09;&＃xff0c;针对于各种这类问题的使用场景。
瓶颈&＃xff1a;数据库和tomcat都可以大规模水平扩展&＃xff0c;最终单机的nginx会成为瓶颈。
第七次演进&＃xff1a;使用LVS让多个Nginx负载均衡
LVS是软件&＃xff0c;运行在操作系统内核态&＃xff0c;可以对TCP请求或高层网络协议进行转发&＃xff0c;分发的性能远高于Nginx&＃xff0c;大概十几万。
F5是硬件&＃xff0c;跟LVS做的事情类似&＃xff0c;但性能更高&＃xff0c;而且价格昂贵。
这种方式&＃xff0c;用户可达千万或上亿级别。
瓶颈&＃xff1a;LVS达到瓶颈&＃xff0c;或用户分布在不同的地区&＃xff0c;与服务器机房的距离不同&＃xff0c;导致访问延迟的不同。
第八次演进&＃xff1a;DNS轮询实现机房间的负载均衡
在DNS中配置一个域名对应多个IP。
每个IP地址对应到不同的机房里的虚拟IP。
做到机房级别的水平扩展&＃xff0c;已经是从请求并发量来讲&＃xff0c;过亿的处理方案&＃xff0c;十几亿或几十亿的并发&＃xff0c;暂时没人考虑。
瓶颈&＃xff1a;检索&＃xff0c;分析的需求越来越多&＃xff0c;单靠数据库无法解决各种各样的需求。
第九次演进&＃xff1a;引入NoSQL数据库和搜索引擎
数据量多到一定规模的时候&＃xff0c;关系型数据库不再适用&＃xff0c;而且数据量较大的查询&＃xff0c;MySQL不一定能运行出结果&＃xff0c;对于海量数据的处理&＃xff0c;通过分布式文件系统HDFS来存储&＃xff0c;对于key-value类型的数据&＃xff0c;通过HBase、Redis等处理&＃xff0c;对于抓取查询&＃xff0c;可以通过ES等解决&＃xff0c;对于多维分析&＃xff0c;通过kylin、Druid等解决。
引入更多的组件同时必然极大的提高系统复杂度&＃xff0c;不同的组件的数据还需要同步&＃xff0c;需要考虑一致性问题。
第十次演进&＃xff1a;大应用拆为小应用
结构图中上下不变&＃xff1a;
按照业务板块来划分应用&＃xff0c;使单个应用的职责更清晰&＃xff0c;相互之间可以做到独立升级迭代&＃xff0c;甚至可以做到部分功能关闭。
瓶颈&＃xff1a;不同应用之间&＃xff0c;存在公用的模块&＃xff0c;导致包含公共功能的部分在升级时&＃xff0c;全部相关代码都要跟着升级。
第十一次演进&＃xff0c;抽离成微服务
类似于我们现在写的SpringCloud的项目结构&＃xff0c;尤其是当用户&＃xff0c;支付等功能在多个应用中都存在&＃xff0c;抽离出来效率更高
现在想实现这种效果&＃xff0c;可以用现成的框架。
再往下演进&＃xff0c;ESB服务总线做接口管理&＃xff0c;容器化技术实现运行环境隔离&＃xff0c;云平台承载大型系统
云平台中的几个概念&＃xff1a;
IaaS&＃xff1a;基础设施即服务&＃xff0c;可申请硬件资源的层面。
PaaS&＃xff1a;平台即服务&＃xff0c;提供云平台常用的技术组件的开发和维护。
SaaS&＃xff1a;软件即服务&＃xff0c;开发好一个应用&＃xff0c;部署之后&＃xff0c;按照功能或要求付费。
总结
&＃xff08;1&＃xff09;架构调整是否必须按照上面的路线演变&＃xff1f;
不一定&＃xff01;&＃xff01;&＃xff01;上面讲的是电商方向&＃xff0c;已有的演化线路。
&＃xff08;2&＃xff09;对于即将实施的系统&＃xff0c;架构要设计到什么程度&＃xff1f;
够用就行&＃xff0c;问清楚什么叫够用&＃xff0c;设计要满足下一阶段用户量和性能指标的要求。
&＃xff08;3&＃xff09;微服务和大数据架构&＃xff1f;
这俩架构&＃xff0c;解决的是同一个系统中&＃xff0c;不同环节的问题。
不用比好坏&＃xff0c;也不用分开处理。
版权声明&＃xff1a;本文为CSDN博主「阿凡博客」的原创文章&＃xff0c;遵循 CC 4.0 BY-SA 版权协议&＃xff0c;转载请附上原文出处链接及本声明。
原文链接&＃xff1a;
https://blog.csdn.net/qq_43107323/article/details/104919132
【END】
热 文 推 荐
☞软件欺诈的骗局揭露&＃xff1a;“替罪羊”究竟是如何构建的&＃xff1f;
☞遗留代码写的烂&＃xff0c;我能怎么办&＃xff1f;
☞Python 爬取疫情期间全球股市走向&＃xff0c;笑不出来......
☞无代码时代来临&＃xff0c;程序员如何保住饭碗&＃xff1f;
☞从零开始构建&＃xff1a;使用CNN和TensorFlow进行人脸特征检测
☞另一种声音&＃xff1a;容器是不是未来&＃xff1f;
☞探索比特币独特时间链、挖矿费用及场外交易的概念
你点的每个“在看”&＃xff0c;我都认真当成了喜欢
京公网安备 11010802041100号