1)负载均衡(Load Balance)建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡有两方面的含义:首先,大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间;其次,单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,返回给用户,系统处理能力得到大幅度提高。
2)简单来说就是:其一是将大量的并发处理转发给后端多个节点处理,减少工作响应时间;其二是将单个繁重的工作转发给后端多个节点处理,处理完再返回给负载均衡中心,再返回给用户。目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。
根据OSI模型分的二层负载,一般是用虚拟mac地址方式,外部对虚拟MAC地址请求,负载均衡接收后分配后端实际的MAC地址响应.
一般采用虚拟IP地址方式,外部对虚拟的ip地址请求,负载均衡接收后分配后端实际的IP地址响应. (即一个ip对一个ip的转发, 端口全放开)
在三次负载均衡的基础上,即从第四层"传输层"开始, 使用"虚拟ip+port"接收请求,再转发到对应的机器。四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器;
从第七层"应用层"开始, 根据虚拟的url或IP,主机名接收请求,再转向相应的处理服务器。七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器。
我们运维中最常见的四层和七层负载均衡,这里重点说下这两种负载均衡。
二层负载均衡又称为数据链路层负载均衡。主要的实现方式就是PPP捆绑和链路聚合技术。
以太网链路聚合简称链路聚合,它通过将多条以太网物理链路捆绑在一起成为一条逻辑链路,从而实现增加链路带宽的目的。同时,这些捆绑在一起的链路通过相互间的动态备份,可以有效地提高链路的可靠性。
链路聚合需要用到LACP协议。LACP(Link Aggregation Control Protocol,链路聚合控制协议)协议是一种实现链路动态聚合的协议,运行该协议的设备之间通过互发LACPDU(Link Aggregation Control Protocol Data Unit,链路聚合控制协议数据单元)来交互链路聚合的相关信息。
链路聚合
PPP捆绑是将多个物理链路合并或者捆绑成一个大逻辑链路的机制。主要起到增加带宽,减少延时,线路备份的作用,另外一个作用是可以将不同类型的接口捆绑为一个逻辑接口。
MLPPP是由LCP在初始化时设置的一个功能选项。MLPPP将packet分成多个小块的片段同时送到远端router,LCP再将它们恢复成完整的packet。
可以在接口或拨号设备上使用下面命令对MLPPP进行配置:
MLPPP配置过程:
PPP捆绑示例
三层负载均衡也就是网络层的负载均衡,需要用到网络层的协议,如OSPF协议,RIP协议等。
首先简要的说一下OSPF,OSPF路由协议是一种典型的链路状态路由协议,一般用于同一个路由域内。在这里,路由域是是指一组通过统一的路由政策或路由协议互相交换路由信息的网络。在这个AS中,所有的OSPF路由器都维护一个相同的描述这个 AS结构的数据库,该数据库中存放的是路由域中相应链路的状态信息,OSPF路由器正是通过这个数据库计算出其OSPF路由表的。 OSPF将链路状态广播数据包LSA传送给在某一区域内的所有路由器,这一点与距离矢量路由协议不同。运行距离矢量路由协议的路由器是将部分或全部的路由表传递给与其相邻的路由器。
OSPF会自动计算接口上的Cost值,但也可以通过手工指定该接口的Cost值,手工指定的优先于自动计算的值。OSPF计算的Cost,同样是和接口带宽成反比,带宽越高,Cost值越小。到达目标相同Cost值的路径相同,可以执行负载均衡,最多6条链路同时执行负载均衡。 OSPF负载均衡是一种等价负载均衡。
OSPF负载均衡一般与其他负载均衡一起搭建成负载均衡集群,提供高可用、高负载服务。
OSPF负载均衡
RIP协议目前用的比较少,不详细介绍。
RIP负载均衡与OSPF负载均衡的原理类似。采用了等价负载均衡的原理。到达后端网络的路径开销一致,就达到了负载均衡的目的。
RIP等价负载均衡
1)http重定向协议实现负载均衡
根据用户的http请求计算出一个真实的web服务器地址,并将该web服务器地址写入http重定向响应中返回给浏览器,由浏览器重新进行访问。这种方式的优点是比较简单。缺点:浏览器需要零次请求服务器才能完成一次访问,性能较差。http重定向服务器自身的处理能力可能成为瓶颈。使用http302响应重定向,有可能使搜索引擎判断为SEO作弊,降低搜索排名。
2)dns域名解析负载均衡
在DNS服务器上配置多个域名对应IP的记录。例如一个域名www.baidu.com对应一组web服务器IP地址,域名解析时经过DNS服务器的算法将一个域名请求分配到合适的真实服务器上。优点:将负载均衡的工作交给了DNS,省却了网站管理维护负载均衡服务器的麻烦,同事许多DNS还支持基于地理位置的域名解析,将域名解析成距离用户地理最近的一个服务器地址,加快访问速度吗,改善性能。这种方式的缺点是:DNS负载均衡的控制权在域名服务商手里,网站可能无法做出过多的改善和管理。 不能够按服务器的处理能力来分配负载。DNS负载均衡采用的是简单的轮询算法,不能区分服务器之间的差异,不能反映服务器当前运行状态,所以其的负载均衡效果并不是太好。
3)反向代理负载均衡
反向代理处于web服务器这边,反向代理服务器提供负载均衡的功能,同时管理一组web服务器,它根据负载均衡算法将请求的浏览器访问转发到不同的web服务器处理,处理结果经过反向服务器返回给浏览器。浏览器访问请求的地址是反向代理服务器的地址114.100.80.10,反向代理服务器收到请求,经过负载均衡算法后得到一个真实物理地址10.0.03,并将请求结果发给真实无服务,真实服务器处理完后通过反向代理服务器返回给请求用户。这种方式的优点是部署简单,处于http协议层面。缺点是使用了反向代理服务器后,web 服务器地址不能直接暴露在外,因此web服务器不需要使用外部IP地址,而反向代理服务作为沟通桥梁就需要配置双网卡、外部内部两套IP地址。
四层的负载均衡就是基于虚拟P+端口的负载均衡:在三层负载均衡的基础上,通过发布三层的虚拟IP地址(VIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行NAT处理,转发至后台服务器,并记录下这个TCP或者UDP的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。
对应的负载均衡器称为四层交换机(L4 switch),主要分析IP层及TCP/UDP层,实现四层负载均衡。此种负载均衡器不理解应用协议(如HTTP/FTP/MySQL等等)。
实现四层负载均衡的软件有:
七层的负载均衡就是基于虚拟的URL或主机IP的负载均衡:在四层负载均衡的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征,比如同一个Web服务器的负载均衡,除了根据VIP加80端口辨别是否需要处理的流量,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。
举个例子,如果你的Web服务器分成两组,一组是中文语言的,一组是英文语言的,那么七层负载均衡就可以当用户来访问你的域名时,自动辨别用户语言,然后选择对应的语言服务器组进行负载均衡处理。
对应的负载均衡器称为七层交换机(L7 switch),除了支持四层负载均衡以外,还有分析应用层的信息,如HTTP协议URI或Cookie信息,实现七层负载均衡。此种负载均衡器能理解应用协议。
实现七层负载均衡的软件有:
总的来说,一般是lvs做4层负载;nginx做7层负载(也能做4层负载, 通过stream模块);haproxy比较灵活,4层和7层负载均衡都能做
所谓四层负载均衡,也就是主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。
以常见的TCP为例,负载均衡设备在接收到第一个来自客户端的SYN 请求时,即通过上述方式选择一个最佳的服务器,并对报文中目标IP地址进行修改(改为后端服务器IP),直接转发给该服务器。TCP的连接建立,即三次握手是客户端和服务器直接建立的,负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下,为保证服务器回包可以正确返回给负载均衡设备,在转发报文的同时可能还会对报文原来的源地址进行修改。
所谓七层负载均衡,也称为“内容交换”,也就是主要通过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。
以常见的TCP为例,负载均衡设备如果要根据真正的应用层内容再选择服务器,只能先代理最终的服务器和客户端建立连接(三次握手)后,才可能接受到客户端发送的真正应用层内容的报文,然后再根据该报文中的特定字段,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。负载均衡设备在这种情况下,更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看,七层负载均衡明显的对负载均衡设备的要求更高,处理七层的能力也必然会低于四层模式的部署方式。
四层负载均衡在中间传输层执行,它处理消息的传递,但不考虑消息的内容。例如TCP是网络上Hypertext Transfer Protocol(HTTP)流量的第四层协议。在这一过程中,4层负载均衡会将网络数据包转发到上游服务器,但不会检查数据包的内容,只能通过检查TCP流中的前几个包来做出有限的路由决策。
七层负载均衡不同于四层负载均衡,它在高级应用层上执行,会处理每个消息的实际内容。HTTP是网络上网站流量的主要7层协议。七层负载均衡以比四层负载均衡更复杂的方式路由网络流量,尤其适用于基于TCP的流量(如HTTP)。七层负载均衡会终止网络流量并读取器中消息,它可以根据消息内容(如URL或cookie)做出负载均衡决策。随后,七层负载均衡与选定上有服务器建立新的TCP连接并将请求写入服务器。
举个例子形象的说明:四层负载均衡就像银行的自助排号机,每一个达到银行的客户根据排号机的顺序,选择对应的窗口接受服务;而七层负载均衡像银行大堂经理,先确认客户需要办理的业务,再安排排号。这样办理理财、存取款等业务的客户,会根据银行内部资源得到统一协调处理,加快客户业务办理流程。
七层负载均衡比基于数据包的四层负载均衡更占CPU,但很少会导致服务器性能下降。七层负载均衡可以让负载均衡器做出更明智的决策,并可以对内容进行优化和更改,如压缩、加密等等。七层负载均衡还可以利用buffering来卸载上游服务器的慢速连接,从而提高性能。
执行七层负载平衡的组件通常被称为反向代理服务器。
举个简单的例子,假设用户访问高流量网站,在会话期间,它可能会请求静态内容(例如图像或视频)、动态内容(例如新闻订阅源)或者交易信息(例如订单状态)等等。7层负载平衡允许负载均衡器根据请求本身中的消息(如内容类型)来路由请求。也就是说,我们可以将对图像或视频的请求路由到存储它的服务器,并进行高度优化以提供多媒体内容;可以将诸如折扣价之类的交易信息请求路由到负责管理定价的应用服务器。借助7层负载平衡,网络和应用程序架构师可以创建高度优化的服务器基础架构或应用交付网络,在保障可靠性的同时进行有效扩展。
从上面的对比看来四层负载与七层负载最大的区别就是效率与功能的区别。四层负载架构设计比较简单,无需解析具体的消息内容,在网络吞吐量及处理能力上会相对比较高,而七层负载均衡的优势则体现在功能多,控制灵活强大。在具体业务架构设计时,使用七层负载或者四层负载还得根据具体的情况综合考虑。
通过修改tcp报文的源地址和目的地址,使从web服务器中返回的数据直接返回到客户端,这是七层负载均衡无法做到的,因为tcp三次握手建立在客户端与负载均衡服务器之间,http协议基于tcp协议,建立好tcp链接后才传送http报文,收到http报文说明负载均衡器和客户端已经建立了tcp连接,而web服务器和客户端的tcp链接都没建立,怎么回传数据给客户端呢。以上的办法会出现问题:所有集群里的主机都是内网ip,无法跟外界联系。
解决方案1:
如果能买到那么多外网Ip地址来用,然后在tcp链接要建立时负载均衡给真正的web服务器,让客户端和服务器建立tcp链接
解决方案2:
引用一句话:计算机所有的问题都可以通过建立一层虚拟层解决。
可以通过将所有服务器主机ip虚拟化成负载均衡服务器的ip,这样服务器集群的所有主机都可以访问外界网络,因为ip地址(网络层,三层)都是相同,所以只能通过第二层来分辨数据流向,修改数据链路层(二层)目的主机的MAC地址,使请求发到web服务器上,然后才真正建立起tcp连接,然后web服务器因为可以联网,所以可以直接返回数据给客户端
七层应用负载的好处,是使得整个网络更"智能化"。例如访问一个网站的用户流量,可以通过七层的方式,将对图片类的请求转发到特定的图片服务器并可以使用缓存技术;将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。当然这只是七层应用的一个小案例,从技术原理上,这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改,极大的提升了应用系统在网络层的灵活性。很多在后台,例如Nginx或者Apache上部署的功能可以前移到负载均衡设备上,例如客户请求中的Header重写,服务器响应中的关键字过滤或者内容插入等功能。
另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击,即黑客控制众多源客户端,使用虚假IP地址对同一目标发送SYN攻击,通常这种攻击会大量发送SYN报文,耗尽服务器上的相关资源,以达到Denial of Service(DoS)的目的。从技术原理上也可以看出,四层模式下这些SYN攻击都会被转发到后端的服务器上;而七层模式下这些SYN攻击自然在负载均衡设备上就截止,不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略,过滤特定报文,例如SQL Injection等应用层面的特定攻击手段,从应用层面进一步提高系统整体安全。
现在的七层负载均衡,主要还是着重于应用HTTP协议,所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其他TCP应用,例如基于C/S开发的ERP等系统。
3.1) 是否真的必要。七层应用的确可以提高流量智能化,同时必不可免的带来设备配置复杂,负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时需要考虑四层七层同时应用的混杂情况。
3.2) 是否真的可以提高安全性。例如SYN Flood攻击,七层模式的确将这些流量从服务器屏蔽,但负载均衡设备本身要有强大的抗DDoS能力,否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。
3.3) 是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化,但是负载均衡设备需要提供完善的七层功能,满足客户根据不同情况的基于应用的调度。最简单的一个考核就是能否取代后台Nginx或者Apache等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备,可以让客户根据需求任意设定功能,才真正有可能提供强大的灵活性和智能性。
4.1) 智能性
七层负载均衡由于具备OIS七层的所有功能,所以在处理用户需求上能更加灵活,从理论上讲,七层模型能对用户的所有跟服务端的请求进行修改。例如对文件header添加信息,根据不同的文件类型进行分类转发。四层模型仅支持基于网络层的需求转发,不能修改用户请求的内容。
4.2) 安全性
七层负载均衡由于具有OSI模型的全部功能,能更容易抵御来自网络的攻击;四层模型从原理上讲,会直接将用户的请求转发给后端节点,无法直接抵御网络攻击。
4.3) 复杂度
四层模型一般比较简单的架构,容易管理,容易定位问题;七层模型架构比较复杂,通常也需要考虑结合四层模型的混用情况,出现问题定位比较复杂。
4.4) 效率比
四层模型基于更底层的设置,通常效率更高,但应用范围有限;七层模型需要更多的资源损耗,在理论上讲比四层模型有更强的功能,现在的实现更多是基于http应用。
软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡,如DNS Load Balance,CheckPoint Firewall-1 ConnectControl,Keepalive+ipvs等,它的优点是基于特定环境,配置简单,使用灵活,成本低廉,可以满足一般的负载均衡需求。软件解决方案缺点也较多,因为每台服务器上安装额外的软件运行会消耗系统不定量的资源,越是功能强大的模块,消耗得越多,所以当连接请求特别大的时候,软件本身会成为服务器工作成败的一个关键;软件可扩展性并不是很好,受到操作系统的限制;由于操作系统本身的Bug,往往会引起安全问题。
硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备,这种设备通常是一个独立于系统的硬件,我们称之为负载均衡器。由于专门的设备完成专门的任务,独立于操作系统,整体性能得到大量提高,加上多样化的负载均衡策略,智能化的流量管理,可达到最佳的负载均衡需求。负载均衡器有多种多样的形式,除了作为独立意义上的负载均衡器外,有些负载均衡器集成在交换设备中,置于服务器与Internet链接之间,有些则以两块网络适配器将这一功能集成到PC中,一块连接到Internet上,一块连接到后端服务器群的内部网络上。
软件负载均衡与硬件负载均衡的对比:
软件负载均衡的优点是需求环境明确,配置简单,操作灵活,成本低廉,效率不高,能满足普通的企业需求;缺点是依赖于系统,增加资源开销;软件的优劣决定环境的性能;系统的安全,软件的稳定性均会影响到整个环境的安全。
硬件负载均衡优点是独立于系统,整体性能大量提升,在功能、性能上优于软件方式;智能的流量管理,多种策略可选,能达到最佳的负载均衡效果;缺点是价格昂贵。
2)本地/全局负载均衡
负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance,也叫地域负载均衡),本地负载均衡是指对本地的服务器群做负载均衡,全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。
本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题,并且不需花费昂贵开支购置性能卓越的服务器,充分利用现有设备,避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充升级,也只是简单地增加一个新的服务器到服务群中,而不需改变现有网络结构、停止现有的服务。
全局负载均衡主要用于在一个多区域拥有自己服务器的站点,为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器,从而获得最快的访问速度,也可用于子公司分散站点分布广的大公司通过Intranet(企业内部互联网)来达到资源统一合理分配的目的。
3)网络层次上的负载均衡
针对网络上负载过重的不同瓶颈所在,从网络的不同层次入手,我们可以采用相应的负载均衡技术来解决现有问题。
随着带宽增加,数据流量不断增大,网络核心部分的数据接口将面临瓶颈问题,原有的单一线路将很难满足需求,而且线路的升级又过于昂贵甚至难以实现,这时就可以考虑采用链路聚合(Trunking)技术。
链路聚合技术(第二层负载均衡)将多条物理链路当作一条单一的聚合逻辑链路使用,网络数据流量由聚合逻辑链路中所有物理链路共同承担,由此在逻辑上增大了链路的容量,使其能满足带宽增加的需求。
现代负载均衡技术通常操作于网络的第四层或第七层。第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址,对每次 TCP连接请求动态使用其中一个内部IP地址,达到负载均衡的目的。在第四层交换机中,此种均衡技术得到广泛的应用,一个目标地址是服务器群VIP(虚拟 IP,Virtual IP address)连接请求的数据包流经交换机,交换机根据源端和目的IP地址、TCP或UDP端口号和一定的负载均衡策略,在服务器IP和VIP间进行映射,选取服务器群中最好的服务器来处理连接请求。
七层负载均衡控制应用层服务的内容,提供了一种对访问流量的高层控制方式,适合对HTTP服务器群的应用。第七层负载均衡技术通过检查流经的HTTP报头,根据报头内的信息来执行负载均衡任务。
七层负载均衡优点表现在如下几个方面:
七层负载均衡缺点表现在如下几个方面:
在实际应用中,我们可能不想仅仅是把客户端的服务请求平均地分配给内部服务器,而不管服务器是否宕机。而是想使Pentium III服务器比Pentium II能接受更多的服务请求,一台处理服务请求较少的服务器能分配到更多的服务请求,出现故障的服务器将不再接受服务请求直至故障恢复等等。选择合适的负载均衡策略,使多个设备能很好的共同完成任务,消除或避免现有网络负载分布不均、数据流量拥挤反应时间长的瓶颈。在各负载均衡方式中,针对不同的应用需求,在OSI参考模型的第二、三、
负载均衡策略的优劣及其实现的难易程度有两个关键因素:负载均衡算法;对网络系统状况的检测方式和能力。
负载均衡算法
PS:Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件,本人都在多个项目中实施过,参考了一些资料,结合自己的一些使用经验,总结一下。
一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析,如果是中小型的Web应用,比如日PV小于1000万,用Nginx就完全可以了;如果机器不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或重要的服务,且服务器比较多时,可以考虑用LVS。
一种是通过硬件来进行进行,常见的硬件有比较昂贵的F5和Array等商用的负载均衡器,它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用;另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件,这些都是通过软件级别来实现,所以费用非常低廉。
目前关于网站架构一般比较合理流行的架构方案:Web前端采用Nginx/HAProxy+Keepalived作负载均衡器;后端采用MySQL数据库一主多从和读写分离,采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。
下面说说各自的特点和适用场合。
LVS:使用Linux内核集群实现一个高性能、高可用的负载均衡服务器,它具有很好的可伸缩性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。
① roundrobin,表示简单的轮询,这个不多说,这个是负载均衡基本都具备的;
② static-rr,表示根据权重,建议关注;
③ leastconn,表示最少连接者先处理,建议关注;
④ source,表示根据请求源IP,这个跟Nginx的IP_hash机制类似,我们用其作为解决session问题的一种方法,建议关注;
⑤ ri,表示根据请求的URI;
⑥ rl_param,表示根据请求的URl参数’balance url_param’ requires an URL parameter name;
⑦ hdr(name),表示根据HTTP请求头来锁定每一次HTTP请求;
⑧ rdp-cookie(name),表示根据据cookie(name)来锁定并哈希每一次TCP请求。
现在对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术:
最终形成比较理想的基本架构为:Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer。
对软件实现负载均衡的几个软件,详细看了一下,从性能和稳定上还是LVS最牛,基本达到了F5硬件设备的60%性能,其他几个10%都有点困难。
不过就因为LVS忒牛了,配置也最麻烦了,而且健康检测需要另外配置Ldirector,其他HAPROXY和NGINX自己就用,而且配置超级简单。
所以建议,如果网站访问量不是门户级别的用HAPROXY或者NGINX就OK了,到了门户级别在用LVS+Idirector吧.
lvs和nginx都可以用作多机负载的方案,它们各有优缺,在生产环境中需要好好分析实际情况并加以利用。