• 关于

    http协议概述

    的搜索结果

回答

概述 防火墙功能支持用户对服务器的端口进行开启和关闭。服务器默认分别开启了 22 端口(对应 SSH 服务),80 端口(对应 HTTP 服务),443 端口(对应 HTTPS 加密访问服务)。未在开放端口范围内的端口默认是关闭状态。 添加防火墙规则 登录轻量服务器控制台,单击 服务器运维 > 防火墙 > 添加规则。 e6e35732a916d9c7.png | center 选择对应的应用类型、协议和端口号后,单击 确定。 如果需要添加多条,可以单击下方的 添加规则。 firewall 防火墙默认预置了如下应用和端口的映射关系供选择。 应用类型 协议 端口 说明 HTTP TCP 80 HTTP 协议默认端口 HTTPS TCP 443 HTTPS 加密协议默认端口 SSH TCP 22 SSH 协议默认端口 FTP TCP 21 FTP 协议默认端口 Telnet TCP 23 Telnet 默认端口 MySQL TCP 3306 MySQL 数据库默认端口 自定义 TCP/UDP 1-65535 其他用户自定义的端口
1934890530796658 2020-03-30 12:49:58 0 浏览量 回答数 0

问题

搜索引擎抓取系统概述(含搜索引擎工作原理等)

       站长朋友们,今后定期都将在这里跟大家分享一些有关搜索引擎工作原理及网站运营相关的内容,并且欢迎大家来此与我讨论或分享一些自己的经验、心得等等。今天先简单介绍一下关于搜索引擎抓取系统中有关抓取系统基本...
kideny 2019-12-01 21:30:39 5387 浏览量 回答数 1

问题

Swarm 集群  服务发现和负载均衡  概述

服务发现和负载均衡主要解决通信的可靠性问题。为了达到可靠性,容器服务引入了负载均衡机制。通信又可以分为对外暴露服务的通信和内部服务之间的通信。下面根据场景引导您使用不同的解决方案。 场景一 普通且简单的 7 层协议负载...
青蛙跳 2019-12-01 21:36:21 605 浏览量 回答数 0

回答

本页目录 概述 计算签名 HTTP协议Header 阿里云协议Header(CanonicalizedHeaders) 规范资源(CanonicalizedResource) Body 为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RESTful API需要按如下格式在API请求头(request header)中添加Authorization参数进行签名: Authorization:acs:AccessKeyId:Singature 其中: acs:Alibaba Cloud Service的缩写,固定标识不可修改。 AccessKeyId:调用者调用API所用的密钥ID。 Signature:使用AccessKey Secret对请求进行对称加密的签名。 计算签名 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 完成以下操作,计算签名: 构建待签名字符串。 待签名字符串(StringToSign)是API请求拼装的字符串,用于计算签名,包括: HTTP协议Header 阿里云协议Header(CanonicalizedHeaders) 规范资源(CanonicalizedResource) Body 待签名字符串必须按照以下顺序构造: StringToSign = //http协议Header HTTP-Verb + "\n" + Accept + "\n" + Content-MD5 + "\n" +//Body的MD5值放在此处 Content-Type + "\n" + Date + "\n" + //阿里云协议header(CanonicalizedHeaders) CanonicalizedHeaders + //签名中如何包含CanonicalizedResource(规范资源) CanonicalizedResource 示例:原始请求 POST /stacks?name=test_alert&status=COMPLETE HTTP/1.1 Host:***.aliyuncs.com Accept:application/json Content-MD5:ChDfdfwC+Tn874znq7Dw7Q== Content-Type:application/x-www-form-urlencoded;charset=utf-8 Accept-Encoding:identity Date:Thu, 22 Feb 2018 07:46:12 GMT x-acs-signature-method:HMAC-SHA1 x-acs-signature-nonce:550e8400-e29b-41d4-a716-446655440000 x-acs-signature-version:1.0 x-acs-version:2019-03-20 示例:待签名字符串 POST application/json ChDfdfwC+Tn874znq7Dw7Q== application/x-www-form-urlencoded;charset=utf-8 Thu, 22 Feb 2018 07:46:12 GMT x-acs-signature-method:HMAC-SHA1 x-acs-signature-nonce:550e8400-e29b-41d4-a716-446655440000 x-acs-signature-version:1.0 x-acs-version:2019-03-20 /stacks?name=test_alert&status=COMPLETE 添加签名。 将计算好的签名以如下格式添加到请求的Header中: Authorization: acs AccessKeyId:Signature HTTP协议Header 计算签名必须包含一下参数,并按字典顺序排列;若值不存在则以“\n”补齐。 Accept :客户端需要的返回值类型,取值:application/json | application/xml。 Content-MD5:HTTP协议消息体的128-bit MD5散列值转换成BASE64编码的结果。 Accept-Encoding:HTTP Header中Accept-Encoding 是浏览器发给服务器,声明浏览器支持的编码类型。 Content-Type:RFC 2616中定义的HTTP请求内容类型。 Date:HTTP 1.1协议中规定的GMT时间,例如:Wed, 05 Sep. 2012 23:00:00 GMT。 说明 不包含key。 示例:原始header Accept:application/json Content-MD5:ChDfdfwC+Tn874znq7Dw7Q== Content-Type:application/x-www-form-urlencoded;charset=utf-8 Accept-Encoding:identity Date:Thu, 22 Feb 2018 07:46:12 GMT 示例:规范header application/json ChDfdfwC+Tn874znq7Dw7Q== application/x-www-form-urlencoded;charset=utf-8 Thu, 22 Feb 2018 07:46:12 GMT 阿里云协议Header(CanonicalizedHeaders) 阿里云规范头,非标准HTTP头部信息,是请求中出现的以x-acs-为前缀的参数。请求中必须包含以下参数: x-acs-signature-nonce:唯一随机数,用于防止网络重放攻击。在不同请求间要使用不同的随机数值。 x-acs-signature-version:签名版本,取值:1.0 x-acs-version:API版本号,请参照各产品的API文档。 完成以下操作,构造阿里云规范头: 将所有以x-acs-为前缀的HTTP请求头的名字转换成小写字母。如将X-acs-OSS-Meta-Name: TaoBao转换成x-acs-oss-meta-name: TaoBao。 将上一步得到的所有HTTP阿里云规范头按照字典序进行升序排列。 删除请求头和内容之间分隔符两端出现的任何空格。如将x-acs-oss-meta-name: TaoBao,Alipay转换成x-acs-oss-meta-name:TaoBao,Alipay。 将所有的头和内容用“\n”分隔符分隔拼成最后的CanonicalizedHeaders。 示例:原始header x-acs-signature-nonce:550e8400-e29b-41d4-a716-446655440000 x-acs-signature-method:HMAC-SHA1 x-acs-signature-version:1.0 x-acs-version: 2019-03-20GMT 示例:规范header x-acs-signature-nonce:550e8400-e29b-41d4-a716-446655440000 x-acs-signature-method:HMAC-SHA1 x-acs-signature-version:1.0 x-acs-version:2019-03-20 规范资源(CanonicalizedResource) CanonicalizedResource表示想要访问资源的规范描述,需要将子资源和query参数一同按照字典序,从小到大排列并以“&”为分隔符生成子资源字符串(?后的所有参数)。 示例:原始请求 /stacks?status=COMPLETE&name=test_alert 示例:规范请求 /stacks?name=test_alert&status=COMPLETE Body 将请求的body用MD5算法加密,在进行base64编码,将结果添加到Content-MD5中。
1934890530796658 2020-03-23 14:42:33 0 浏览量 回答数 0

问题

服务发现和负载均衡的概述

服务发现和负载均衡主要解决通信的可靠性问题。为了达到可靠性,容器服务引入了负载均衡机制。通信又可以分为对外暴露服务的通信和内部服务之间的通信。下面根据场景引导您使用不同的解决方案。 场景一 普通且简单的 7 层协议负载均衡&...
反向一觉 2019-12-01 21:20:06 1340 浏览量 回答数 0

问题

Swarm mode 集群中服务发现和负载均衡的概述

