• 关于

    保留字符未响应

    的搜索结果

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:10 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

2019-12-01 23:31:11 0 浏览量 回答数 0

问题

IIS7.5安装配置UrlScan3.1应用防火墙

虎笑 2019-12-01 21:00:19 11275 浏览量 回答数 2

问题

方法追踪有哪几种?

猫饭先生 2019-12-01 21:03:55 875 浏览量 回答数 0

回答

调用API可能出现的错误有四类:连接淘宝服务器错误、平台级错误、业务级错误和容器类错误。这四种类型的错误分别代表了开发者访问淘宝服务器、淘宝接入平台、后端业务和容器这几个层次上出现的问题。 2,连接淘宝服务器错误主要是http连接错误或者连接被重置被拒绝等,这类错误是开发者访问淘宝服务器出现的问题,请直接联系服务器管理员或通过网络搜索答案。 平台级错误 1,平台级错误是指错误码小于100的调用错误,这种错误一般是由于用户的请求不符合各种基本校验而引起的。 2,用户遇到这些错误的返回首先检查应用的权限、频率等情况,然后参照文档检验一下传入的参数是否完整且合法。 错误码 错误描述-英文 错误描述-中文 解决方案 3 Upload Fail 图片上传失败 将传入的图片格式改为正确的格式、适当的大小的图片放进消息体里面传输过来,如果传输仍然失败需要减小图片大小或者增加网络带宽进行尝试 7 App Call Limited 应用调用次数超限,包含调用频率超限 调整程序合理调用API,等限频时间过了再调用,淘客的调用频率是系统按照上个月交易额自动修改的,修改后的频率会在官方论坛首页以公告形式通知,开发者可自行查看 9 Http Action Not Allowed HTTP方法被禁止 请用大写的POST或GET,如果有图片等信息传入则一定要用POST才可以 10 Service Currently Unavailable 服务不可用 多数是由未知异常引起的,仔细检查传入的参数是否符合文档描述 11 Insufficient ISV Permissions 开发者权限不足 应用没有权限调用中级或高级权限的接口,可在淘宝合作伙伴后台提交权限申请 12 Insufficient User Permissions 用户权限不足 应用没有权限调用中级或高级权限的接口,可在淘宝合作伙伴后台提交权限申请 13 Insufficient Partner Permissions 合作伙伴权限不足 应用没有权限调用中级或高级权限的接口,可在淘宝合作伙伴后台提交权限申请 15 Remote Service Error 远程服务出错 API调用后端服务出错,首先查看自己的参数是否合法,如果参数没有问题请过一段时间再尝试 21 Missing Method 缺少方法名参数 传入的参数加入method字段 22 Invalid Method 不存在的方法名 传入的method字段必需是你所调用的API的名称,并且该API是确实存在的 23 Invalid Format 无效数据格式 传入的format必需为json或xml中的一种 24 Missing Signature 缺少签名参数 传入的参数中必需包含sign字段 25 Invalid Signature 无效签名 签名必需根据正确的算法算出来的。算法请见: http://open.taobao.com/dev/index.php/API签名算法 26 Missing Session 缺少SessionKey参数 传入的参数中必需包含session字段 27 Invalid Session 无效的SessionKey参数 传入的session必需是用户绑定session拿到的,如果报session不合法可能是用户没有绑定session或session过期造成的,用户需要重新绑定一下然后传入新的sessionKey 28 Missing App Key 缺少AppKey参数 传入的参数必需包含app_key字段 29 Invalid App Key 无效的AppKey参数 应用所处的环境跟选择的环境不一致,例如:应用处于沙箱测试环境,却选择在正式环境进行测试,可在合作伙伴后台或商家接入平台对该应用进行修改 30 Missing Timestamp 缺少时间戳参数 传入的参数中必需包含timestamp参数 31 Invalid Timestamp 非法的时间戳参数 时间戳,格式为yyyy-mm-dd hh:mm:ss,例如:2008-01-25 20:23:30。淘宝API服务端允许客户端请求时间误差为10分钟 32 Missing Version 缺少版本参数 传入的参数中必需包含v字段 33 Invalid Version 非法的版本参数 用户传入的版本号格式错误,必需为数字格式 34 Unsupported Version 不支持的版本号 用户传入的版本号没有被提供 40 Missing Required Arguments 缺少必选参数 API文档中设置为必选的参数是必传的,请仔细核对文档 41 Invalid Arguments 非法的参数 参数类型不对,例如:需要传入的是数字类型的,却传入了字符类型的参数 42 Forbidden Request 请求被禁止 目前没有控制 43 Parameter Error 参数错误 一般是用户传入参数非法引起的,请仔细检查入参格式、范围是否一一对应 47 Invalid encoding 编码错误 一般是用户做http请求的时候没有用UTF-8编码请求造成的 业务级错误 1,业务级错误是指用户通过平台初步的参数校验,进入后端业务流程所出现的,错误码大于100的错误。 2,以isv开头的一般都是isv的错误,这一类错误一般是由于用户提供的参数不合法或者不匹配造成的,因此isv应该根据错误信息检验是否传入了相应的信息,对于这一类错误建议改正后再重试。 3,以isp开头的错误一般是isp服务不可用或top平台连接后端服务时的错误,这些错误可能与后台服务端的服务可用性有关,建议用户在一段时间后重试。 4,错误响应是用户和服务器交互失败的最直接展示,isv在调用top服务时,如果调用失败,请尽量保留下错误日志以便进行后面的错误追查。 业务级父错误 产品线 错误码 用户 500 类目 510 交易 520 退款 521 商品 530 商品扩展 531 邮费模板 532 产品 540 物流 550 店铺 560 评价 570 淘宝客 580 系统 590 备案 591 增量 600 画报 620 江湖 630 分销 640 淘秀 650 收费 660 业务级子错误 子错误码格式 错误信息 归属方 是否可在程序中重试 isv.###-not-exist:*** 根据***查询不到### ISV 否 isv.missing-parameter:*** 缺少必要的参数*** ISV 否 isv.invalid-paramete:*** 参数***无效,格式不对、非法值、越界等 ISV 否 isv.invalid-permission 权限不够、非法访问 ISV 否 isv.parameters-mismatch:***-and-### 传入的参数***和###不匹配,两者有一定的对应关系 ISV 否 isv.***-service-error:### 调用***服务返回false,业务逻辑错误,###表示具体的错误信息 ISV 否 isp.***-service-unavailable 调用后端服务***抛异常,服务不可用 ISP 是 isp.remote-service-error 连接远程服务错误 ISP 是 isp.remote-service-timeout 连接远程服务超时 ISP 是 isp.remote-connection-error 远程连接错误 ISP 是 isp.null-pointer-exception 空指针异常错误 ISP 否 isp.top-parse-error api解析错误(出现了未被明确控制的异常信息) ISP 否 isp.top-remote-connection-timeout top平台连接后端服务超时 ISP 是 isp.top-remote-connection-error top平台连接后端服务错误,找不到服务 ISP 是 isp.top-mapping-parse-error top-mapping转换出错,主要是由于传入参数格式不对 ISP 否 isp.unknown-error top平台连接后端服务抛未知异常信息 ISP 是 容器类错误 容器类错误是指用户通过容器登录之后页面上出现的错误 错误码 错误描述(中文) 100 授权码已经过期 101 授权码在缓存里不存在,一般是用同样的authcode两次获取sessionkey 102 系统错误,建议清理浏览器缓存,稍后重试 103 appkey或者tid(插件ID)参数必须至少传入一个 104 appkey或者tid对应的插件不存在 105 插件的状态不对,不是上线状态或者正式环境下测试状态 106 没权限调用此app,由于插件不是所有用户都默认安装,所以需要用户和插件进行一个订购关系,这个错误一般是由于用户访问了自己没有订购的在线订购应用所造成的 107 系统错误,建议清理浏览器缓存,稍后重试 108 应用是自用型应用,只有自用型绑定用户才可以访问。 109,111 服务端在生成参数的时候出了问题,建议清理浏览器缓存,稍后重试 110 服务端在写出参数的时候出了问题 ,建议清理浏览器缓存,稍后重试 112 回调地址不正确,请检查回调地址,是否为空,或者含有top认为非法的字符。 113 用户没有同意授权

