软件架构设计学习总结(12):大型网站技术架构(六)网站的伸缩性架构

网站系统的伸缩性架构最重要的技术手段就是使用服务器集群功能,通过不断地向集群中添加服务器来增强整个集群的处理能力。“伸”即网站的规模和服务器的规模总是在不断扩大。

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

网站的伸缩性设计可以分成两类,一类是根据功能进行物理分离实现伸缩,一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务,提供不同的 功能;后者是集群内的多台服务器部署相同的服务,提供相关的功能。

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

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


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

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

当一头牛拉不动车的时候,不要去寻找一头更强壮的牛,而是用两头牛来拉车。
      集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。数据服务器集群也可分为缓存数据服务器集群和存储数据服务器集群。

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

所谓应用服务器的伸缩性即:HTTP请求分发装置可以感知或者可以配置集群的服务器数量,可以及时发现集群中新上线或下线的服务器,并能向新上线的服务器分发请求 ,停止向已下线的服务器分发请求。这个HTTP请求分发装置被称为负载均衡服务器。
       负载均衡是网站必不可少的基础技术手段,不但可以实现网站的伸缩性,同时还改善网站的可用性,可谓网站的杀手锏之一。具体的技术实现也多种多样,从硬件实现到软件实现, 从商业产品到开源,应有尽有,但实现负载均衡的基础技术不外以下几种。

2.1 HTTP重定向负载均衡

HTTP重定向服务器是一台普通的应用服务器,其唯一的功能就是根据用户的HTTP请求计算一台真实的服务器地址,并将真实的服务器地址写入HTTP重定向响应中(响应状态吗302)返回给浏览器,然后浏览器再自动请求真实的服务器。

这种负载均衡方案的优点是比较简单,缺点是浏览器需要每次请求两次服务器才能拿完成一次访问,性能较差;使用HTTP302响应吗重定向,可能是搜索引擎判断为SEO作弊,降低搜索排名。重定向服务器自身的处理能力有可能成为瓶颈。因此这种方案在实际使用中并不见多。

2.2 DNS域名解析负载均衡

利用DNS处理域名解析请求的同时进行负载均衡是另一种常用的方案。在DNS服务器中配置多个A记录,如:www.mysite.com IN A 114.100.80.1、www.mysite.com IN A 114.100.80.2、www.mysite.com IN A 114.100.80.3.

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

DNS域名解析负载均衡的优点是将负载均衡工作交给DNS,省略掉了网络管理的麻烦,缺点就是DNS可能缓存A记录,不受网站控制。

事实上,大型网站总是部分使用DNS域名解析,作为第一级负载均衡手段,然后再在内部做第二级负载均衡。

2.3 反向代理负载均衡

前面我们已经讲过,反向代理可以缓存资源,改善网站性能,事实上,反向代理业可以做负载均衡,如图所示。

由于反向代理服务器转发请求在HTTP协议层面,因此也叫应用层负载均衡。优点是部署简单,缺点是可能成功系统的瓶颈。

2.4 IP负载均衡

       IP负载均衡:即在网络层通过修改请求目标地址进行负载均衡。

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

这里的关键在于真实WEB服务器相应数据包如何返回给负载均衡服务器,一种是负载均衡服务器在修改目的IP地址的同时修改源地址,将数据包源地址改为自身的IP,即源地址转换(SNAT),另一种方案是将负载均衡服务器同时作为真实物理服务器的网关服务器,这样所有的数据都会到达负载均衡服务器。

IP负载均衡在内核进程完成数据分发,较反向代理均衡有更好的处理性能。但由于所有请求响应的数据包都需要经过负载均衡服务器,因此负载均衡的网卡带宽成为系统的瓶颈。

2.5 数据链路层负载均衡

顾名思义:数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡,如下图:

这种数据传输方式又称作三角传输模式,负载均衡数据分发过程中不修改IP地址,只修改目的的mac地址,通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一样,从而达到负载均衡,这种负载均衡方式又称为直接路由方式(DR).