服务发现和负载均衡主要解决通信的可靠性问题。为了达到可靠性,容器服务引入了负载均衡机制。通信又可以分为对外暴露服务的通信和内部服务之间的通信。 swarm mode 集群内置负载均衡机制,基于 ingress&#...
反向一觉 2019-12-01 21:22:31 1096 浏览量 回答数 0

问题

配置七层监听

七层监听概述 阿里云提供七层(HTTP协议和HTTPS协议)的负载均衡服务,负载均衡七层监听原理上是反向代理的一种实现。客户端HTTP请求到达负载均衡监听后,负载均衡服务器会通...
行者武松 2019-12-01 21:36:08 1822 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RESTful API需要按如下格式在API请求头(request header)中添加Authorization参数进行签名: Authorization:acs:AccessKeyId:Singature 其中: acs:Alibaba Cloud Service的缩写,固定标识不可修改。 AccessKeyId:调用者调用API所用的密钥ID。 Signature:使用AccessKey Secret对请求进行对称加密的签名。 计算签名 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 完成以下操作,计算签名: 构建待签名字符串。 待签名字符串(StringToSign)是API请求拼装的字符串,用于计算签名,包括: HTTP协议Header 阿里云协议Header (CanonicalizedHeaders) 规范资源(CanonicalizedResource) Body 待签名字符串必须按照以下顺序构造: StringToSign = //http协议Header HTTP-Verb + "\n" + Accept + "\n" + Content-MD5 + "\n" +//Body的MD5值放在此处 Content-Type + "\n" + Date + "\n" + //阿里云协议header(CanonicalizedHeaders) CanonicalizedHeaders + //签名中如何包含CanonicalizedResource(规范资源) CanonicalizedResource 示例:原始请求 POST /stacks?name=test_alert&status=COMPLETE HTTP/1.1 Host: ***.aliyuncs.com Accept: application/json Content-MD5: ChDfdfwC+Tn874znq7Dw7Q== Content-Type: application/x-www-form-urlencoded;charset=utf-8 Date: Thu, 22 Feb 2018 07:46:12 GMT x-acs-signature-nonce: 550e8400-e29b-41d4-a716-446655440000 x-acs-signature-method: HMAC-SHA1 x-acs-signature-version: 1.0 x-acs-version: 2016-01-02 示例:规范请求 POST application/json ChDfdfwC+Tn874znq7Dw7Q== application/x-www-form-urlencoded;charset=utf-8 Thu, 22 Feb 2018 07:46:12 GMT x-acs-signature-nonce: 550e8400-e29b-41d4-a716-446655440000 x-acs-signature-method:HMAC-SHA1 x-acs-signature-version:1.0 x-acs-version:2016-01-02 /stacks?name=test_alert&status=COMPLETE 添加签名。 将计算好的签名以如下格式添加到请求的Header中: Authorization: acs AccessKeyId:Signature HTTP协议Header 计算签名必须包含一下参数,并按字典顺序排列;若值不存在则以“\n”补齐。 Accept :客户端需要的返回值类型,取值:application/json | application/xml Content-MD5:HTTP协议消息体的128-bit MD5散列值转换成BASE64编码的结果。 Content-Type:RFC 2616中定义的HTTP请求内容类型。 Date:HTTP 1.1协议中规定的GMT时间,例如:Wed, 05 Sep. 2012 23:00:00 GMT。 说明 不包含key。 示例:原始header Accept: application/json Content-MD5: ChDfdfwC+Tn874znq7Dw7Q== Content-Type: application/x-www-form-urlencoded;charset=utf-8 Date: Thu, 22 Feb 2018 07:46:12 GMT 示例:规范header application/json ChDfdfwC+Tn874znq7Dw7Q== application/x-www-form-urlencoded;charset=utf-8 Thu, 22 Feb 2018 07:46:12 GMT 阿里云协议Header (CanonicalizedHeaders) 阿里云规范头,非标准HTTP头部信息,是请求中出现的以x-acs-为前缀的参数。请求中必须包含以下参数: x-acs-signature-nonce:唯一随机数,用于防止网络重放攻击。在不同请求间要使用不同的随机数值。 x-acs-signature-version:签名版本,取值:1.0 x-acs-version:API版本号,请参照各产品的API文档。 完成以下操作,构造阿里云规范头: 将所有以x-acs-为前缀的HTTP请求头的名字转换成小写字母。如将X-acs-OSS-Meta-Name: TaoBao转换成x-acs-oss-meta-name: TaoBao。 将上一步得到的所有HTTP阿里云规范头按照字典序进行升序排列。 删除请求头和内容之间分隔符两端出现的任何空格。如将x-acs-oss-meta-name: TaoBao,Alipay转换成x-acs-oss-meta-name:TaoBao,Alipay。 将所有的头和内容用“\n”分隔符分隔拼成最后的CanonicalizedHeaders。 示例:原始header x-acs-signature-nonce: 550e8400-e29b-41d4-a716-446655440000 x-acs-signature-method: HMAC-SHA1 x-acs-signature-version: 1.0 x-acs-version: 2016-01-02GMT 示例:规范header x-acs-signature-nonce:550e8400-e29b-41d4-a716-446655440000 x-acs-signature-method:HMAC-SHA1 x-acs-signature-version:1.0 x-acs-version:2016-01-02 规范资源(CanonicalizedResource) CanonicalizedResource表示想要访问资源的规范描述,需要将子资源和query参数一同按照字典序,从小到大排列并以“&”为分隔符生成子资源字符串(?后的所有参数)。 示例:原始请求 /stacks?status=COMPLETE&name=test_alert 示例:规范请求 /stacks?name=test_alert&status=COMPLETE Body 将请求的body用MD5算法加密,在进行base64编码,将结果添加到Content-MD5中。
1934890530796658 2020-03-27 13:12:22 0 浏览量 回答数 0

问题

技术原理

技术架构 如下图所示,整个负载均衡系统由三部分构成:四层负载均衡、七层负载均衡和控制系统。 四层负载均衡:采用开源软件LVS(Linux Virtual Server)...
行者武松 2019-12-01 21:43:50 2231 浏览量 回答数 0

问题

云效使用指南:代码管理:代码管理概述

Git基础 学习Git,推荐阅读开源电子书 Pro Git(中文版)。此外,可参阅下述快捷帮助文档: 开始在命令行中使用Git基础的命令行命令Git基本命令 code.aliyun.com ...
行者武松 2019-12-01 21:59:12 1526 浏览量 回答数 0

问题

Java概述

在使用Java SDK或阅读本手册之前,请务必先阅读《 OAS API参考手册》(以下简称 [backcolor=transparent]API手册)第一章基本概念和第二章功能简介ÿ...
云栖大讲堂 2019-12-01 21:09:10 1183 浏览量 回答数 0

回答