问问小秘 2019-12-02 02:12:57 0 浏览量 回答数 0

问题

高级接口的使用

云栖大讲堂 2019-12-01 21:08:59 1628 浏览量 回答数 1

问题

如何推送高级接口?

猫饭先生 2019-12-01 21:56:00 1106 浏览量 回答数 0

回答

一 系统介绍 Android 是Google开发的基于Linux平台的、开源的、智能手机操作系统。Android包括操作系统、中间件和应用程序,由于源代码开放,Android可以被移植到不同的硬件平台上。 围绕在Google的Android系统中,形成了移植开发和上层应用程序开发两个不同的开发方面。手机厂商从事移植开发工作,上层的应用程序开发可以由任何单位和个人完成,开发的过程可以基于真实的硬件系统,还可以基于仿真器环境。 作为一个手机平台,Android在技术上的优势主要有以下几点: - 全开放智能手机平台 - 多硬件平台的支持 - 使用众多的标准化技术 - 核心技术完整,统一 - 完善的SDK和文档 - 完善的辅助开发工具 Android的开发者可以在完备的开发环境中进行开发,Android的官方网站也提供了丰富的文档、资料。这样有利于Android系统的开发和运行在一个良好的生态环境中。 https://developer.android.com/about安卓开发者官方网站 从宏观的角度来看,Android是一个开放的软件系统,它包含了众多的源代码。从下至上,Android系统分成4个层次: 第1层次:Linux操作系统及驱动; 第2层次:本地代码(C/C++)框架; 第3层次:Java框架; 第4层次:Java应用程序。 Android系统的架构如图所示: 由于Android系统需要支持Java代码的运行,这部分内容是Android的运行环境(Runtime),由虚拟机和Java基本类组成。 对于Android应用程序的开发,主要关注第3层次和第4层次之间的接口。 二 学习路线 基础学习——JavaSE: 基础学习扩展——JavaEE: 基础学习扩展——Linux基础: Android开发学习——基础理论:系统架构分析: Android系统从底向上一共分了4层,每一层都把底层实现封装,并暴露调用接口给上一层。 Linux内核(Linux Kernel) Android运行在linux kernel 2.6之上,但是把linux内受GNU协议约束的部分做了取代,这样在Android的程序可以用于商业目的。 Linux 内核是硬件和软件层之间的抽象层。 中间件 中间件包括两部分: 核心库和运行时(libraries & Android runtime) 核心库包括,SurfaceManager 显示系统管理库,负责把2D或3D内容显示到屏幕;Media Framework 媒体库,负责支持图像,支持多种视频和音频的录制和回放;SQlite 数据库,一个功能强大的轻量级嵌入式关系数据库;WebKit 浏览器引擎等。 Dalvik虚拟机: 区别于Java虚拟机的是,每一个Android 应用程序都在它自己的进程中运行,都有一个属于自己的Dalvik 虚拟机,这一点可以让系统在运行时可以达到优化,程序间的影响大大降低。Dalvik虚拟机并非运行Java字节码,而是运行自己的字节码。 应用程序框架(Application Framework) 丰富而又可扩展性的视图(Views),可以用来构建应用程序, 它包括列表(lists),网格(grids), 文本框(text boxes),按钮( buttons), 可嵌入的web 浏览器。内容提供者(Content Providers)使得应用程序可以访问另一个应用程序的数据(如联系人数据库), 或者共享它们自己的数据。资源管理器(Resource Manager)提供非代码资源的访问,如本地字符串,图形,和布局文件( layoutfiles )。通知管理器(Notification Manager) 使得应用程序可以在状态栏中显示自定义的提示信息。活动管理器( Activity Manager) 用来管理应用程序生命周期并提供常用的导航回退功能。 三 基础知识 掌握java部分之后,可以使用开发工具进入android世界 您可以使用 Kotlin、Java 和 C++ 语言编写 Android 应用。Android SDK 工具会将您的代码连同任何数据和资源文件编译成一个 APK(Android 软件包),即带有 .apk 后缀的归档文件。一个 APK 文件包含 Android 应用的所有内容,它也是 Android 设备用来安装应用的文件。 每个 Android 应用都处于各自的安全沙盒中,并受以下 Android 安全功能的保护: • Android 操作系统是一种多用户 Linux 系统,其中的每个应用都是一个不同的用户; • 默认情况下,系统会为每个应用分配一个唯一的 Linux 用户 ID(该 ID 仅由系统使用,应用并不知晓)。系统会为应用中的所有文件设置权限,使得只有分配给该应用的用户 ID 才能访问这些文件; • 每个进程都拥有自己的虚拟机 (VM),因此应用代码独立于其他应用而运行。 • 默认情况下,每个应用都在其自己的 Linux 进程内运行。Android 系统会在需要执行任何应用组件时启动该进程,然后当不再需要该进程或系统必须为其他应用恢复内存时,其便会关闭该进程。 Android 系统实现了最小权限原则。换言之,默认情况下,每个应用只能访问执行其工作所需的组件,而不能访问其他组件。这样便能创建非常安全的环境,在此环境中,应用无法访问其未获得权限的系统部分。不过,应用仍可通过一些途径与其他应用共享数据以及访问系统服务: • 可以安排两个应用共享同一 Linux 用户 ID,在此情况下,二者便能访问彼此的文件。为节省系统资源,也可安排拥有相同用户 ID 的应用在同一 Linux 进程中运行,并共享同一 VM。应用还必须使用相同的证书进行签名。 • 应用可以请求访问设备数据(如用户的联系人、短信消息、可装载存储装置(SD 卡)、相机、蓝牙等)的权限。用户必须明确授予这些权限。如需了解详细信息,请参阅使用系统权限。 本文档的其余部分将介绍以下概念: • 用于定义应用的核心框架组件 • 用来声明组件和应用必需设备功能的清单文件。 • 与应用代码分离并允许应用针对各种设备配置适当优化其行为的资源。 应用组件 应用组件是 Android 应用的基本构建块。每个组件都是一个入口点,系统或用户可通过该入口点进入您的应用。有些组件会依赖于其他组件。 共有四种不同的应用组件类型: • Activity • 服务 • 广播接收器 • 内容提供程序 每种类型都有不同的用途和生命周期,后者会定义如何创建和销毁组件。以下部分将介绍应用组件的四种类型。 Activity Activity 是与用户交互的入口点。它表示拥有界面的单个屏幕。例如,电子邮件应用可能有一个显示新电子邮件列表的 Activity、一个用于撰写电子邮件的 Activity 以及一个用于阅读电子邮件的 Activity。尽管这些 Activity 通过协作在电子邮件应用中形成一种紧密结合的用户体验,但每个 Activity 都独立于其他 Activity 而存在。因此,其他应用可以启动其中任何一个 Activity(如果电子邮件应用允许)。例如,相机应用可以启动电子邮件应用内用于撰写新电子邮件的 Activity,以便用户共享图片。Activity 有助于完成系统和应用程序之间的以下重要交互: • 追踪用户当前关心的内容(屏幕上显示的内容),以确保系统继续运行托管 Activity 的进程。 • 了解先前使用的进程包含用户可能返回的内容(已停止的 Activity),从而更优先保留这些进程。 • 帮助应用处理终止其进程的情况,以便用户可以返回已恢复其先前状态的 Activity。 • 提供一种途径,让应用实现彼此之间的用户流,并让系统协调这些用户流。(此处最经典的示例是共享。) 您需将 Activity 作为 Activity 类的子类来实现。如需了解有关 Activity 类的更多信息,请参阅 Activity 开发者指南。 服务 服务是一个通用入口点,用于因各种原因使应用在后台保持运行状态。它是一种在后台运行的组件,用于执行长时间运行的操作或为远程进程执行作业。服务不提供界面。例如,当用户使用其他应用时,服务可能会在后台播放音乐或通过网络获取数据,但这不会阻断用户与 Activity 的交互。诸如 Activity 等其他组件可以启动服务,使该服务运行或绑定到该服务,以便与其进行交互。事实上,有两种截然不同的语义服务可以告知系统如何管理应用:已启动服务会告知系统使其运行至工作完毕。此类工作可以是在后台同步一些数据,或者在用户离开应用后继续播放音乐。在后台同步数据或播放音乐也代表了两种不同类型的已启动服务,而这些服务可以修改系统处理它们的方式: • 音乐播放是用户可直接感知的服务,因此,应用会向用户发送通知,表明其希望成为前台,从而告诉系统此消息;在此情况下,系统明白它应尽全力维持该服务进程运行,因为进程消失会令用户感到不快。 • 通常,用户不会意识到常规后台服务正处于运行状态,因此系统可以更自由地管理其进程。如果系统需要使用 RAM 来处理用户更迫切关注的内容,则其可能允许终止服务(然后在稍后的某个时刻重启服务)。 绑定服务之所以能运行,原因是某些其他应用(或系统)已表示希望使用该服务。从根本上讲,这是为另一个进程提供 API 的服务。因此,系统会知晓这些进程之间存在依赖关系,所以如果进程 A 绑定到进程 B 中的服务,系统便知道自己需使进程 B(及其服务)为进程 A 保持运行状态。此外,如果进程 A 是用户关心的内容,系统随即也知道将进程 B 视为用户关心的内容。由于存在灵活性(无论好坏),服务已成为非常有用的构建块,并且可实现各种高级系统概念。动态壁纸、通知侦听器、屏幕保护程序、输入方法、无障碍功能服务以及众多其他核心系统功能均可构建为在其运行时由应用实现、系统绑定的服务。 您需将服务作为 Service 的子类来实现。如需了解有关 Service 类的更多信息,请参阅服务开发者指南。 注意:如果您的应用面向 Android 5.0(API 级别 21)或更高版本,请使用 JobScheduler 类来调度操作。JobScheduler 的优势在于,它能通过优化作业调度来降低功耗,以及使用 Doze API,从而达到省电目的。如需了解有关使用此类的更多信息,请参阅 JobScheduler 参考文档。 广播接收器 借助广播接收器组件,系统能够在常规用户流之外向应用传递事件,从而允许应用响应系统范围内的广播通知。由于广播接收器是另一个明确定义的应用入口,因此系统甚至可以向当前未运行的应用传递广播。例如,应用可通过调度提醒来发布通知,以告知用户即将发生的事件。而且,通过将该提醒传递给应用的广播接收器,应用在提醒响起之前即无需继续运行。 许多广播均由系统发起,例如,通知屏幕已关闭、电池电量不足或已拍摄照片的广播。应用也可发起广播,例如,通知其他应用某些数据已下载至设备,并且可供其使用。尽管广播接收器不会显示界面,但其可以创建状态栏通知,在发生广播事件时提醒用户。但广播接收器更常见的用途只是作为通向其他组件的通道,旨在执行极少量的工作。例如,它可能会根据带 JobScheduler 的事件调度 JobService 来执行某项工作 广播接收器作为 BroadcastReceiver 的子类实现,并且每条广播都作为 Intent 对象进行传递。如需了解详细信息,请参阅 BroadcastReceiver 类。 内容提供程序 内容提供程序管理一组共享的应用数据,您可以将这些数据存储在文件系统、SQLite 数据库、网络中或者您的应用可访问的任何其他持久化存储位置。其他应用可通过内容提供程序查询或修改数据(如果内容提供程序允许)。例如,Android 系统可提供管理用户联系人信息的内容提供程序。 因此,任何拥有适当权限的应用均可查询内容提供程序(如 ContactsContract.Data),以读取和写入特定人员的相关信息。我们很容易将内容提供程序看作数据库上的抽象,因为其内置的大量 API 和支持时常适用于这一情况。但从系统设计的角度看,二者的核心目的不同。对系统而言,内容提供程序是应用的入口点,用于发布由 URI 架构识别的已命名数据项。因此,应用可以决定如何将其包含的数据映射到 URI 命名空间,进而将这些 URI 分发给其他实体。反之,这些实体也可使用分发的 URI 来访问数据。在管理应用的过程中,系统可以执行以下特殊操作: • 分配 URI 无需应用保持运行状态,因此 URI 可在其所属的应用退出后继续保留。当系统必须从相应的 URI 检索应用数据时,系统只需确保所属应用仍处于运行状态。 • 这些 URI 还会提供重要的细粒度安全模型。例如,应用可将其所拥有图像的 URI 放到剪贴板上,但将其内容提供程序锁定,以便其他应用程序无法随意访问它。当第二个应用尝试访问剪贴板上的 URI 时,系统可允许该应用通过临时的 URI 授权来访问数据,这样便只能访问 URI 后面的数据,而非第二个应用中的其他任何内容。 内容提供程序也适用于读取和写入您的应用不共享的私有数据。 内容提供程序作为 ContentProvider 的子类实现,并且其必须实现一组标准 API,以便其他应用能够执行事务。如需了解详细信息,请参阅内容提供程序开发者指南。 Android 系统设计的独特之处在于,任何应用都可启动其他应用的组件。例如,当您想让用户使用设备相机拍摄照片时,另一个应用可能也可执行该操作,因而您的应用便可使用该应用,而非自行产生一个 Activity 来拍摄照片。您无需加入甚至链接到该相机应用的代码。只需启动拍摄照片的相机应用中的 Activity 即可。完成拍摄时,系统甚至会将照片返回您的应用,以便您使用。对用户而言,这就如同相机是您应用的一部分。 当系统启动某个组件时,它会启动该应用的进程(如果尚未运行),并实例化该组件所需的类。例如,如果您的应用启动相机应用中拍摄照片的 Activity,则该 Activity 会在属于相机应用的进程(而非您的应用进程)中运行。因此,与大多数其他系统上的应用不同,Android 应用并没有单个入口点(即没有 main() 函数)。 由于系统在单独的进程中运行每个应用,且其文件权限会限制对其他应用的访问,因此您的应用无法直接启动其他应用中的组件,但 Android 系统可以。如要启动其他应用中的组件,请向系统传递一条消息,说明启动特定组件的 Intent。系统随后便会为您启动该组件。 启动组件 在四种组件类型中,有三种(Activity、服务和广播接收器)均通过异步消息 Intent 进行启动。Intent 会在运行时对各个组件进行互相绑定。您可以将 Intent 视为从其他组件(无论该组件是属于您的应用还是其他应用)请求操作的信使。 您需使用 Intent 对象创建 Intent,该对象通过定义消息来启动特定组件(显式 Intent)或特定的组件类型(隐式 Intent)。 对于 Activity 和服务,Intent 会定义要执行的操作(例如,查看或发送某内容),并且可指定待操作数据的 URI,以及正在启动的组件可能需要了解的信息。例如,Intent 可能会传达对 Activity 的请求,以便显示图像或打开网页。在某些情况下,您可以通过启动 Activity 来接收结果,这样 Activity 还会返回 Intent 中的结果。例如,您可以发出一个 Intent,让用户选取某位联系人并将其返回给您。返回 Intent 包含指向所选联系人的 URI。 对于广播接收器,Intent 只会定义待广播的通知。例如,指示设备电池电量不足的广播只包含指示“电池电量不足”的已知操作字符串。 与 Activity、服务和广播接收器不同,内容提供程序并非由 Intent 启动。相反,它们会在成为 ContentResolver 的请求目标时启动。内容解析程序会通过内容提供程序处理所有直接事务,因此通过提供程序执行事务的组件便无需执行事务,而是改为在 ContentResolver 对象上调用方法。这会在内容提供程序与请求信息的组件之间留出一个抽象层(以确保安全)。 每种组件都有不同的启动方法: • 如要启动 Activity,您可以向 startActivity() 或 startActivityForResult() 传递 Intent(当您想让 Activity 返回结果时),或者为其安排新任务。 • 在 Android 5.0(API 级别 21)及更高版本中,您可以使用 JobScheduler 类来调度操作。对于早期 Android 版本,您可以通过向 startService() 传递 Intent 来启动服务(或对执行中的服务下达新指令)。您也可通过向将 bindService() 传递 Intent 来绑定到该服务。 • 您可以通过向 sendBroadcast()、sendOrderedBroadcast() 或 sendStickyBroadcast() 等方法传递 Intent 来发起广播。 • 您可以通过在 ContentResolver 上调用 query(),对内容提供程序执行查询。 如需了解有关 Intent 用法的详细信息,请参阅 Intent 和 Intent 过滤器文档。以下文档将为您详细介绍如何启动特定组件:Activity、服务、BroadcastReceiver 和内容提供程序。

