系统架构演进过程Word格式文档下载.docx
- 文档编号:21207510
- 上传时间:2023-01-28
- 格式:DOCX
- 页数:11
- 大小:309.45KB
系统架构演进过程Word格式文档下载.docx
《系统架构演进过程Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《系统架构演进过程Word格式文档下载.docx(11页珍藏版)》请在冰豆网上搜索。
同时,如果系统初期就设计一个千万级并发的流量架构,很难有公司可以支撑这个成本。
因此,一个大型服务系统都是从小一步一步走过来的,在每个阶段,找到对应该阶段网站架构所面临的问题,然后在不断解决这些问题,在这个过程中整个架构会一直演进。
那我们来一起看一下。
1单服务器-俗称allinone
从一个小网站说起。
一台服务器也就足够了。
文件服务器,数据库,还有应用都部署在一台机器,俗称ALLINONE。
随着我们用户越来越多,访问越来越大,硬盘,CPU,内存等都开始吃紧,一台服务器已经满足不了。
这个时候看一下下一步演进。
2数据服务与应用服务分离
我们将数据服务和应用服务分离,给应用服务器配置更好的CPU,内存。
而给数据服务器配置更好更大的硬盘。
分离之后提高一定的可用性,例如FilesServer挂了,我们还是可以操作应用和数据库等。
随着访问qps越来越高,降低接口访问时间,提高服务性能和并发,成为了我们下一个目标,发现有很多业务数据不需要每次都从数据库获取。
3使用缓存,包括本地缓存,远程缓存,远程分布式缓存
因为80%的业务访问都集中在20%的数据上,也就是我们经常说的28法则。
如果我们能将这部分数据缓存下来,性能一下子就上来了。
而缓存又分为两种:
本地缓存和远程缓存缓存,以及远程分布式缓存,我们这里面的远程缓存图上画的是分布式的缓存集群(Cluster)。
3.1思考的点
1.1.具有哪种业务特点数据使用缓存?
2.2.具有哪种业务特点的数据使用本地缓存?
3.3.具有哪种务特点的数据使用远程缓存?
4.4.分布式缓存在扩容时候会碰到什么问题?
如何解决?
分布式缓存的算法都有哪几种?
各有什么优缺点?
5.
这个时候随着访问qps的提高,服务器的处理能力会成为瓶颈。
虽然是可以通过购买更强大的硬件,但总会有上限,而且这个到后期成本就是指数级增长了,这时,我们就需要服务器的集群。
需要使我们的服务器可以横向扩展,这时,就必须加个新东西:
负载均衡调度服务器。
4使用负载均衡,进行服务器集群
增加了负载均衡,服务器集群之后,我们可以横向扩展服务器,解决了服务器处理能力的瓶颈。
4.1思考的点
1.1.负载均衡的调度策略都有哪些?
2.2.各有什么优缺点?
3.3.各适合什么场景?
打个比方,我们有轮询,权重,地址散列,地址散列又分为原ip地址散列hash,目标ip地址散列hash,最少连接,加权最少连接,还有继续升级的很多种策略......
我们一起来分析一下。
典型负载均衡策略分析
1.1.轮询:
优点:
实现简单,缺点:
不考虑每台服务器处理能力
2.2.权重:
考虑了服务器处理能力的不同
3.3.地址散列:
能实现同一个用户访问同一个服务器
4.4.最少连接:
使集群中各个服务器负载更加均匀
5.5.加权最少连接:
在最少连接的基础上,为每台服务器加上权值。
算法为(活动连接数*256+非活动连接数)/权重,计算出来的值小的服务器优先被选择。
6.
继续引出问题的场景
我们的登录的时候登录了A服务器,session信息存储到A服务器上了,假设我们使用的负载均衡策略是iphash,那么登录信息还可以从A服务器上访问,但是这个有可能造成某些服务器压力过大,某些服务器又没有什么压力,这个时候压力过大的机器(包括网卡带宽)有可能成为瓶颈,并且请求不够分散。
这时候我们使用轮询或者最小连接负载均衡策略,就导致了,第一次访问A服务器,第二次可能访问到B服务器,这个时候存储在A服务器上的session信息在B服务器上读取不到。
4.2Session管理-SessionSticky粘滞会话:
打个比方就是如果我们每次吃饭都要保证我们用的是自己的碗筷,而只要我们在一家饭店里存着我们的碗筷,只要我们每次去这家饭店吃饭就好了。
对于同一个连接中的数据包,负载均衡会将其转发至后端固定的服务器进行处理。
解决了我们session共享的问题,但是它有什么缺点呢?
1.1.一台服务器运行的服务挂掉,或者重启,上面的session都没了。
2.2.负载均衡器成了有状态的机器,为以后实现容灾造成了羁绊。
4.3Session管理-Session复制
就像我们在所有的饭店里都存一份自己的碗筷。
我们随意去哪一家饭店吃饭都OK,不适合做大规模集群,适合机器不多的情况。
1.1.应用服务器间带宽问题,因为需要不断同步session数据。
2.2.大量用户在线时,服务器占用内存过多。
4.4Session管理-基于Cookie
打个比方,就是我们每次去饭店吃饭,都自己带着自己的碗筷。
1.1.cookie的长度限制。
2.2.cookie存于浏览器,安全性是一个问题。
4.5Session管理-Session服务器
打个比方,就是我们的碗筷都存在了一个庞大的橱柜里,我们去任何一家饭店吃饭,都可以从橱柜中拿到属于我们自己的碗筷。
解决了我们session共享的问题,这种方案需要思考哪些问题呢?
1.1.保证session服务器的可用性,session服务器单点如何解决?
2.2.我们在写应用时需要做调整存储session的业务逻辑
打个比方,我们为了提高sessionserver的可用性,可以继续给sessionserver做集群。
5中间总结
所以说,网站架构在遇到某些指标瓶颈时,演进的过程中,都有哪些解决方案,他们都有什么优缺点?
业务功能上如何取舍?
如何做出选择?
这个过程才是最重要的。
在解决了横向扩展应用服务器之后,那我们继续~~
继续回到目前架构图
数据库的读及写操作都还需要经过数据库。
当用户量达到一定量,数据库将会成为瓶颈。
那我们如何来解决呢?
6数据库读写分离
使用数据库提供的热备功能,将所有的读操作引入slave服务器,因为数据库的读写分离了,所以,我们的应用程序也得做相应的变化。
我们实现一个数据访问模块(图中的dataaccessmodule)使上层写代码的人不知道读写分离的存在。
这样多数据源读写分离就对业务代码没有了侵入。
这里就引出了代码层次的演变。
6.1思考的点
1.1.如何支持多数据源?
2.2.如何封装对业务没有侵入?
3.3.如何使用目前业务的ORM框架完成主从读写分离?
是否需要更4.换ORM模型?
ORM模型之间各有什么优缺点?
4.4.如何取舍?
数据库读写分离会遇到如下问题:
1.1.在master和slave复制的时候,考虑延时问题、数据库的支持、复制条件的支持。
2.2.当为了提高可用性,将数据库分机房后,跨机房传输同步数据,这个更是问题。
3.3.应用对于数据源的路由问题。
7使用反向代理和CDN加速网站响应
使用CDN可以很好的解决不同的地区的访问速度问题,反向代理则在服务器机房中缓存用户资源。
访问量越来越大,我们文件服务器也出现了瓶颈。
8分布式文件系统
8.1思考的点
1.分布式文件系统如何不影响已部署在线上的业务访问?
不能让某个图片突然访问不到呀
2.是否需要业务部门清洗数据?
3.是否需要重新做域名解析?
这个时候数据库又出现了瓶颈。
9数据垂直拆分
数据库专库专用,如图Products、Users、Deal库。
解决写数据时,并发,量大的问题。
9.1思考的点
1.跨业务的事务?
使用分布式事务、去掉事务或不追求强事务
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 架构 演进 过程