概述 本文主要介绍在不同操作系统中检查TCP 80端口是否正常工作的方法。 详细信息 阿里云提醒您: 如果您对实例或数据有修改、变更等风险操作,务必注意实例的容灾、容错能力,确保数据安全。 如果您对实例(包括但不限于ECS、RDS)等进行配置与数据修改,建议提前创建快照或开启RDS日志备份等功能。 如果您在阿里云平台授权或者提交过登录账号、密码等安全信息,建议您及时修改。 如果实例无法对外提供HTTP服务,可以按以下思路检查Web服务相关的接口(默认为TCP 80)是否正常工作。 在ECS管理控制台,确认安全组已经放行该端口。 远程连接ECS实例,确认服务已经开启。 确认端口正常被监听。如没有,请修改监听地址。 确认实例防火墙已经放行服务。 若仍无法解决,请提交工单咨询。 本文分别介绍在以下不同操作系统中检查TCP 80端口是否正常工作的方法。 Windows Server 2012 Windows Server 2008 CentOS 7.3 Ubuntu 16.04 以下是在Windows Server 2012系统中检查TCP 80端口是否正常工作的方法。 Windows Server 2012 注:在Windows 2012系统的Windows实例中安装IIS服务为例。 登录ECS 管理控制台,确认实例所在安全组里已经添加如下安全组规则。 网络类型 网卡类型 规则方向 授权策略 协议类型 端口范围 授权类型 授权对象 优先级 VPC 网络 不需要配置 入方向 允许 HTTP(80) 80/80 地址段访问 10.0.0.0/8 1 经典网络 公网 参考远程连接 Windows 实例,登录Windows实例。 以下是查看IIS服务是否已经开启的操作步骤。 在 服务器管理器 窗口,单击 工具 > Internet Information Services (IIS) 管理器。如果找不到这个选项,则说明没有成功安装IIS服务,需要重新安装IIS服务。 Windows2012_确认已安装IIS服务 在 Internet Information Services (IIS) 管理器 窗口中确认以下信息。 在 连接 导航栏里,右键单击实例ID,如果 启动 处于灰色状态,表示IIS服务已经开启。 单击 网站,在右边列表页查看您安装的网站的状态。如果网站 状态 为 已停止,则单击网站,在右侧 操作 栏的 管理站点 部分,单击 启动,启动网站。 Windows2012_确认站点已启动 以下是查看端口在实例中是否正常被监听的操作步骤。 启动 命令提示符。 执行如下命令。 netstat -ano | findstr :80 如果返回TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4,则说明80端口正常全网监听。如果返回的不是上述结果,请修改监听地址。 以下是查看实例里防火墙是否已经放行Web服务的操作步骤。 单击 控制面板 > 系统与安全 > Windows 防火墙。 根据防火墙状态,执行不同操作。 如果防火墙处于关闭状态,不需要再做其他处理。如果仍无法访问网站,请提交工单咨询。 如果防火墙处于开启状态,则执行以下操作。 单击 高级设置。 在弹出窗口的左侧导航栏中,单击 入站规则。 选择 万维网服务 (HTTP 流入量),如果处于禁用状态,在 操作 栏里,单击 启用规则。 Windows2012_防火墙里启用HTTP入站规则 完成上述检查,如果仍不能访问实例,请提交工单咨询。 以下是在Windows Server 2008系统中检查TCP 80端口是否正常工作的方法。 Windows Server 2008 注:以在Windows 2008系统的Windows实例中安装IIS服务为例。 登录ECS 管理控制台,确认实例所在安全组里已经添加如下安全组规则。 网络类型 网卡类型 规则方向 授权策略 协议类型 端口范围 授权类型 授权对象 优先级 VPC 网络 不需要配置 入方向 允许 HTTP(80) 80/80 地址段访问 10.0.0.0/8 1 经典网络 公网 参考远程连接 Windows 实例,登录Windows实例。 以下是查看IIS服务是否已经开启的操作步骤。 在 服务器管理器 窗口,选择 角色 > Web 服务器。如果找不到这个选项,则说明没有成功安装IIS服务。 在 Web 服务器 窗口,确认 系统服务 部分显示为 全部正在运行。如果不是这个状态,请启动所有服务。 Windows2008_确认已安装IIS服务 以下是查看端口在实例中是否正常被监听的操作步骤。 启动 命令提示符。 执行如下命令。 netstat -ano | findstr :80 如果返回TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4,则说明80端口正常全网监听。如果返回的不是上述结果,请修改监听地址。 以下是查看实例里防火墙是否已经放行Web服务的操作步骤。 单击 控制面板 > 系统与安全 > 检查防火墙状态。 根据防火墙状态,执行不同操作。 如果防火墙处于关闭状态,不需要再做其他处理。如果仍无法访问网站,请提交工单咨询。 如果防火墙处于开启状态,则执行以下操作。 单击 高级设置。 在弹出窗口的左侧导航栏中,单击 入站规则。 选择 万维网服务 (HTTP 流入量),如果处于禁用状态,在 操作 栏里,单击 启用规则。 Windows2008_防火墙里启用HTTP入站规则 完成上述检查,如果仍不能访问实例,请提交工单咨询。 以下是在CentOS 7.3系统中检查TCP 80端口是否正常工作的方法。 CentOS 7.3 注:以在CentOS 7.3系统的Linux实例中安装Nginx服务为例。 登录ECS 管理控制台,确认实例所在安全组里已经添加如下安全组规则。 网络类型 网卡类型 规则方向 授权策略 协议类型 端口范围 授权类型 授权对象 优先级 VPC 网络 不需要配置 入方向 允许 HTTP(80) 80/80 地址段访问 10.0.0.0/8 1 经典网络 公网 参考远程连接 Linux实例,登录Linux实例。 执行如下运行命令。 systemctl status nginx 如果系统返回类似如下,则说明Nginx已经启动。如果未开启,则执行systemctl start nginx命令。 CentOS7.3_nginx已启动 执行如下命令,查看端口在实例中是否正常被监听。 netstat -an | grep 80 如果返回tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN,则说明80端口正常全网监听。如果返回的不是上述结果,请修改监听地址。 CentOS 7之后的版本默认安装Firewalld。如果已经启用firewalld.service,则需要放行 TCP 80 端口。执行如下命令。若返回结果为success,则表示已经放行TCP 80端口。 firewall-cmd --add-port=80/tcp --permanent 使用CentOS 7之前的版本并开启默认防火墙iptables时,应注意iptables默认不拦截访问,如果配置了iptables规则,需要执行以下步骤。 查看规则列表:执行命令 iptables --line -vnL。根据返回结果执行不同操作。 如果设置了默认拦截,添加规则放行TCP 80端口。执行命令iptables -A INPUT -p tcp --dport 80 -j ACCEPT。 如果设置了DROP TCP 80端口,替换规则放行 80 端口。执行命令iptables -R INPUT [80端口对应的规则编号] -p tcp --dport 80 -j ACCEPT。 保存上述规则,执行命令 service iptables save。 完成上述检查,如果仍不能访问实例,请提交工单咨询。 以下是在Ubuntu 16.04系统中检查TCP 80端口是否正常工作的方法。 Ubuntu 16.04 注:以在Ubuntu 16.04系统的Linux实例中安装Apache2 Web服务器为例。 登录ECS 管理控制台,确认实例所在安全组里已经添加如下安全组规则。 网络类型 网卡类型 规则方向 授权策略 协议类型 端口范围 授权类型 授权对象 优先级 VPC 网络 不需要配置 入方向 允许 HTTP(80) 80/80 地址段访问 10.0.0.0/8 1 经典网络 公网 参考远程连接 Linux实例,登录Linux实例。 查看Apache2 Web服务器是否已经开启。执行命令service apache2 status。如果返回以下结果,说明 Apache2 Web服务器已经启动。如果未开启,执行命令 service apache2 start。 Ubuntu 16.04_Apache2 Web 服务器正常工作 执行如下命令,查看端口在实例中是否正常被监听。 netstat -an | grep 80 如果返回tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN,则说明80端口正常全网监听。如果返回的不是上述结果,请修改监听地址。 如果您已经启用UFW(Ubuntu 预装防火墙),需要放行TCP 80端口或HTTP服务。执行命令ufw allow 80/tcp或ufw allow http。返回结果为Rule added 表示已经放行TCP 80端口或HTTP服务。 注:如果实例中已经安装Firewalld并且已经启用firewalld.service,若需要放行 TCP 80 端口,执行命令firewall-cmd --add-port=80/tcp --permanent。返回结果为success即表示已经放行TCP 80端口。 完成上述检查,如果仍不能访问实例,请提交工单咨询。
1934890530796658 2020-03-25 23:19:54 0 浏览量 回答数 0

回答