在上图中,用户请求到达负载均衡服务器后,负载均衡服务器将请求数据的目的mac地址修改为真是WEB服务器的mac地址,并不修改数据包目标IP地址,因此数据可以正常到达目标WEB服务器,该服务器在处理完数据后可以经过网管服务器而不是负载均衡服务器直接到达用户浏览器。

使用三角传输模式的链路层负载均衡是目前大型网站所使用的最广的一种负载均衡手段。在linux平台上最好的链路层负载均衡开源产品是LVS(linux virtual server)。

2.6 负载均衡算法

负载均衡服务器的实现可以分成两个部分:
        1、根据负载均衡算法和WEB服务器列表计算得到集群中一台WEB服务器的地址;
        2、将请求数据发送到改地址对应的WEB服务器上。

常用的负载均衡算法如下几种:
         1、轮询:即将请求依次分发到每台应用服务器上。
         2、加权轮询:根据应用服务器硬件性能情况,在轮询的基础上,安装配置的权重将请求分发到每个服务器。
         3、随机:将请求随机分配到各个应用服务器。
         4、最少连接:记录每个服务器正在处理的连接数,将新到的请求分发到最少连接的服务器上。
         5、原地址散列:根据请求来源的IP地址进行Hash计算,得到应用服务器,这样来自同一个IP地址请求总在同一个服务器上处理。

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

分布式缓存服务器集群中不同服务器中缓存的数据不相同,缓存访问请求不可用在缓存服务器集群中的任意一台处理,必须先找到缓存有需要数据的服务器,然后才能访问。 这个特点会严重制约分布式缓存集群的伸缩性设计,因为新上线的缓存服务器没有缓存数据,而已下线的缓存服务器还缓存着网站的许多热点数据。
 分布式缓存集群伸缩性设计的最主要目标即:必须让新上线的缓存服务器对整个分布式缓存集群影响最小,也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据 尽可能还被访问到。

3.1 memcached分布式缓存集群访问模型

3.2 分布式缓存的一致性Hash算法

一致性hash算法通过一个叫做一致性hash环的数据结构实现KEY到缓存服务器的Hash映射,如下图:

如果使用上面数据结构的话,那么当新添加一台缓存服务器时,只是影响到了其中一台缓存服务器,其他两头缓存服务器的压力并没有得到缓解,因此此方案还是存在问题。 一种替代的方案就是增加一个虚拟层,即把每台缓存服务器虚拟为一组服务器(比如3个虚拟网元)平均放到上面的环里面。这样当新增加缓存服务器时,把新增加的虚拟网元平均分配 到环中,这样就能缓解每台缓存服务器,达到分布式缓存集群高伸缩性。

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

和缓存服务器集群的伸缩性设计不同,数据存储服务器集群的伸缩性对数据的持久性和可用性提出了更高的要求。具体来说,又可分为关系数据库集群的伸缩性设计和NoSql数据库的伸缩性设计。

4.1 关系数据库集群的伸缩性设计

主要的关系数据库都支持数据复制功能,使用这个功能可以对数据库进行简单伸缩。
       另外除了利用数据库主从读写分离外,也可以利用业务分隔模式使不同业务的数据表部署在不同的数据库集群上,即俗称的数据分库。但是这种方式的制约条件时跨库不能进行join操作。
       在大型网站的实际应用中,即使使用了分库和主从复制,对一些单表数据任然很大的表还需要进行分片,将一张表拆开分别存储在多个数据库中。
       目前支持分布式数据分片的关系数据库产品主要有开源的Amoeba和Cobar(阿里巴巴),下图为Cobar部署模型。


       Cobar是一个分布式关系数据库访问代理,介于应用服务器和数据库服务器之间。应用程序通过JDBC驱动访问Cobar集群,Cobar服务器根据SQL和分库规则分解SQL,分发到MySQL集群不同 的数据库实例上执行(每个MySQL实例都部署为主/从结构,保证数据高可用)。
       Cobar系统组件模型如下图:

