大型网站的可伸缩性架构如何设计?

时间: 2019-04-30阅读: 197标签: 架构

1. 网站架构的伸缩性设计

1.1. 不同功能进行物理分离实现伸缩

纵向分离(分层后分离):将业务处理流程上的不同部分分离部署,实现系统伸缩性。

横向分离(业务分割后分离):将不同的业务模块分离部署,实现系统伸缩性。


1.2. 单一功能通过集群规模实现伸缩

将不同功能分离部署可以实现一定程度的伸缩性,但是随着网站的访问量逐步增加,即使分离到最小粒度的独立部署,单一的服务器也不能满足业务规模的要求。因此必须使用服务器集群,即将相同服务部署在多态服务器上构成一个集群整体对外提供服务。


2. 应用服务器集群的伸缩性设计

2.1. HTTP 重定向负载均衡

利用 HTTP 重定向协议实现负载均衡。

这种负载均衡方案的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问,性能较差:重定向服务器自身的处理能力有可能成为瓶颈,整个集群的伸缩性规模有限;使用 HTTP 302 响应码重定向,可能使搜索引擎判断为 SEO 作弊,降低搜索排名。


2.2. DNS 域名解析负载均衡

利用 DNS 处理域名解析请求的同时进行负载均衡处理的一种方案。

在 DNS 服务器中配置多个 A 记录,如:

114.100.40.1 www.mysite.com
114.100.40.2 www.mysite.com
114.100.40.3 www.mysite.com

每次域名解析请求都会根据负载均衡算法计算一个不同的 IP 地址返回,这样 A 记录中配置的多个服务器就构成一个集群,并可以实现负载均衡。

DNS 域名解析负载均衡的优点:

  • 将负载均衡的工作转交给了 DNS,省掉了网站管理维护的麻烦。
  • 同时,许多 DNS 服务器还支持基于地理位置的域名解析,即将域名解析成距离用户地理最近的一个服务器地址,这样可以加快用户访问速度,改善性能。

DNS 域名解析负载均衡的缺点:

  • DNS 是多级解析,每一级 DNS 都可能缓存 A 记录,当某台服务器下线后,即使修改了 DNS 的 A 记录,要使其生效也需要较长时间。这段时间,依然会域名解析到已经下线的服务器,导致用户访问失败。
  • DNS 的负载均衡的控制权在域名服务商那里,网站无法对其做更多改善和更强大的管理。


2.3. 反向代理负载均衡

大多数反向代理服务器同时提供反向代理和负载均衡的功能。

反向代理服务器的优点是部署简单。缺点是反向代理服务器时所有请求和响应的中转站,其性能可能会成为瓶颈。


2.4. IP 负载均衡

在网络层通过修改请求目标地址进行负载均衡。负载均衡服务器(网关服务器)在操作系统内核获取网络数据包,根据负载均衡算法计算得到一台真实 Web 服务器 10.0.0.1,然后将目的 IP 地址修改为 10.0.0.1,不需要通过用户进程。真实 Web 服务器处理完成后,响应数据包回到负载均衡服务器,负载均衡服务器再将数据包原地址修改为自身的 IP 地址(114.100.80.10)发送给浏览器。

IP 负载均衡在内核完成数据分发,所以处理性能优于反向代理负载均衡。但是因为所有请求响应都要经过负载均衡服务器,集群的最大响应数据吞吐量受制于负载均衡服务器网卡带宽。


2.5. 数据链路层负载均衡

数据链路层负载均衡是指在通信协议的数据链路层修改 mac 地址进行负载均衡。

这种方式又称作三角传输方式,负载均衡数据分发过程中不修改 IP 地址,只修改目的 mac 地址,通过配置真实物理服务器集群所有机器虚拟 IP 和负载均衡服务器 IP 地址一致,从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的,由于实际处理请求的真实物理服务器 IP 和数据请求目的 IP 一致,不需要通过负载均衡服务器进行地址转换,可将响应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。这种负载方式又称作直接路由方式。

在 Linux 平台上最好的链路层负载均衡开源产品是 LVS(Linux Virtual Server)。


2.6. 负载均衡算法

负载均衡服务器的实现可以分为两个部分:

  1. 根据负载均衡算法和 Web 服务器列表计算得到集群中一台 Web 服务器的地址。
  2. 将请求数据发送到该地址对应的 Web 服务器上。