本入门教程采用ecs.g6.large实例规格,在CentOS 8.0系统上配置了Apache服务,结合ECS管理控制台展示如何快速使用云服务器ECS。 准备工作 创建账号,以及完善账号信息。 注册阿里云账号,并完成实名认证。具体操作,请参见阿里云账号注册流程。 本入门教程创建的是按量付费实例,您的账号的可用余额(含现金、代金券、优惠券等)不得少于100元人民币。充值方式请参见如何充值。 可选: 阿里云提供一个默认的专有网络VPC,如果您不想使用默认的,可以在目标地域创建一个专有网络和交换机。 具体操作,请参见搭建IPv4专有网络。 可选: 阿里云提供一个默认的安全组,如果您不想使用默认的,可以在目标地域创建一个安全组。 具体操作,请参见创建安全组。 步骤一:创建ECS实例 前往实例创建页。 在购买页面的前四个配置页面,完成实例启动配置。 本入门教程采用以下配置,未提及的配置保持默认选项。 配置页面 配置项 示例 说明 基础配置 付费模式 按量付费 按量付费模式操作相对灵活。详情请参见计费概述。 说明 如果您需要为网站域名备案,必须选择包年包月。 地域与可用区 地域:华东1(杭州) 可用区:随机分配 实例创建后,无法直接更改地域和可用区,请谨慎选择。 实例 规格族:通用型g6 规格:ecs.g6.large 可供选择的实例规格由您所选择的地域以及库存供应决定。 您可以前往ECS实例可购买地域,查看实例的可购情况。 镜像 类型:公共镜像 版本:CentOS 8.0 64位 实例启动后,系统盘将完整复制镜像的操作系统和应用数据。 网络和安全组 专有网络 [默认]vpc-bp1opxu1zkhn00g****** 带[默认]前缀的资源由ECS控制台自动创建。 分配公网IPv4地址 勾选 勾选后,自动分配一个公网IP(v4)地址。 带宽计费模式 按使用流量 按使用流量模式只需为所消耗的公网流量付费。详情请参见公网带宽计费方式。 峰值带宽 2 Mbps 无。 安全组 安全组:[默认]sg-bp1bhjjsoiyx44****** 安全组规则:勾选ICMP协议、SSH 22、RDP 3389、HTTP 80和HTTPS 443端口 带[默认]前缀的资源由ECS控制台自动创建。 系统配置 登录凭证 自定义密码 请记录该配置,连接ECS实例时,您需要输入root密码。 实例名称 EcsQuickStart 本文中的实例一律使用EcsQuickStart指代。 分组设置 标签 ECS:Documentation 有多台实例时,建议添加标签,方便管理。 单击下一步:确认订单,在该页面确认所选配置,或者单击编辑图标编辑-图标返回修改配置。 快速入门-Linux版 可选: 单击保存为启动模板,然后设置模板名称和描述。 快速入门-启动模板 说明 将当前实例所选配置保存为启动模板,方便您下次通过模板一键下单。 勾选《云服务器ECS服务条款》,然后单击创建实例。 单击创建成功提示框里的管理控制台,前往实例列表页面查看创建进度。 实例状态进入运行中后表示已成功创建。复制实例的公网IP地址,便于下文连接ECS实例时使用。快速入门-Linux版-创建成功 步骤二:添加安全组规则 如果创建ECS实例时,您没有在默认安全组中勾选添加安全组规则,或者ECS实例加入的是一个全新的安全组,请按以下步骤继续操作。 单击实例ID,进入实例详情页。 在左侧导航栏,单击本实例安全组,然后单击安全组ID,进入安全组详情页。 在安全组规则页面的右上角,单击快速创建规则。 按以下设置添加安全组规则,未提及的配置保持页面默认选项。 规则方向 授权策略 常用端口 授权类型 授权对象 入方向 允许 SSH 22 RDP 3389 HTTP 80 HTTPS 443 IPv4地址段访问 0.0.0.0/0 说明 常用端口处勾选的是ECS实例上运行的应用需开放的端口。例如步骤四:配置Apache服务时使用的SSH服务和Apache服务,未开启SSH 22端口和HTTP 80端口会导致实例无响应。 0.0.0.0/0表示允许全网段设备访问指定的端口。如果您知晓请求端的IP地址,建议设置为具体的IP范围。 快速入门-Linux版-添加安全组规则 单击确定。 步骤三:连接ECS实例 单击下一步骤中的cloud-shell-try-it按钮,等待初始化CloudShell客户端。 使用ssh命令连接实例。 试用 ssh root@<实例公网IP地址> 提示ECS实例此次授信登录需要存储密钥指纹时,输入yes。 输入ECS实例的root用户名密码,并回车。 输入密码阶段,password:处保持黑屏,无提示信息。提示以下信息则表示您已连接ECS实例。 Welcome to Alibaba Cloud Elastic Compute Service ! 步骤四:配置Apache服务 安装Apache服务。 试用 yum install -y httpd 启动Apache服务。 试用 systemctl start httpd 设置Apache服务开机自启动。 试用 systemctl enable httpd 查询Apache服务是否处于运行中状态。 试用 systemctl status httpd 返回active (running)则表示已开始运行Apache服务。 在当前浏览器页面,新开启一个网页,在地址栏输入实例的公网IP地址,并回车。 试用 http://<实例公网IP地址> 快速入门-Linux版-测试网站 步骤五:(可选)解析网站域名 直接通过实例公网IP地址访问Apache服务会降低服务端安全性。如果您已有域名或者想为Apache网站注册一个域名,请参见以下步骤。 注册域名。 详情请参见注册通用域名。 如果域名指向的网站托管在阿里云中国大陆境内节点服务器,您需要备案域名。 首次备案,请参见首次备案,其他情况请参见ICP备案流程概述。 解析域名,将域名指向实例公网IP。 域名解析是使用域名访问您的网站的必备环节。具体操作流程,请参见设置域名解析。 使用解析后的域名访问Apache服务,例如,https://ecs-quickstarts.info。 步骤六:(可选)释放ECS实例 如果您不再需要这台实例,可以将其释放。释放后,实例停止计费,数据不可恢复。 说明 本小节操作仅适用于按量付费实例,不支持手动释放包年包月实例。如果您需要提前释放包年包月实例,请参见退款规则及退款流程。 返回实例列表页面,找到实例EcsQuickStart。 在操作列中,单击更多 > 实例状态 > 释放设置。 选择立即释放,并单击下一步。 确认要释放的实例,并单击确定。 输入您收到的手机验证码,单击确认。 步骤七:查看费用账单 账单明细数据延迟一天更新,且不含万网和云通信数据。 在ECS管理控制台顶部工具栏处,选择费用 > 用户中心。 ECS快速入门-查看费用账单 在左侧导航栏,单击费用账单,然后单击页面中的账单明细页签。 在实例名称处,输入实例名称EcsQuickStart,并回车开始搜索。 后续步骤 了解云服务器ECS在售的实例规格族:实例规格族 了解更多创建ECS实例的方式:创建方式导航 了解镜像的相关概念:镜像概述 了解安全组的相关概念:安全组概述 了解专有网络VPC的相关概念:什么是专有网络 了解云服务器ECS的常见操作:常用操作导航 了解云服务器ECS提供的API:API概览
1934890530796658 2020-03-24 14:02:43 0 浏览量 回答数 0

回答