问问小秘 2020-03-03 09:47:38 0 浏览量 回答数 0

回答

您可以使用阿里云负载均衡来访问服务。 背景信息 如果您的集群的cloud-controller-manager版本大于等于v1.9.3,对于指定已有SLB,系统默认不再为该SLB处理监听,用户可以通过设置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"参数来显示启用监听配置,或者手动配置该SLB的监听规则。 执行以下命令,可查看cloud-controller-manager的版本。 root@master # kubectl get pod -n kube-system -o yaml|grep image:|grep cloud-con|uniq image: registry-vpc.cn-hangzhou.aliyuncs.com/acs/cloud-controller-manager-amd64:v1.9.3 注意事项 Cloud Controller Manager(简称CCM)会为Type=LoadBalancer类型的Service创建或配置阿里云负载均衡(SLB),包含SLB、监听、虚拟服务器组等资源。 对于非LoadBalancer类型的Service则不会为其配置负载均衡,这包含如下场景:当用户将Type=LoadBalancer的Service变更为Type!=LoadBalancer时,CCM也会删除其原先为该Service创建的SLB(用户通过service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id指定的已有SLB除外)。 自动刷新配置 CCM使用声明式API,会在一定条件下自动根据Service的配置刷新阿里云负载均衡配置,所有用户自行在SLB控制台上修改的配置均存在被覆盖的风险(使用已有SLB同时不覆盖监听的场景除外),因此不能在SLB控制台手动修改Kubernetes创建并维护的SLB的任何配置,否则有配置丢失的风险。 同时支持为serivce指定一个已有的负载均衡,或者让CCM自行创建新的负载均衡。但两种方式在SLB的管理方面存在一些差异: 指定已有SLB 仅支持复用负载均衡控制台创建的SLB,不支持复用CCM创建的SLB。 如果您需要在Kubernetes集群中复用私网类型的SLB,则该SLB需要和Kubernetes集群在同一VPC下。 需要为Service设置annotation:service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id 。 SLB配置 此时CCM会使用该SLB做为Service的SLB,并根据其他annotation配置SLB,并且自动的为SLB创建多个虚拟服务器组(当集群节点变化的时候,也会同步更新虚拟服务器组里面的节点)。 监听配置 是否配置监听取决于service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: 是否设置为true。如果设置为false,CCM不会为SLB管理任何监听配置;如果设置为true,CCM会根据service配置管理监听,如果监听已经存在,则CCM会覆盖已有监听。 SLB的删除 当Service删除时CCM不会删除用户通过id指定的已有SLB。 CCM管理的SLB CCM会根据Service的配置自动的创建配置SLB、监听、虚拟服务器组等资源,所有资源归CCM管理,因此用户不得手动在SLB控制台更改以上资源的配置,否则CCM在下次Reconcile的时候将配置刷回Service所声明的配置,造成非用户预期的结果。 SLB的删除 当Service删除时CCM会删除该SLB。 后端服务器更新 CCM会自动的为该Service对应的SLB刷新后端虚拟服务器组。当Service对应的后端Endpoint发生变化的时候或者集群节点变化的时候都会自动的更新SLB的后端Server。 spec.externalTrafficPolicy = Cluster模式的Service,CCM默认会将所有节点挂载到SLB的后端(使用BackendLabel标签配置后端的除外)。由于SLB限制了每个ECS上能够attach的SLB的个数(quota),因此这种方式会快速的消耗该quota,当quota耗尽后,会造成Service Reconcile失败。解决的办法,可以使用Local模式的Service。 spec.externalTrafficPolicy = Local模式的Service,CCM默认只会将Service对应的Pod所在的节点加入到SLB后端。这会明显降低quota的消耗速度。同时支持四层源IP保留。 任何情况下CCM不会将Master节点作为SLB的后端。 CCM默认不会从SLB后端移除被kubectl drain/cordon的节点。如需移除节点,请设置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend为on。 说明 如果是v1.9.3.164-g2105d2e-aliyun之前的版本,CCM默认会从SLB后端移除被kubectl drain/cordon的节点。 VPC路由 集群中一个节点对应一条路由表项,VPC默认情况下仅支持48条路由表项,如果集群节点数目多于48个,请提工单给VPC产品。 说明 您可以在提交工单时,说明需要修改vpc_quota_route_entrys_num参数,用于提升单个路由表可创建的自定义路由条目的数量。 更多VPC使用限制请参见使用限制。 专有网络VPC配额查询请参见专有网络VPC配额管理。 SLB使用限制 CCM会为Type=LoadBalancer类型的Service创建SLB。默认情况下一个用户可以保留60个SLB实例,如果需要创建的SLB数量大于60,请提交工单给SLB产品。 说明 您可以在提交工单时,说明需要修改slb_quota_instances_num参数,用于提高用户可保有的slb实例个数。 CCM会根据Service将ECS挂载到SLB后端服务器组中。 默认情况下一个ECS实例可挂载的后端服务器组的数量为50个,如果一台ECS需要挂载到更多的后端服务器组中,请提交工单给SLB产品。 说明 您可以在提交工单时,说明需要修改slb_quota_backendservers_num参数,用于提高同一台服务器可以重复添加为SLB后端服务器的次数。 默认情况下一个SLB实例可以挂载200个后端服务器,如果需要挂载更多的后端服务器,请提交工单给SLB产品。 说明 您可以在提交工单时,说明需要修改slb_quota_backendservers_num参数,提高每个SLB实例可以挂载的服务器数量。 CCM会根据Service中定义的端口创建SLB监听。默认情况下一个SLB实例可以添加50个监听,如需添加更多监听,请提交工单给SLB产品。 说明 您可以在提交工单时,说明需要修改slb_quota_listeners_num参数,用于提高每个实例可以保有的监听数量。 更多SLB使用限制请参见使用限制。 负载均衡SLB配额查询请参见负载均衡SLB配额管理。 通过命令行操作 方法一: 通过命令行工具创建一个Nginx应用。 root@master # kubectl run nginx --image=registry.aliyuncs.com/acs/netdia:latest root@master # kubectl get po NAME READY STATUS RESTARTS AGE nginx-2721357637-dvwq3 1/1 Running 1 6s 为Nginx应用创建阿里云负载均衡服务,指定 type=LoadBalancer 来向外网用户暴露Nginx服务。 root@master # kubectl expose deployment nginx --port=80 --target-port=80 --type=LoadBalancer root@master # kubectl get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx 172.19.XX.XX 101.37.XX.XX 80:31891/TCP 4s 在浏览器中访问 http://101.37.XX.XX,来访问您的Nginx服务。 方法二: 将下面的yml code保存到 nginx-svc.yml文件中。 apiVersion: v1 kind: Service metadata: labels: run: nignx name: nginx-01 namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 执行如下命令,创建一个Nginx应用。 kubectl apply -f nginx-svc.yml 执行如下命令,向外网用户暴露Nginx服务。 root@master # kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE9d ngi-01nx LoadBalancer 172.19.XX.XX 101.37.XX.XX 80:32325/TCP 3h 在浏览器中访问 http://101.37.XX.XX,来访问您的Nginx服务。 通过 Kubernetes Dashboard 操作 将下面的yml code保存到 nginx-svc.yml文件中。 apiVersion: v1 kind: Service metadata: labels: run: nginx name: http-svc namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 登录容器服务管理控制台,单击目标集群右侧的控制台,进入Kubernetes Dashboard页面。 单击创建,开始创建应用。 创建应用 单击使用文件创建。选择刚才保存的nginx-svc.yml 文件。 单击上传。 此时,会创建一个阿里云负载均衡实例指向创建的Nginx应用,服务的名称为 http-svc。 在Kubernetes Dashboard上定位到default命名空间,选择服务。 可以看到刚刚创建的 http-svc 的Nginx服务和机器的负载均衡地址 http://114.55.XX.XX:80。 访问服务 将该地址拷贝到浏览器中即可访问该服务。 通过控制台操作 登录容器服务管理控制台。 在 Kubernetes 菜单下,单击左侧导航栏中的应用 > 无状态,进入无状态(Deployment)页面。 选择目标集群和命名空间,单击右上角使用模板创建。 创建应用 示例模板选为自定义,将以下内容复制到模板中。 apiVersion: v1 kind: Service metadata: labels: run: nginx name: ngnix namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 单击创建。 创建成功,单击Kubernetes 控制台前往控制台查看创建进度。 Kubernetes 控制台 或单击左侧导航栏路由与负载均衡 > 服务,选择目标集群和命名空间,查看已部署的服务。 部署服务 更多信息 阿里云负载均衡还支持丰富的配置参数,包含健康检查、收费类型、负载均衡类型等参数。 注释 阿里云可以通过注释annotations的形式支持丰富的负载均衡功能。 创建一个公网类型的负载均衡 apiVersion: v1 kind: Service metadata: name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建一个私网类型的负载均衡 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建HTTP类型的负载均衡 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建HTTPS类型的负载均衡 需要先在阿里云控制台上创建一个证书并记录cert-id,然后使用如下annotation创建一个 HTTPS 类型的SLB。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "https:443" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 限制负载均衡的带宽 只限制负载均衡实例下的总带宽,所有监听共享实例的总带宽,参见共享实例带宽。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type: "paybybandwidth" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth: "100" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 指定负载均衡规格 负载均衡规格可参见CreateLoadBalancer。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: "slb.s1.small" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 使用已有的负载均衡 默认情况下,使用已有的负载均衡实例,不会覆盖监听,如要强制覆盖已有监听,请配置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners为true。 说明 复用已有的负载均衡默认不覆盖已有监听,因为以下两点原因: 如果已有负载均衡的监听上绑定了业务,强制覆盖可能会引发业务中断。 由于CCM目前支持的后端配置有限,无法处理一些复杂配置。如果有复杂的后端配置需求,可以在不覆盖监听的情况下,通过控制台自行配置监听。 如存在以上两种情况不建议强制覆盖监听,如果已有负载均衡的监听端口不再使用,则可以强制覆盖。 使用已有的负载均衡暂不支持添加额外标签(annotation: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-additional-resource-tags) apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALACER_ID}" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 使用已有的负载均衡,并强制覆盖已有监听 强制覆盖已有监听,如果监听端口冲突,则会删除已有监听。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALACER_ID}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 使用指定Label的worker节点作为后端服务器 多个Label以逗号分隔。例如"k1=v1,k2=v2"。多个label之间是and的关系。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-backend-label: "failure-domain.beta.kubernetes.io/zone=ap-southeast-5a" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为TCP类型的负载均衡配置会话保持时间 参数service.beta.kubernetes.io/alibaba-cloud-loadbalancer-persistence-time仅对TCP协议的监听生效。 如果负载均衡实例配置了多个TCP协议的监听端口,则默认将该配置应用到所有TCP协议的监听端口。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-persistence-timeout: "1800" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为HTTP&HTTPS协议的负载均衡配置会话保持(insert cookie) 仅支持HTTP及HTTPS协议的负载均衡实例。 如果配置了多个HTTP或者HTTPS的监听端口,该会话保持默认应用到所有HTTP和HTTPS监听端口。 配置insert cookie,以下四项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type: "insert" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie-timeout: "1800" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 为HTTP&HTTPS协议的负载均衡配置会话保持(server cookie) 仅支持HTTP及HTTPS协议的负载均衡实例。 如果配置了多个HTTP或者HTTPS的监听端口,该会话保持默认应用到所有HTTP和HTTPS监听端口。 配置server cookie,以下四项annotation必选。 cookie名称(service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie)只能包含字母、数字、‘_’和‘-’。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type: "server" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie: "${YOUR_COOKIE}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建负载均衡时,指定主备可用区 某些region的负载均衡不支持主备可用区,例如ap-southeast-5。 一旦创建,主备可用区不支持修改。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "ap-southeast-5a" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "ap-southeast-5a" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 使用Pod所在的节点作为后端服务器 默认externalTrafficPolicy为Cluster模式,会将集群中所有节点挂载到后端服务器。Local模式仅将Pod所在节点作为后端服务器。 Local模式需要设置调度策略为加权轮询wrr。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler: "wrr" name: nginx namespace: default spec: externalTrafficPolicy: Local ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建私有网络类型(VPC)的负载均衡 创建私有网络类型的负载均衡,以下两个annotation必选。 私网负载均衡支持专有网络(VPC)和经典网络(Classic),两者区别参见实例概述。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-network-type: "vpc" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 创建按流量付费的负载均衡 仅支持公网类型的负载均衡实例 以下两项annotation必选 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth: "45" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type: "paybybandwidth" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 创建带健康检查的负载均衡 设置TCP类型的健康检查 TCP端口默认开启健康检查,且不支持修改,即service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag annotation无效。 设置TCP类型的健康检查,以下所有annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type: "tcp" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout: "8" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval: "3" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 设置HTTP类型的健康检查 设置HTTP类型的健康检查,以下所有的annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type: "http" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-uri: "/test/index.html" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout: "10" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval: "3" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 为负载均衡设置调度算法 rr(默认值):轮询,按照访问顺序依次将外部请求依序分发到后端服务器。 wrr:加权轮询,权重值越高的后端服务器,被轮询到的次数(概率)也越高。 wlc:加权最小连接数,除了根据每台后端服务器设定的权重值来进行轮询,同时还考虑后端服务器的实际负载(即连接数)。当权重值相同时,当前连接数越小的后端服务器被轮询到的次数(概率)也越高。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler: "wlc" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为负载均衡配置访问控制策略组 需要先在阿里云负载均衡控制台上创建一个负载均衡访问控制策略组,然后记录该访问控制策略组ID(acl-id),然后使用如下annotation创建一个带有访问控制的负载均衡实例。 白名单适合只允许特定IP访问的场景,black黑名单适用于只限制某些特定IP访问的场景。 使用该功能前,请确保CloudControllerManage组件是最新版本。请登录容器服务管理控制台,在左侧导航栏选择集群 > 集群,在集群列表中对需要升级的集群单击更多 > 系统组件升级,在组件列表中找到Cloud Controller Manager,单击升级。系统组建升级 创建带有访问控制的负载均衡,以下三项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-status: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-id: "${YOUR_ACL_ID}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-type: "white" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为负载均衡指定虚拟交换机 通过阿里云专有网络控制台查询交换机ID,然后使用如下的annotation为负载均衡实例指定虚拟交换机。 为负载均衡指定虚拟交换机,以下两项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vswitch-id: "${YOUR_VSWITCH_ID}" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为负载均衡指定转发端口 端口转发是指将http端口的请求转发到https端口上。 设置端口转发需要先在阿里云控制台上创建一个证书并记录cert-id。 如需设置端口转发,以下三项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "https:443,http:80" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-forward-port: "80:443" name: nginx namespace: default spec: ports: - name: https port: 443 protocol: TCP targetPort: 443 - name: http port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 为负载均衡添加额外标签 多个tag以逗号分隔,例如"k1=v1,k2=v2"。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-additional-resource-tags: "Key1=Value1,Key2=Value2" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 移除SLB后端unscheduleable状态的节点 kubectl cordon与kubectl drain命令会将节点置为unscheduleable状态,默认service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend的取值为off,此时不会将处于unscheduleable状态的节点从SLB的后端服务器组移除。若需要从SLB的后端服务器组移除unscheduleable状态的节点,请将service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend的的取值设置为on。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend: "on" name: nginx spec: externalTrafficPolicy: Local ports: - name: http port: 30080 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 直接将Pod ENI挂载到SLB后端 支持在Terway 网络模式下,通过annotation:service.beta.kubernetes.io/backend-type:"eni" 将Pod直接挂载到SLB后端,提升网络转发性能。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/backend-type: "eni" name: nginx spec: ports: - name: http port: 30080 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 创建IPv6类型的负载均衡 集群的kube-proxy代理模式需要是IPVS。 生成的IPv6地址仅可在支持IPv6的环境中访问。 创建后IP类型不可更改。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-ip-version: "ipv6" name: nginx spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 说明 注释的内容是区分大小写的。 自2019年9月11日起,annotation字段alicloud更新为alibaba-cloud。 例如: 更新前:service.beta.kubernetes.io/alicloud-loadbalancer-id 更新后:service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id 系统将继续兼容alicloud的写法,用户无需做任何修改,敬请注意。 注释 类型 描述 默认值 支持的版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port string 多个值之间由逗号分隔,例如:https:443,http:80 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type string 取值可以是internet或者intranet internet v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slb-network-type string 负载均衡的网络类型,取值可以是classic或者vpc 取值为vpc时,需设置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type为intranet。 classic v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type string 取值可以是paybytraffic或者paybybandwidth paybytraffic v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id string 负载均衡实例的 ID。通过 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id指定您已有的SLB,默认情况下,使用已有的负载均衡实例,不会覆盖监听,如要强制覆盖已有监听,请配置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners为true。 无 v1.9.3.81-gca19cd4-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-backend-label string 通过 label 指定 SLB 后端挂载哪些worker节点。 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec string 负载均衡实例的规格。可参见:CreateLoadBalancer 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-persistence-timeout string 会话保持时间。 仅针对TCP协议的监听,取值:0-3600(秒) 默认情况下,取值为0,会话保持关闭。 可参见:CreateLoadBalancerTCPListener 0 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session string 是否开启会话保持。取值:on | off 说明 仅对HTTP和HTTPS协议的监听生效。 可参见:CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener off v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type string cookie的处理方式。取值: insert:植入Cookie。 server:重写Cookie。 说明 仅对HTTP和HTTPS协议的监听生效。 当service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session取值为on时,该参数必选。 可参见:CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie-timeout string Cookie超时时间。取值:1-86400(秒) 说明 当service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session为on且service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type为insert时,该参数必选。 可参见:CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie string 服务器上配置的Cookie名称。 长度为1-200个字符,只能包含ASCII英文字母和数字字符,不能包含逗号、分号或空格,也不能以$开头。 说明 当service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session为on且service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type为server时,该参数必选。 可参见:CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid string 主后端服务器的可用区ID。 无 v1.9.3.10-gfb99107-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid string 备后端服务器的可用区ID。 无 v1.9.3.10-gfb99107-aliyun及以上版本 externalTrafficPolicy string 哪些节点可以作为后端服务器,取值: Cluster:使用所有后端节点作为后端服务器。 Local:使用Pod所在节点作为后端服务器。 Cluster v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners string 绑定已有负载均衡时,是否强制覆盖该SLB的监听。 false:不覆盖 v1.9.3.81-gca19cd4-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth string 负载均衡的带宽,仅适用于公网类型的负载均衡。 50 v1.9.3.10-gfb99107-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id string 阿里云上的证书ID。您需要先上传证书 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag string 取值是on | off TCP监听默认为on且不可更改。 HTTP监听默认为off。 默认为off。TCP 不需要改参数。因为 TCP 默认打开健康检查,用户不可设置。 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type string 健康检查类型,取值:tcp | http。 可参见:CreateLoadBalancerTCPListener tcp v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-uri string 用于健康检查的URI。 说明 当健康检查类型为TCP模式时,无需配置该参数。 可参见:CreateLoadBalancerTCPListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-port string 健康检查使用的端口。取值: -520:默认使用监听配置的后端端口。 1-65535:健康检查的后端服务器的端口。 可参见:CreateLoadBalancerTCPListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold string 健康检查连续成功多少次后,将后端服务器的健康检查状态由fail判定为success。 取值:2-10 可参见:CreateLoadBalancerTCPListener 3 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold string 健康检查连续失败多少次后,将后端服务器的健康检查状态由success判定为fail。取值: 2-10 可参见:CreateLoadBalancerTCPListener 3 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval string 健康检查的时间间隔。 取值:1-50(秒) 可参见:CreateLoadBalancerTCPListener 2 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout string 接收来自运行状况检查的响应需要等待的时间,适用于TCP模式。如果后端ECS在指定的时间内没有正确响应,则判定为健康检查失败。 取值:1-300(秒) 说明 如果service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout的值小于service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值,则service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout无效,超时时间为service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值。 可参见:CreateLoadBalancerTCPListener 5 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout string 接收来自运行状况检查的响应需要等待的时间,适用于HTTP模式。如果后端ECS在指定的时间内没有正确响应,则判定为健康检查失败。 取值:1-300(秒) 说明 如果 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout的值小于service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值,则 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout无效,超时时间为 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值。 可参见:CreateLoadBalancerTCPListener 5 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-domain string 用于健康检查的域名。 $_ip:后端服务器的私网IP。当指定了IP或该参数未指定时,负载均衡会使用各后端服务器的私网IP当做健康检查使用的域名。 domain:域名长度为1-80,只能包含字母、数字、点号(.)和连字符(-)。 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-httpcode string 健康检查正常的HTTP状态码,多个状态码用逗号(,)分割。取值: http_2xx http_3xx http_4xx http_5xx 默认值为http_2xx。 http_2xx v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler string 调度算法。取值wrr | wlc| rr。 wrr:权重值越高的后端服务器,被轮询到的次数(概率)也越高。 wlc:除了根据每台后端服务器设定的权重值来进行轮询,同时还考虑后端服务器的实际负载(即连接数)。当权重值相同时,当前连接数越小的后端服务器被轮询到的次数(概率)也越高。 rr:默认取值,按照访问顺序依次将外部请求依序分发到后端服务器。 rr v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-status string 是否开启访问控制功能。取值: on | off off v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-id string 监听绑定的访问策略组ID。当AclStatus参数的值为on时,该参数必选。 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-type string 访问控制类型。 取值:white | black。 white:仅转发来自所选访问控制策略组中设置的IP地址或地址段的请求,白名单适用于应用只允许特定IP访问的场景。设置白名单存在一定业务风险。一旦设名单,就只有白名单中的IP可以访问负载均衡监听。如果开启了白名单访问,但访问策略组中没有添加任何IP,则负载均衡监听会转发全部请求。 black: 来自所选访问控制策略组中设置的IP地址或地址段的所有请求都不会转发,黑名单适用于应用只限制某些特定IP访问的场景。如果开启了黑名单访问,但访问策略组中没有添加任何IP,则负载均衡监听会转发全部请求。当AclStatus参数的值为on时,该参数必选。 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vswitch-id string 负载均衡实例所属的VSwitch ID。设置该参数时需同时设置addresstype为intranet。 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-forward-port string 将HTTP请求转发至HTTPS指定端口。取值如80:443 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-additional-resource-tags string 需要添加的Tag列表,多个标签用逗号分隔。例如:"k1=v1,k2=v2" 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend string 从slb后端移除SchedulingDisabled Node。取值on | off off v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/backend-type string 支持在Terway eni网络模式下,通过设定改参数为"eni",可将Pod直接挂载到SLB后端,提升网络转发性能。取值:eni。 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-ip-version string 负载均衡实例的IP版本,取值:ipv4或ipv6 ipv4 v1.9.3.220-g24b1885-aliyun及以上版本