前端通信模块负责和应用程序通信,接搜到SQL请求(select * from users where userid in (12,22,23))后转交给SQL解析模块,SQL解析模块解析获得SQL中的路由规则查询条件(userid in (12,22,23))再转交给 SQL路由模块,SQL路由模块根据路由规则配置(userid为偶数路由至数据库A,奇数则路由至数据库B)将应用程序提交的SQL分解成两条SQL(select * from users where userid in (12,22);select * from users where userid in (23))转交给SQL执行代理模块,发送至数据库A和数据库B分别执行。 数据库A和数据库B的执行结果返回至SQL执行模块,通过结果合并模块将两个返回结果集合并成一个结果集,最终返回该应用程序,完成在分布式关系数据库中的一次访问请求。

Cobar的伸缩有两点:Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。
       Cobar服务器可以看做是无状态的应用服务器
,因此其集群伸缩可以简单实用负载均衡的手段实现。而MySQL中存储着数据,要保证集群扩容后数据一致负载均衡,必须要做数据迁移,如下图(利用数据同步功能进行数据迁移)。

4.2 NoSQL数据库的伸缩设计

NoSQL主要是指非关系的、分布式的数据库设计模式。一般而言,NoSQL数据库产品都放弃了关系数据库的两大重要基础:以关系代数为基础的结构化查询语言(SQL)和事物一致性保证(ACID),而强化了高可用性和可伸缩性。目前应用最广泛的是Apache HBase

时间: 2024-10-08 09:29:48

软件架构设计学习总结(12):大型网站技术架构(六)网站的伸缩性架构的相关文章

软件架构设计学习总结(14):大型网站技术架构(八)网站的安全架构

从互联网诞生起,安全威胁就一直伴随着网站的发展,各种Web攻击和信息泄露也从未停止.常见的攻击手段有XSS攻击.SQL注入.CSRF.Session劫持等. 1.XSS攻击 XSS攻击即跨站点脚本攻击(Cross Site Script),指黑客通过篡改网页,注入恶意HTML脚本,在用户访问网页时,控制用户浏览器进行恶意操作的一种攻击方式. 常见的XSS攻击类型有两种,一种是反射型,攻击者诱使用户点击一个嵌入恶意脚本的链接,达到攻击的目的,如下图所示: 另一种XSS攻击是持久型XSS攻击,黑客提

互联网技术架构演变过程-软件架构设计学习第四天(非原创)