负载均衡算法通常有以下几种:

  • 轮询(Round Robin) - 所有请求被依次分发到每台应用服务器上,即每台服务器需要处理的请求数据都相同,适合于所有服务器硬件都相同的场景。
  • 加权轮询(Weighted Round Robin) - 根据服务器硬件性能情况,在轮询的基础上,按照配置权重将请求分发到每个服务器,高性能服务器能分配更多请求。
  • 随机(Random) - 请求被随机分配到各个应用服务器,在许多场合下,这种方案都很简单实用,因为好的随机数本身就很平均,即使应用服务器硬件配置不同,也可以使用加权随机算法。
  • 最少连接(Least Connection) - 记录每个应用服务器正在处理的连接数,将新到的请求分发到最少连接的服务器上,应该说,这是最符合负载均衡定义的算法。
  • 源地址 Hash(Source Hash) - 根据请求来源的 IP 地址进行 Hash 计算,得到应用服务器,这样来自同一个 IP 地址的请求总在同一个服务器上处理,该请求的上下文信息可以存储在这台服务器上,在一个会话周期内重复使用,从而实现会话粘滞。


3. 分布式缓存集群的伸缩性设计

一致性 HASH 算法


4. 数据存储服务器集群的伸缩性设计

4.1. 关系型数据库的伸缩性设计

  • 主从复制 - 主流关系型数据库一般都支持主从复制。
  • 分库 - 根据业务对数据库进行分割。制约条件是跨库的表不能进行 Join 操作。
  • 分表 - 使用数据库分片中间件,如 Cobar 等。


4.2. NoSql 数据库的伸缩性设计

一般而言,Nosql 不支持 SQL 和 ACID,但是强化了对于高可用和伸缩性的支持。


原文地址:https://www.cnblogs.com/yuxiang1/p/10790514.html 

 

链接: http://www.fly63.com/article/detial/3155

架构师教你如何设计一个高并发系统?大多程序员都收藏了

其实所谓的高并发,如果你要理解这个问题呢,其实就得从高并发的根源出发,为啥会有高并发?为啥高并发就很牛逼?我说的浅显一点,很简单,就是因为刚开始系统都是连接数据库的

Redis高可用,高性能,架构演进史

高性能就是做分片(可以类比为分库分表,将数据分到不同服务器上),在Kafka中叫分区,在mongodb中叫shard,在HDFS上叫DataNode。而保证高可用的方式就是做交叉备份。然后我很好奇Redis是怎么部署的。

业务架构师给你一些建议

搬运工: 付老师讲述了自己成为业务架构师的一些个人经历,并且也给出了学习建议,最后推荐了一些不错的书籍。希望对你成为业务架构师有帮助或者启发,也可以在完成业务开发建模等有所帮助。

从Web开发者的视角来解读MVC架构

MVC代表了一种软件框架的设计模式。该框架的主要功能是:通过允许多名开发人员共同在一个项目上开展工作,以分离应用程序的功能、逻辑和接口,进而促进有组织的编程实现方法

高级架构设计师 推荐书籍

关于程序员类的技术书籍有很多,但是往往没有时间阅读,下面的这些书籍,是由John Sonmez(《软技能》作者)精选的架构经典书籍,可以帮助你提高技术技能,让你成为一名更好的程序员

大型项目前端架构浅谈

本篇文章不会更多侧重于具体技术实现,而是尝试从更高角度出发,分析为什么要这么做,这些设计能解决什么问题,成本和收益如何。前端架构的设计,应是用于解决已存在或者未来可能发生的技术问题

前端架构师对于框架的技术选型

前端技术发展日新月异,互联网上出现的新型框架也比较多,如何让新招聘的人员能够直接上手接替项目,或者有相关人员请假,替补人员的接替工作,如何做到不同前端工程师的开发的差异性更小

vue/react/angular开发的css架构思考

前端开发现在已经从传统的后端web多页面开发模式转向前端单页SPA开发模式,而vuejs/react/angular则是开发SPA非常优秀的前端框架。组件化开发由react最早提出,vuejs后发优势,将组件化开发贯彻到了极致

微服务架构 VS 单体架构

在软件行业,微服务架构是一种重要的发展趋势。这一趋势,不仅仅是对企业内的IT信息系统建设,甚至在企业向数字化转型方面,都有着深远的影响

网站的架构

有人说过,大型网站是根据业务需求逐步演化而来的,而不是设计出来的,下面就是一个大型网站的进化过程。在初始阶段,访问量并不大,所以应用程序、数据库、文件等所有的资源都在一台服务器上。

fly63.com版权所有,内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权,请与小编联系!情况属实本人将予以删除!

广告赞助文章投稿关于web前端网站点搜索站长推荐网站地图站长QQ:522607023

小程序专栏: 土味情话心理测试脑筋急转弯幽默笑话段子句子语录成语大全