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

更新日期: 2019-04-30阅读: 1.7k标签: 架构

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 

 

链接: https://fly63.com/article/detial/3155

微内核架构在大型前端系统中的应用

架构和框架是独立的,本文仅仅是提出一种架构思路,而且这个架构也在百度的某款用户量很大的复杂前端产品中得以应用。基于这一套弹性架构并结合Vue/React的现代化开发理念,可以很好的完成高复杂度的前端系统。

怎么判定web前端架构师的能力高低?

软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。传统软件架构描述的对象是直接构成系统的抽象组件,侧重于系统的抽象、拆分、组织方式等

成为一个顶尖架构师

架构师的一个重要职责是,确保团队有共同的技术愿景,以帮助我们向客户交付他们想要的系统。在某些场景下,架构师只需要和一个团队一起工作,这时他们等同于技术引领者。在其他情况下,他们要对整个项目的技术愿景负责,通常需要协调多个团队之间,甚至是整个组织内的工作。

C/S和B/S两种架构区别与优缺点分析

C/S 架构是一种典型的两层架构,其全程是Client/Server,即客户端服务器端架构,其客户端包含一个或多个在用户的电脑上运行的程序,而服务器端有两种,一种是数据库服务器端,客户端通过数据库连接访问服务器端的数据

架构/构建高可用的网站

目的为保证服务器硬件故障时依然可用,数据依然保持并能够访问,手段:数据和服务的冗余备份以及失效转移机制,有状态 :在服务端保留之前的请求信息,用以处理当前请求(例如:session)无状态 :没有特殊状态的服务

大型web系统架构详解

动态应用,是相对于网站静态内容而言,是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件,比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。

讲讲亿级PV的负载均衡架构

本来没想写这个题材的,为了某某童鞋能够更好的茁壮成长,临时写一篇负载均衡的。负载均衡,大家可能听过什么3层负载均衡、4层负载均衡、7层负载均衡什么的?那这是怎么分的呢,ok,是根据osi七层网络模型来分的,例如nginx是工作在应用层

朱晔的互联网架构实践心得:品味Kubernetes的设计理念

Kubernetes(k8s)是一款开源的优秀的容器编排调度系统,其本身也是一款分布式应用程序。虽然本系列文章讨论的是互联网架构,但是k8s的一些设计理念非常值得深思和借鉴,本人并非运维专家,本文尝试从自己看到的一些k8s的架构理念结合自己的理解来分析 k8s在稳定性

大型网站核心架构要素

一般来说,除了当前的系统功能需求外,软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。性能是网站的一个重要指标,任何软件架构设计档案都必须考虑可能会带来的性能问题。

大型网站技术架构 构建高可用的网站 高可用的服务

本章介绍如何去构建高可用的服务,关键词:服务分级,超时设置,异步调用,服务降级,幂等性设计,一些架构设计中的常用方案,但是需要结合实际业务场景进行设计,没有一套方案能解决所有问题

点击更多...

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