如何迁移? 目前,阿里云提供以下两种将经典网络迁移到VPC的方案。这些方案可以独立使用,也可以组合使用,以满足不同的迁移场景: 混访混挂方案 如果您的服务依赖RDS、SLB等云产品,建议您选择混访混挂的迁移方案。该方案可以平滑地将系统迁移至专有网络环境中,保证服务的稳定性。 搭配使用ClassicLink功能,以满足未迁移的经典网络ECS实例访问VPC中云资源的需求。详情参见ClassicLink概述。 单ECS迁移方案 如果您的应用部署在了ECS实例上,且ECS实例重启对系统没有影响,可以选择单ECS迁移方案。 混挂和混访方案 混挂和混访方案是一种系统平滑迁移方案,即用户通过在VPC中新建ECS等云产品实例,然后将系统平滑迁移到VPC。当所有系统都迁移到VPC后,再将经典网络内的资源释放,从而完成经典网络到VPC的迁移。详情参见混访混挂迁移示例。 混挂 混挂指一个负载均衡实例可以同时添加经典网络和VPC网络的ECS作为后端服务器接收监听转发的请求,且支持虚拟服务器组形式的混挂。 公网负载均衡实例和私网负载均衡实例都可开通混挂。 说明  VPC私网负载均衡实例同时挂载经典网络和专有网络ECS时,如果使用四层(TCP和UDP协议)监听,目前无法在经典网络ECS上获取客户端的真实IP,但在专有网络ECS上还可以正常获取客户端的真实IP。对七层监听(HTTP和HTTPS协议)没有影响,可以正常获取客户端的真实IP。 混访 云数据库RDS和对象存储OSS等云产品支持混访,即支持同时被经典网络和专有网络中的ECS访问。通常该类产品都提供两个访问域名,一个是经典网络访问域名,另外一个是专有网络访问域名。 在使用本方案时,请注意: 本方案可以满足绝大部分系统的迁移要求。但如果系统中的专有网络ECS和经典网络ECS有内网通信的需求,可通过ClassicLink功能实现。 本方案仅用于经典网络迁移到VPC。 单ECS迁移方案 单ECS迁移方案,即无需通过创建镜像、重新购买等步骤就能把经典网络的ECS实例迁移到专有网络。 在控制台上完成迁移预约后,阿里云会根据您设置的迁移时间进行迁移,迁移完成后,您将收到迁移成功的短信消息提醒。 在使用单ECS迁移方案时,注意: 迁移过程中ECS需要进行重启,请关注对系统的影响。 迁移后,不需要进行任何特殊配置,ECS实例的公网IP都不变。 虽然公网IP没有变化,但无法在ECS的操作系统中查看到这个公网IP(称之为VPC类型的ECS的固定公网IP)。您可以将按流量计费的ECS实例的固定公网IP转换为EIP,方便管理,详情参见ECS固定公网IP转换为EIP。 如果您的个别应用对ECS操作系统上可见的公网IP有依赖,迁移后会有影响,请谨慎评估。 迁移后,所有地域的ECS实例的私网IP都会变化。 迁移到的目标VPC的交换机的可用区必须和待迁移的ECS的可用区相同。 迁移过程中实例ID及登录信息不变。 包年包月购买方式的实例迁移过程中不需要额外付费。从新的计费周期开始,按照同规格专有网络的价格计算。且迁移到VPC后,ECS的使用费用会降低。 迁移前如有续费变配未生效订单或未支付订单,迁移后该订单将被取消且不能恢复,您需要重新下单。 迁移到VPC后,若ECS有使用其它云服务,需将访问方式调整到VPC访问方式(云产品混访方案)。 望采纳,谢谢
元芳啊 2019-12-02 00:17:01 0 浏览量 回答数 0

问题

健康检查原理

概述 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台E...
行者武松 2019-12-01 21:36:16 1626 浏览量 回答数 0

回答

概述 本文主要介绍SLB实例采集不到访问日志的排查步骤。 详细信息 阿里云提醒您: 如果您对实例或数据有修改、变更等风险操作,务必注意实例的容灾、容错能力,确保数据安全。 如果您对实例(包括但不限于ECS、RDS)等进行配置与数据修改,建议提前创建快照或开启RDS日志备份等功能。 如果您在阿里云平台授权或者提交过登录账号、密码等安全信息,建议您及时修改。 检查是否为SLB实例开通了访问日志功能 每个SLB实例都需要单独设置,开通后产生的访问日志将实时写入日志服务。 登录SLB控制台,在左侧导航栏中单击 日志管理 > 访问日志,在访问日志(7层)页面中,确认存在指定的SLB实例。 确认SLB实例对应的SLS日志存储一列中的日志保存位置正确。 提示:SLS日志存储列显示的是日志服务Project和Logstore,请在对应的位置查看是否存在SLB日志。 检查RAM授权是否正确 若您使用的是子用户,在SLB实例开通访问日志功能时,系统会指引您完成RAM角色授权,成功授权后才能开通访问日志功能。如果RAM角色没有正常创建或创建后被删除,都会导致日志采集后无法投递到日志服务的Logstore。 登录RAM控制台,在RAM角色管理页面查找是否存在AliyunLogArchiveRole。 如果AliyunLogArchiveRole不存在,请使用主账号登录阿里云控制台,并单击快速授权链接,完成授权所需要的RAM角色创建。 如果AliyunLogArchiveRole存在,请单击该角色名称,再单击 权限策略名称,查看策略内容是否正确。默认的授权策略如下所示,如果您的策略与默认策略不相同,可能之前修改过授权策略,请将授权策略改为默认的授权策略。 { "Version": "1", "Statement": [ { "Action": [ "log:PostLogStoreLogs" ], "Resource": "*", "Effect": "Allow" } ] } 检查是否产生日志 如果在日志服务控制台没有查看到SLB访问日志,可能是由于SLB实例没有日志产生。可能的原因如下所示。 当前实例未配置七层监听:日志服务目前只支持SLB七层监听的实例开通访问日志功能,暂不支持四层实例的日志采集。常见的七层监听协议有HTTP和HTTPS,详细说明请参考监听介绍。 日志服务不会采集开通访问日志功能之前的历史日志:开通SLB实例的访问日志功能之后,日志功能从开通时间开始采集日志。 指定实例没有访问请求:使用访问日志功能后,必须访问七层监听的SLB实例,才会产生访问日志。 适用于 日志服务 负载均衡 SLB
保持可爱mmm 2020-03-26 23:10:41 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

回答