1934890530796658 2020-03-31 15:26:42 0 浏览量 回答数 0

回答

创建一个包含模板间共享布局的模板,通常这样的模板包含: 页面头部、导航栏、脚部、内容展示区域。 Layout.html <!DOCTYPE html> <html xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"> <head> <title>Layout page</title> <script src="common-script.js"></script> </head> <body> <header> <h1>My website</h1> </header> <section layout:fragment="content"> <p>Page content goes here</p> </section> <footer> <p>My footer</p> <p layout:fragment="custom-footer">Custom footer here</p> </footer> </body> </html> 注意事项: 1. html标签上附上命名空间 2. section与脚部p标签上使用layout:fragment属性 这些是布局中的插入候选槽点,通过匹配内容模板中片段进行替换。 创建一些内容模板: Content1.html <!DOCTYPE html> <html xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout" layout:decorate="~{Layout}"> <head> <title>Content page 1</title> <script src="content-script.js"></script> </head> <body> <section layout:fragment="content"> <p>This is a paragraph from content page 1</p> </section> <footer> <p layout:fragment="custom-footer">This is some footer content from content page 1</p> </footer> </body> </html> html标签中的layout:decorate说明哪一个布局模板使用这个内容模板进行装饰。内容模板定义自身标题与脚本、content与custom-footer片段。custom-footer片段处于footer元素内部,这其实是不必要的,但是可能会是很方便的,如果想要做内容模板的静态模板,这是一开始使用Thymeleaf的原因之一。 在一个模板内片段名称必须唯一,否则可能会出现片段不匹配,各种各样的可笑事情会接踵而至。 不管如何,一旦告知Thymeleaf处理Content1.html,最终的页面会是这样子: <!DOCTYPE html> <html> <head> <title>Content page 1</title> <script src="common-script.js"></script> <script src="content-script.js"></script> </head> <body> <header> <h1>My website</h1> </header> <section> <p>This is a paragraph from content page 1</p> </section> <footer> <p>My footer</p> <p>This is some footer content from content page 1</p> </footer> </body> </html> 内容模板装饰Layout.html,结果是布局的组合,加上内容模板的片段(两个模板的<head>元素,来自内容模板的<title>元素替换布局文件内的,所有的元素来自布局文件,但是由所有指定的内容模板进行替换) 想了解更多可以如何控制<head>元素合并,参看<head>元素合并一小节。 装饰进程重定向处理从内容模板至布局,将layout:fragment部分从内容模板中挑选出来,因为布局需要它们。正因如此,任何在layout:fragment之外的东西实际从未得到执行,这说明在内容模板中不能这样做: <div th:if="${user.admin}"> <div layout:fragment="content"> ... </div> </div> 如果布局模板想要’内容’片段,那么会得到那个片段,不顾任何所在条件,因为那些条件不会执行。 如果说只想用绝对最小HTML代码量替换装饰器脚部: Content2.html <p layout:decorate="~{Layout}" layout:fragment="custom-footer"> This is some footer text from content page 2. </p> 这就是全部所需的东西!<p>标签同时用作根元素与片段定义,生成一个像这样的页面: <!DOCTYPE html> <html> <head> <title>Layout page</title> <script src="common-script.js"></script> </head> <body> <header> <h1>My website</h1> </header> <section> <p>Page content goes here</p> </section> <footer> <p>My footer</p> <p> This is some footer text from content page 2. </p> </footer> </body> </html> 可以把布局看作母版,会得以填充或者被内容(子模板)覆盖,仅当内容会填充/覆盖父类。以这种方式,布局充当某种’默认’,内容充当这种默认之上的实现。 给布局传送数据 子模板向上给母版布局传送数据,在涉及到布局/装饰过程的任意元素上使用th:with/ data-th-with属性处理器,可以在任何地方layout:decorate/ data-layout-decorate 或者可以发现 layout:fragment/data-layout-fragment, 例如: 孩子/内容模板: <html layout:decorate="your-layout.html" th:with="greeting='Hello!'"> 1 父类/布局模板: <html> ... <p th:text="${greeting}"></p> <!-- You'll end up with "Hello!" in here --> 将来,或许会增加支持使用分片局部变量,很像Thymeleaf用于创建片段签名。 配置标题 鉴于布局方言自动用内容模板中所发现的重载布局<title>,可能会发现自己重复布局中发现的标题部分,尤其是想要创建面包屑或者在页面标题中保留页面名称。layout:title-pattern处理器可以免除重复布局标题的问题,通过使用一些特殊标记以想要标题如何出现的模式。 这是一个例子: Layout.html <!DOCTYPE html> <html xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"> <head> <title layout:title-pattern="$LAYOUT_TITLE - $CONTENT_TITLE">My website</title> </head> ... </html> layout:title-pattern处理器采取简单字符串,识别两种特殊标记:$LAYOUT_TITLE与$CONTENT_TITLE。每种标记在结果页中会被各自相应的标题替换。所以,如果有下面的内容模板: Content.html <!DOCTYPE html> <html xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout" layout:decorator="Layout"> <head> <title>My blog</title> </head> ... </html> 结果页会是这样: <!DOCTYPE html> <html> <head> <title>My website - My blog</title> </head> ... </html> 这对<title>元素内的静态/内联文本或者<title>元素上发现使用th:text的动态文本均有效。 上述例子中的模式在布局中指定,所以对所有使用布局的内容模板均适用。如果在内容模板中指定另一种标题模式,那么会覆盖布局中发现的那个,允许细粒度的控制标题的展现形式。 可重用模板 假如发现有一些HTML或者结构经常性地重复,想要做成自己的模板从不同地方插入以便减少代码重复。(模块化Thymeleaf?)这个的例子可能会是一个模态面板,由几个HTML元素与CSS类构成,在网页应用中产生一个新窗口的效果: Modal.html <!DOCTYPE html> <html> <body> <div id="modal-container" class="modal-container" style="display:none;"> <section id="modal" class="modal"> <header> <h1>My Modal</h1> <div id="close-modal" class="modal-close"> <a href="#close">Close</a> </div> </header> <div id="modal-content" class="modal-content"> <p>My modal content</p> </div> </section> </div> </body> </html> 会发现可以将一些东西转换成像头部、ID的变量,以便包含Modal.html的页面可以设定它们自己的名称/ID。继续尽可能泛型化编写模态代码,然而会遇到填充自己的模态框内容的问题,那是开始接触一些限制的地方。 一些页面使用单一消息的模态框,其他想要使用模态框容纳一些更复杂的东西比如接受用户输入的表单。模态框可能性变得无休无止,但是未支持想象,发现自己得不得将这段模态框代码拷贝到每一个模板中,每一次使用场合变化相应内容,重复同样的HTML代码维持同样的外观感受,打破了过程中的DRY原则。 主要妨碍适当重用的事情是无法将HTML元素传递至插入模板中。这正是layout:insert有用的地方。它运作起来完全像th:insert,但是通过指定与实现片段很像内容/布局实例,可以创建一个公共的结构,对插入它的模板使用场合作出响应。 这是一个更新的模态框模板,使用Thymeleaf与layout:fragment属性定义一个可替换的模态框内容部分以变得更加泛型化: Modal2.html Modal2.html <!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org" xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"> <body layout:fragment="modal(modalId, modalHeader)"> <div th:id="${modalId} + '-container'" class="modal-container" style="display:none;"> <section th:id="${modalId}" class="modal"> <header> <h1 th:text="${modalHeader}">My Modal</h1> <div th:id="'close-' + ${modalId}" class="modal-close"> <a href="#close">Close</a> </div> </header> <div th:id="${modalId} + '-content'" class="modal-content"> <div layout:fragment="modal-content"> <p>My modal content</p> </div> </div> </section> </div> </body> </html> 现在可以插入这个模板,使用layout:insert处理器与无论怎样需要实现modal-content片段,通过在调用模板插入元素内创建同样名称的片段: Content.html <!DOCTYPE html> <html xmlns:th="http://www.thymeleaf.org" xmlns:layout="http://www.ultraq.net.nz/thymeleaf/layout"> ... <div layout:insert="Modal2 :: modal(modalId='message', modalHeader='Message')" th:remove="tag"> <p layout:fragment="modal-content">Message goes here!</p> </div> ... </html> 就像内容/布局实例,插入模板layout:fragment会被匹配片段名称的元素替换掉。在这种场合下,Modal2.html的整个modal-content部分会被上述自定义段落替换掉。这是结果: <!DOCTYPE html> <html> ... <div id="message-container" class="modal-container" style="display:none;"> <section id="message" class="modal"> <header> <h1>Message</h1> <div id="close-message" class="modal-close"> <a href="#close">Close</a> </div> </header> <div id="message-content" class="modal-content"> <p>Message goes here!</p> </div> </section> </div> ... </html> 定义在模板内包含Modal2.html的自定义消息作为模态框内容的一部分。在插入模板上下文环境中的片段与用于内容/布局过程中的片段一样工作:如果片段未在模板中定义,那么它不会覆盖插入模板中的内容,使得在可重用版本中创建默认。

景凌凯 2020-04-29 21:11:25 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站