文章大纲 一.演变过程思路图二.何为大型网站三.架构体系演进四.架构总结五.参考文章 一.演变过程思路图 二.何为大型网站 1. 大型网站特性 既然说的是大型网站架构,那么架构的背后自然是解决人因面对大型网站特性而带来的问题.这样可以先给大家说下大型网站的特性,这些特性带来的问题就是人要解决的问题:(1)高并发.大流量:PV 量巨大:(2)高可用:7*24 小时不间断服务:(3)海量数据:文件数目分分钟 xxTB:(4)用户分布广泛,网络情况复杂:网络运营商:(5)安全环境恶劣:黑客的攻击:(6

软件架构设计学习总结(22):软件架构——分层架构、事件驱动架构、微内核架构、微服务架构、基于空间的架构

分层架构 (Layered Architecture) 分层架构是最常见的架构,也被称为n层架构.多年以来,许多企业和公司都在他们的项目中使用这种架构,它已经几乎成为事实标准,因此被大多数架构师.开发者和软件设计者所熟知.比如MVC. 分层架构的一个特性就是 关注分离(separation of concerns) .在层中的组件只负责本层的逻辑.组件的划分很容易让它们实现自己的角色和职责,也比较容易地开发,测试管理和维护. 我们需要这样的冗余,即使业务层没有处理业务规则,也要通过业务层来调用数

软件架构设计常用方法-软件架构设计学习第五天(非原创) 发布成功,点击查看文章

文章大纲 一.需考虑问题二.前端架构三.应用层架构四.服务层架构五.存储层架构六.后台架构七.数据采集与监控八.安全架构九.数据中心机房架构十.自动化运维十一.参考文章 一.需考虑问题 1. 研发过程管理困难 (1)依赖管理,每个模块对其他模块的依赖是管理困难的:(2)版本管理:(3)部署管理(搭火车,难以触达到用户):(4)模块组织方式(库工程,源代码级别,没有权限).(5)构建打包痛苦:可能不能打包(2.x安装不上),合并代码搞了很久,编译打包时间过长. 2. 架构设计需考虑情况 (1)业务

软件架构设计学习总结

软件架构设计就是软件系统的'布局谋篇',是软件抽象发展到一定阶段的产物.软件设计人员学习软件架构知识,旨在站在较高的层面上,整体的解决好软件的设计,复用,质量和维护等方面的实际问题.本文以图形的方式进行总结归纳,从软件架构的描述,设计,风格,评价,形成方法进行阐述. 软件架构设计总述: 软件架构的概念 软件架构的意义 软件架构的风格 分层架构 面向服务的架构(SOA) 特定领域的架构(DSSA) 软件产品线 基于架构的软件开发(ABSD) 软件架构与质量属性 软件架构评估 -----------

软件架构设计学习总结(13):大型网站技术架构(七)网站的可扩展性架构

扩展性是指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力. 设计网站可扩展架构的核心思想是模块化,并在此基础上,降低模块间的耦合性,提供模块的复用性.模块通过分布式部署,独立的模块部署在独立的服务器上(集群)从物理上分离模块之间的耦合关系. 模块分布式部署以后具体聚合方式主要有分布式消息队列和分布式服务. 1.利用分布式消息队列降低系统耦合性 如果模块之间不存在直接调用,那么新增模块或者修改模块对其他模块影响最小,这样系统的可扩展性无疑更好一些.         事件驱动框架:通过在

软件架构设计学习总结(23):软件架构设计的6大原则

1. 单一职责原则(Single Responsibility Principle - SRP) 原文:There should never be more than one reason for a class to change. 译文:永远不应该有多于一个原因来改变某个类. 理解:对于一个类而言,应该仅有一个引起它变化的原因.说白了就是,不同的类具备不同的职责,各施其责.这就好比一个团队,大家分工协作,互不影响,各做各的事情. 应用:当我们做系统设计时,如果发现有一个类拥有了两种的职责,那

[软件架构设计学习笔记] - 软件架构概念

组成派的概念 计算组件及组件之间的交互 1.组件(程序模块.独立程序).连接件(过程调用.管道.消息   组件间的关系).约束(组件连接条件) 2.是一组具有特定形式的架构元素,这些元素分为三类:负责完成数据加工的处理元素.作为被加工信息的数据元素.用于把架构的不同部分组合在一起的连接元素 3.某个软件或计算机系统的软件架构是该系统的一个或多个结构,每个结构均由软件元素.这些元素的外部可见属性.这些元素之间的关系组成. 决策派的概念 一些重要方面做出的决策的组合 1.决策? 软件的组织,构成系统

《大型网站技术架构 -核心原理与安全分析》读书笔记

大型网站架构演化的价值观 网站的价值在于它能为用户提供什么价值,在于网站能做什么,而不在于它是怎么做的,所以在网站还很小的时候去追求网站的架构是舍本逐末,得不偿失的.小型网站最需要做的就是为用户提供好的服务来创造价值,得到用户的认可,活下去,野蛮生长. 网站架构设计误区 一味追求大公司的解决方案 大公司的经验和成功模式固然重要,值得学习借鉴,但如果因此而变得盲从,就失去了坚持自我的勇气,在架构演化的道路上迟早会迷路. 为了技术而技术 网站技术是为业务而存在的,除此毫无意义.在技术选型和架构设计中