使本文介绍使用 Jenkins 构建 SAE 应用的持续集成。 前提条件 在开始持续集成之前,需要完成下述的准备工作。 获取阿里云的 Access Key ID 和 Access Key Secret。 使用已经开通了 SAE 服务的主账号登录阿里云官网。 进入 Access Key 控制台,创建 Access Key ID 和 Access Key Secret。EDAS使用 Jenkins 创建持续集成01 在使用 Jenkins 自动部署应用之前,需要先在 SAE 控制台中创建一个可以部署的应用。 登录 SAE 控制台。 参考应用部署概述,部署应用。 在左侧导航栏中单击应用管理。找到您在上一步中创建的应用并单击进入详情页面,获取应用 ID 的字段内容。在SAE控制平台获取应用ID 使用 GitLab 托管您的代码。您可以自行搭建 Gitlab 或者使用阿里云 Code。 本文使用通过自行搭建的 GitLab 做演示,关于 Gitlab 的更多信息请参考 GitLab。 了解并使用 Jenkins。关于 Jenkins 的更多详细信息请参考 Jenkins 官网。 背景信息 使用 Jenkins 可以构建 SAE 应用的持续集成方案。该方案涉及下面的计算机语言或开发工具,阅读本文需要对下述的语言或工具有一定的理解。 工具 说明 Maven Maven 是一个项目管理和构建的自动化工具。 Jenkins Jenkins是一个可扩展的持续集成引擎。 GitLab GitLab是一个利用 Ruby on Rails 开发的开源应用程序,实现一个自托管的 Git 项目仓库,可通过 Web 界面进行访问公开的或者私人项目。 它拥有与 GitHub 类似的功能,能够浏览源代码,管理缺陷和注释。 配置项目 参考通过 toolkit-maven-plugin 插件自动化部署应用修改项目配置,添加 toolkit-maven-plugin 及部署信息。您在修改完项目配置后,建议在本地使用 Maven 构建验证配置是否正确。 安装和配置 Jenkins 进入 Jenkins 官网下载安装 Jenkins。 在 Jenkins 控制台的菜单栏中选择系统管理 > 插件管理,安装 Git 和 GitLab 插件。 安装 GIT Client Plugin 和 GIT Plugin 插件可以帮助 Jenkins 拉取 Git 仓库中的代码。 安装 Gitlab Hook Plugin 插件可以帮助 Jenkins 在收到 Gitlab 发来的 Hook 后触发一次构建。 安装和配置 Jenkins 安装 Maven 构建工具,请参见 Maven 官网。 在 Jenkins 控制台的菜单栏中选择系统管理 > 全局工具配置,选择 Maven 版本名称并配置路径。 Jenkins 控制台设置Maven 在 Jenkins 服务器上生成 SSH RSA 密钥对,并将公匙导入 GitLab,实现 Jenkins 拉取 GitLab 代码时自动认证。 参考 GitLab 文档,在 Jenkins 服务器运行 Jenkins 软件的用户下,生成 SSH RSA 密钥对。 EDAS在 Jenkins 服务器运行 Jenkins 软件的用户下,生成 SSH RSA 密钥对 进入 GitLab 首页,在菜单栏选择Settings > Deploy Keys ,并单击 new deploy key 添加 key,导入在Jenkins服务器上创建的SSH RSA公匙。 EDAS使用Jenkins在gitlab导公钥1EDAS使用Jenkins在gitlab导公钥2 创建 Jenkins 任务。 在 Jenkins 首页左侧导航栏中单击新建,创建 Jenkins 任务,并选择构建一个自由风格的软件项目。 EDAS使用Jenkins集成之创建项目 在 源码管理 页面中选择 Git,并设置相关参数。 Repository URL:您的项目的 Git 协议地址。 Credentials:安全凭证,选择无即可(前提是运行 Jenkins 软件的用户的 SSH RSA 公匙已添加到该 Git 项目所在的 GitLab 中,否则这里会报错)。 EDAS使用Jenkins集成之源码管理 单击构建触发器页签,勾选轮询 SCM。 单击构建环境页签,勾选 Add timestamps to the Console Output(为控制台输出的信息添加时间戳)。 单击构建页签,然后单击增加构建步骤。 在调用顶层 Maven 目标区域设置 Maven 版本和目标。如果您想部署多模块工程,请参见创建多模块工程的 Jenkins 任务。 Maven Version:单击该选项后面的下拉框,选择在全局工具配置里配置的 Maven 版本名称。 Goals:填入 clean package toolkit:deploy (如有其它参数,请根据实际情况填入) EDAS使用Jekins集成之调用顶层 Maven 目标 配置 Gitlab 的 Web Hook,实现自动构建 右键单击 GitLab 工程,然后选择 Setting > Web Hooks。 在 Web Hooks 页面的在 URL 文本框中输入http://jenkins服务器地址:jenkins服务器监听端口/git/notifyCommit?url=本项目的git协议地址 例如:http://123.57.57.164:8080/git/notifyCommit?url=git@code.aliyun.com:tdy218/hello-edas.git 配置 Gitlab 的 Web Hook,实现自动构建 图中表示的 Jenkins 服务器地址为您的 Jenkins 服务器的 Web 访问地址如 http://123.57.57.164:8080。 配置完成后,单击 Test Hook,进行测试。 配置 Gitlab 的 Web Hook结果 配置正确后,提交变更到 GitLab 如果上述步骤配置正确,这次提交会触发一次 GitLab Hook。 Jenkins 在接受到这个 Hook 后会构建您的 Maven 项目,并在构建结束时调用 SAE POP API 脚本触发部署。 提交部署成功输出的日志信息(Build Number > 控制台输出)。 15:58:51 [INFO] Deploy application successfully! 15:58:51 [INFO] ------------------------------------------------------------------------ 15:58:51 [INFO] BUILD SUCCESS 15:58:51 [INFO] ------------------------------------------------------------------------ 15:58:51 [INFO] Total time: 24.330 s 15:58:51 [INFO] Finished at: 2018-12-25T15:58:51+08:00 15:58:51 [INFO] Final Memory: 23M/443M 15:58:51 [INFO] ------------------------------------------------------------------------ 15:58:51 Finished: SUCCESS 如果部署失败,可以登录 SAE 控制台 ,在左侧导航栏中单击应用管理 > 应用列表 ,在应用列表页面单击具体应用名称,进入应用详情页面。在左侧导航栏单击变更记录来查看此次部署任务的执行过程。 创建多模块工程的 Jenkins 任务 创建多模块工程的 Jenkins 任务和安装和配置 Jenkins第 5 步基本相同,只需要调整下调用顶层 Maven 目标。如果工程为多模块工程,想在 Jenkins 中部署子模块的话,那么需要在父模块中调用 mvn clean install 命令,然后在子模块中调用 mvn clean package toolkit:deploy 命令。以 Demo 工程为例,工程结构如下: sh-3.2# tree -L 1 carshop carshop ├── detail ├── itemcenter ├── itemcenter-api └── pom.xml 其中,detail、itemcenter、itemcenter-api 为子模块,现在想部署 itemcenter 模块的话,那么需要在父工程中设置一个 clean install 构建目标,然后在 itemcenter 模块中设置 clean package toolkit:deploy 构建目标。 创建多模块工程的 Jenkins 任务
1934890530796658 2020-03-27 13:10:36 0 浏览量 回答数 0

回答

为保证 API 的安全调用,在调用 API 时阿里云会对每个 API 请求通过签名(Signature)进行身份验证。无论使用 HTTP 还是 HTTPS 协议提交请求,都需要在请求中包含签名信息。 概述 RPC API 要按以下格式在 API 请求的 Query 中增加签名(Signature)。 https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=xxxx%xxxx%3D&SignatureNonce=e7b1f31150be45594905ce6d28561286 其中: SignatureMethod:签名方式,目前支持 HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用 AccessKey Secret 对请求进行对称加密后生成的签名。 签名算法遵循 RFC 2104 HMAC-SHA1 规范,使用 AccessSecret 对编码、排序后的整个请求串计算 HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个 API 请求内容不同,所以签名的结果也不尽相同。可参考本文的操作步骤,计算签名值。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 步骤一:构造待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String)。 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature 参数)进行排序。 说明 当使用 GET 方法提交请求时,这些参数就是请求 URI 中的参数部分,即 URI 中”?“之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用 UTF-8 字符集进行 URL 编码。编码规则请参考下表。 字符 编码方式 A-Z、a-z 和 0-9 以及”-”、“_”、“.”和“~” 不编码。 其它字符 编码成 %XY 的格式,其中 XY 是字符对应 ASCII 码的 16 进制表示。例如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符 编码成 %XY%ZA…的格式。 英文空格 编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME 格式编码算法(例如 Java 标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的 HTTP 方法,例如 GET。 percentEncode(“/”) 是按照步骤 1.1 中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤 1 中构造的规范化请求字符串按步骤 1.2 中描述的 URL 编码规则编码后得到的字符串。 步骤二:计算签名值 按照 RFC2104 的定义,计算待签名字符串(StringToSign)的 HMAC 值。 说明 计算签名时使用的 Key 就是您持有的 AccessKey Secret 并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是 SHA1。 按照 Base64 编码规则把上面的 HMAC 值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为 Signature 参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照 RFC3986 的规则进行 URL 编码。 示例 以 Listinstances API 为例,假设使用的 AccessKey Id 为 testid, AccessKey Secret 为 testsecret。 签名前的请求 URL 如下: http://amqp-open.aliyuncs.com/?Timestamp=2020-02-11T06%3A00%3A10Z&Format=JSON&AccessKeyId=testid&Action=ListInstances&SignatureMethod=HMAC-SHA1&SignatureNonce=1e428a4d3e45bce88b2ed41cc34497eb&Version=2019-12-12&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: xtC1HBet6MjHTQVZLo%2Fbm4dlJ0s%3D 最后将签名作为 Signature 参数加入到 URL 请求中,最后得到的 URL 为: http://amqp-open.aliyuncs.com/?SignatureVersion=1.0&Action=ListInstances&Format=JSON&SignatureNonce=1e428a4d3e45b
保持可爱mmm 2020-03-28 20:35:40 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按如下格式在API请求的Query中增加签名(Signature): https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 计算签名 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of(StringToSign)) ) 完成以下操作,计算签名: 构建待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String): 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则如下: 对A-Z、a-z和0-9以及“-”、“_”、“.”和“~”不编码。 其它字符编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。比如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符,编码成 %XY%ZA…的格式。 英文空格要编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(比如 Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,比如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 计算签名 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以DescribeRegions API为例,假设使用的AccessKey ID 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://cityvisual.aliyuncs.com/?Timestamp=2019-08-01T12:46:24Z&Format=XML&AccessKeyId=testid&Action=DescribeRegions&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2018-10-30&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://cityvisual.aliyuncs.com/?SignatureVersion=1.0&Action=DescribeRegions&Format=XML&SignatureNonce=3ee8c1b
保持可爱mmm 2020-03-27 01:23:33 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按如下格式在API请求的Query中增加签名(Signature): https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 计算签名 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 完成以下操作,计算签名: 构建待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String): 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则如下: 字符 编码方式 A-Z、a-z和0-9以及“-”、“_”、“.”和“~” 不编码。 其它字符 编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。比如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符 编码成 %XY%ZA…的格式。 英文空格 编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(比如 Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,比如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 计算签名 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以DescribeRegionsAPI 为例,假设使用的AccessKey Id 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://ecs.aliyuncs.com/?Timestamp=2016-02-23T12:46:24Z&Format=XML&AccessKeyId=testid&Action=DescribeRegions&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2014-05-26&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://ecs.aliyuncs.com/?SignatureVersion=1.0&Action=DescribeRegions&Format=XML&SignatureNonce=3ee8c1b8-83d3-
1934890530796658 2020-03-25 14:54:13 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按如下格式在API请求的Query中增加签名(Signature): https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 计算签名 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 完成以下操作,计算签名: 构建待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String): 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则如下: 字符 编码方式 A-Z、a-z和0-9以及“-”、“_”、“.”和“~” 不编码。 其它字符 编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。比如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符 编码成 %XY%ZA…的格式。 英文空格 编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(比如 Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,比如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 计算签名 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以DescribeRegionsAPI 为例,假设使用的AccessKey Id 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://ecs.aliyuncs.com/?Timestamp=2016-02-23T12:46:24Z&Format=XML&AccessKeyId=testid&Action=DescribeRegions&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2014-05-26&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://ecs.aliyuncs.com/?SignatureVersion=1.0&Action=DescribeRegions&Format=XML&SignatureNonce=3ee8c1b8-83d3-44af-a
保持可爱mmm 2020-03-28 23:52:14 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按如下格式在API请求的Query中增加签名(Signature): https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 计算签名 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 完成以下操作,计算签名: 构建待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String): 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则如下: 字符 编码方式 A-Z、a-z和0-9以及“-”、“_”、“.”和“~” 不编码。 其它字符 编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。比如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符 编码成 %XY%ZA…的格式。 英文空格 编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(比如 Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,比如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 计算签名 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以DescribeRegionsAPI 为例,假设使用的AccessKey Id 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://ecs.aliyuncs.com/?Timestamp=2016-02-23T12:46:24Z&Format=XML&AccessKeyId=testid&Action=DescribeRegions&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2014-05-26&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://ecs.aliyuncs.com/?SignatureVersion=1.0&Action=DescribeRegions&Format=XML&SignatureNonce=3ee8c1b8-83d3-4
保持可爱mmm 2020-03-27 19:27:43 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按如下格式在API请求的Query中增加签名(Signature): https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 计算签名 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 完成以下操作,计算签名: 构建待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String): 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则如下: 对A-Z、a-z和0-9以及“-”、“_”、“.”和“~”不编码。 其它字符编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。比如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符,编码成 %XY%ZA…的格式。 英文空格要编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(比如 Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,比如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 计算签名 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以DescribeFabricOrganization API 为例,假设使用的AccessKey ID 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://baas.aliyuncs.com/?Action=DescribeFabricOrganization&Timestamp=2018-12-23T12:46:24Z&Format=XML&AccessKeyId=testid&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2018-12-21&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://baas.aliyuncs.com/?Action=DescribeFabricOrganization&Timestamp=2018-12-23T12:46:24Z&Format=XML&AccessKeyId=testid&
保持可爱mmm 2020-03-26 20:13:46 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按如下格式在API请求的Query中增加签名(Signature): https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 计算签名 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 完成以下操作,计算签名: 构建待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String): 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则如下: 字符 编码方式 A-Z、a-z和0-9以及“-”、“_”、“.”和“~” 不编码。 其它字符 编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。比如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符 编码成 %XY%ZA…的格式。 英文空格 编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(比如 Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,比如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 计算签名 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以DescribeRegionsAPI 为例,假设使用的AccessKey Id 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://ecs.aliyuncs.com/?Timestamp=2016-02-23T12:46:24Z&Format=XML&AccessKeyId=testid&Action=DescribeRegions&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2014-05-26&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://ecs.aliyuncs.com/?SignatureVersion=1.0&Action=DescribeRegions&Format=XML&SignatureNonce=3ee8c1b8-83d3-44af-
保持可爱mmm 2020-03-27 19:31:31 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按以下格式在API请求的Query中增加签名(Signature)。 https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。可参考本文的操作步骤,计算签名值。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 步骤一:构造待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String)。 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 说明 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则请参考下表。 字符 编码方式 A-Z、a-z和0-9以及“-”、“_”、“.”和“~” 不编码。 其它字符 编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。例如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符 编码成 %XY%ZA…的格式。 英文空格 编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(例如Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,例如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 步骤二:计算签名值 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以QueryPhoneNumberAttributeAPI 为例,假设使用的AccessKey Id 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://dytnsapi.aliyuncs.com/?Timestamp=2016-02-23T12%3A46:24Z&Format=XML&AccessKeyId=testid&Action=QueryPhoneNumberAttribute&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2020-02-17&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://dytnsapi.aliyuncs.com/?SignatureVersion=1.0&Action=QueryPhoneNumberAttribute&Format=XML&SignatureNonce=3ee8c1b8
保持可爱mmm 2020-03-27 00:01:18 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按如下格式在API请求的Query中增加签名(Signature): https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。可参考本文的操作步骤,计算签名值。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of(StringToSign) ) ) 步骤一:构造待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String)。 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 说明 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则请参考下表。 字符 编码方式 A-Z、a-z和0-9以及“-”、“_”、“.”和“~” 不编码。 其它字符 编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。例如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符 编码成 %XY%ZA…的格式。 英文空格 编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(例如Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,例如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 步骤二:计算签名值 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以CreateIntentAPI 为例,假设使用的AccessKey Id 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://outboundbot.cn-shanghai.aliyuncs.com/?Timestamp=2016-02-23T12%3A46:24Z&Format=XML&AccessKeyId=testid&Action=CreateIntent&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2019-12-26&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://outboundbot.cn-shanghai.aliyuncs.com/?SignatureVersion=1.0&Action=CreateIntent&Format=XML&SignatureNonce=3ee8c
保持可爱mmm 2020-03-26 18:45:07 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按以下格式在API请求的Query中增加签名(Signature)。 https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。可参考本文的操作步骤,计算签名值。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of( StringToSign)) ) 步骤一:构造待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String)。 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 说明 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则请参考下表。 字符 编码方式 A-Z、a-z和0-9以及“-”、“_”、“.”和“~” 不编码。 其它字符 编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。例如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符 编码成 %XY%ZA…的格式。 英文空格 编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(例如Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,例如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 步骤二:计算签名值 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以DescribeRegionsAPI 为例,假设使用的AccessKey Id 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://ecs.aliyuncs.com/?Timestamp=2016-02-23T12%3A46:24Z&Format=XML&AccessKeyId=testid&Action=DescribeRegions&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2014-05-26&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://ecs.aliyuncs.com/?SignatureVersion=1.0&Action=DescribeRegions&Format=XML&SignatureNonce=3ee8c1b8-83d3-44a
保持可爱mmm 2020-03-27 18:58:11 0 浏览量 回答数 0

回答

四层负载均衡采用开源软件LVS(Linux Virtual Server)+ Keepalived的方式实现负载均衡,七层负载均衡由Tengine实现。 压力测试性能概述 四层监听经过LVS后直接到达后端服务器,而七层监听经过LVS后,还需要再经过Tengine,最后到达后端服务器。七层比四层多了一个处理环节,因此,七层性能没有四层性能好。 如果您使用七层监听进行压力测试,发现压测性能比较低。挂了两台ECS的七层负载均衡监听性能还不如挂了一台ECS的四层负载均衡监听性能,除了七层本身的性能比四层低外,以下情况也可能会造成七层压测性能低: 客户端端口不足 。 在进行压力测试时,客户端端口不足会导致建立连接失败。负载均衡会默认抹除TCP连接的timestamp属性,Linux协议栈的tw_reuse(time_wait 状态连接复用)无法生效,time_wait状态连接堆积导致客户端端口不足。 解决方法:客户端使用长连接代替短连接。使用RST报文断开连接,即socket设置SO_LINGER属性。 后端服务器accept队列满 。 后端服务器accept队列满,导致后端服务器不回复syn_ack报文,客户端超时。 解决方法:默认net.core.somaxconn的值为128,执行sysctl -w net.core.somaxconn=1024命令更改net.core.somaxconn的值,并重启后端服务器上的应用。 后端服务器连接过多。 由于架构设计的原因,使用七层负载均衡时,用户长连接经过Tengine后变成短连接,可能导致后端服务器连接过多,从而表现为压测性能低。 后端服务器依赖的应用成为瓶颈。 请求经过负载均衡到达后端服务器后,后端服务器本身负载正常,但由于所有的后端服务器上的应用又依赖其它应用,例如数据库,当数据库成为瓶颈时,也会引起性能降低。 后端服务器的健康检查状态异常。 在压测时,容易忽略后端服务器的健康检查状态,如果有后端服务器健康检查失败或者健康检查状态经常跳跃(好到坏,又从坏到好,反复变化),也会导致压测性能低。 压力测试建议 在进行压力测试时,请注意如下配置: 压测负载均衡转发能力建议使用短连接 。 一般来说压测除了验证会话保持和均衡性等功能外,主要想验证负载均衡的转发能力,因此使用短连接比较合适,用于测试负载均衡和后端服务器的处理能力。使用短连接测试时,需要注意客户端端口不足的问题。 压测负载均衡吞吐量建议使用长连接,用于测试带宽上限或特殊业务。 压测工具的超时时间建议设置为一个较小值,如5秒。超时时间太大的话,测试结果会体现在平均响应时间加长,不利于判断压测水位是否已到达。超时时间调小,测试结果会体现在成功率上,便于快速判断压测水位。 后端服务器提供一个静态网页用于压测,以避免应用逻辑带来的损耗。 压测时,监听配置建议如下: 不开启会话保持功能,否则压力会集中在个别后端服务器。 关闭健康检查功能,减少健康检查对后端服务器的访问请求。 性能测试服务的5000并发规格能够提供5个及5个以上的公网IP。 压力测试工具建议 不建议您使用Apache ab作为压力测试工具。 Apache ab在大量并发场景下存在3s、6s、9s阶梯式停顿的现象。Apache ab会通过判断content length来确定请求是否成功,而负载均衡挂载多台后端服务器时,返回的content length会不一致,导致测试结果有误。 建议使用阿里云PTS。 可以设置足够高的并发,PTS会分配来自全国各地的公网IP,压力来源足够分散,并且可以在PTS中集成云监控,实时查看端到端的全部性能数据。 使用PTS简单压测示例 创建一个负载均实例,添加两台ECS实例作为后端服务器,分别创建一个TCP监听和HTTP监听,后端端口设置为80。ECS服务器的配置为CPU 1核,内存512M使用CentOS 6.3 64位的操作系统。 安装Apache Web Server提供Web服务。 yum install -y httpd 初始化默认首页index.html。 echo "testvm" > /var/www/html/index.html 启动HTTP服务。 service httpd start 访问本地的80端口,确认Web服务可用。 curl localhost 在PTS中创建测试场景,开始压力测试。
保持可爱mmm 2020-03-29 11:52:22 0 浏览量 回答数 0

回答

为保证API的安全调用,在调用API时阿里云会对每个API请求通过签名(Signature)进行身份验证。无论使用HTTP还是HTTPS协议提交请求,都需要在请求中包含签名信息。 概述 RPC API要按以下格式在API请求的Query中增加签名(Signature)。 https://Endpoint/?SignatureVersion=1.0&SignatureMethod=HMAC-SHA1&Signature=CT9X0VtwR86fNWSnsc6v8YGOjuE%3D&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf 其中: SignatureMethod:签名方式,目前支持HMAC-SHA1。 SignatureVersion:签名算法版本,目前版本是 1.0。 SignatureNonce:唯一随机数,用于防止网络重放攻击。用户在不同请求间要使用不同的随机数值,建议使用通用唯一识别码(Universally Unique Identifier, UUID)。 Signature: 使用AccessKey Secret对请求进行对称加密后生成的签名。 签名算法遵循RFC 2104 HMAC-SHA1规范,使用AccessSecret对编码、排序后的整个请求串计算HMAC值作为签名。签名的元素是请求自身的一些参数,由于每个API请求内容不同,所以签名的结果也不尽相同。可参考本文的操作步骤,计算签名值。 Signature = Base64( HMAC-SHA1( AccessSecret, UTF-8-Encoding-Of(StringToSign) ) ) 步骤一:构造待签名字符串 使用请求参数构造规范化的请求字符串(Canonicalized Query String)。 按照参数名称的字典顺序对请求中所有的请求参数(包括公共请求参数和接口的自定义参数,但不包括公共请求参数中的Signature参数)进行排序。 说明 当使用GET方法提交请求时,这些参数就是请求URI中的参数部分,即URI中“?”之后由“&”连接的部分。 对排序之后的请求参数的名称和值分别用UTF-8字符集进行URL编码。编码规则请参考下表。 字符 编码方式 A-Z、a-z和0-9以及“-”、“_”、“.”和“~” 不编码。 其它字符 编码成 %XY 的格式,其中 XY 是字符对应ASCII码的16进制表示。例如英文的双引号(””)对应的编码为 %22。 扩展的UTF-8字符 编码成 %XY%ZA…的格式。 英文空格 编码成 %20,而不是加号(+)。 该编码方式和一般采用的 application/x-www-form-urlencoded MIME格式编码算法(例如Java标准库中的 java.net.URLEncoder的实现)存在区别。编码时可以先用标准库的方式进行编码,然后把编码后的字符串中的加号(+)替换成 %20,星号(*)替换成 %2A,%7E替换回波浪号(~),即可得到上述规则描述的编码字符串。本算法可以用下面的percentEncode方法来实现: private static final String ENCODING = "UTF-8"; private static String percentEncode(String value) throws UnsupportedEncodingException { return value != null ? URLEncoder.encode(value, ENCODING).replace("+", "%20").replace("*", "%2A").replace("%7E", "~") : null; } 将编码后的参数名称和值用英文等号(=)进行连接。 将等号连接得到的参数组合按步骤 i 排好的顺序依次使用“&”符号连接,即得到规范化请求字符串。 将第一步构造的规范化字符串按照下面的规则构造成待签名的字符串。 StringToSign= HTTPMethod + “&” + percentEncode(“/”) + ”&” + percentEncode(CanonicalizedQueryString) 其中: HTTPMethod 是提交请求用的HTTP方法,例如GET。 percentEncode(“/”) 是按照步骤1.1中描述的 URL 编码规则对字符 “/” 进行编码得到的值,即 %2F。 percentEncode(CanonicalizedQueryString) 是对步骤1中构造的规范化请求字符串按步骤 1.2 中描述的URL编码规则编码后得到的字符串。 步骤二:计算签名值 按照RFC2104的定义,计算待签名字符串(StringToSign)的HMAC值。 说明 计算签名时使用的Key就是您持有的AccessKey Secret并加上一个 “&” 字符(ASCII:38), 使用的哈希算法是SHA1。 按照Base64编码规则把上面的HMAC值编码成字符串,即得到签名值(Signature)。 将得到的签名值作为Signature参数添加到请求参数中。 说明 得到的签名值在作为最后的请求参数值提交时要和其它参数一样,按照RFC3986的规则进行URL编码。 示例 以BeginDialogueAPI 为例,假设使用的AccessKey Id 为 testid, AccessKey Secret为testsecret。 签名前的请求URL如下: http://voicenavigator.cn-shanghai.aliyuncs.com/?Timestamp=2016-02-23T12%3A46:24Z&Format=XML&AccessKeyId=testid&Action=BeginDialogue&SignatureMethod=HMAC-SHA1&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2018-06-12&SignatureVersion=1.0 使用testsecret&,计算得到的签名值是: OLeaidS1JvxuMvnyHOwuJ+uX5qY= 最后将签名作为Signature参数加入到URL请求中,最后得到的URL为: http://voicenavigator.cn-shanghai.aliyuncs.com/?SignatureVersion=1.0&Action=BeginDialogue&Format=XML&SignatureNonce=3ee8c1b8-83d3-44af-a94f-4e0ad82fd6cf&Version=2018-06-12&AccessKeyId=testid&Signature=OLeaidS1JvxuMvnyHOwuJ+uX5qY=&SignatureMethod=HMAC-SHA1&Timestamp=2016-02-23T12%3A46%3A24Z 上
保持可爱mmm 2020-03-26 17:12:10 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT