未找到结果
我们无法找到任何使用该词的内容,请尝试搜索其他内容。
内容简介 游戏内资源包括玩家的装备/弹药/材料等素材,对游戏内资源的发布和更新是游戏运营商的一个常规业务流程,使用频率会十分高,所以游戏运营商希望该流程可以做到简化和可控。针对这个需求,我们设计了 3 个架构,面向游戏内资源更新发布的 3 个典型场景,来优化游戏内资源更新发布流程。3 个场景分别为
游戏内资源包括玩家的装备/弹药/材料等素材,对游戏内资源的发布和更新是游戏运营商的一个常规业务流程,使用频率会十分高,所以游戏运营商希望该流程可以做到简化和可控。针对这个需求,我们设计了 3 个架构,面向游戏内资源更新发布的 3 个典型场景,来优化游戏内资源更新发布流程。3 个场景分别为:
该 3 个架构围绕亚马逊云科技 CloudFront 服务 — CloudFront 边缘计算服务 — WAF 服务展开实现。
游戏在运营过程中会有资源更新的需求,用一个简单模型来描述:老的资源 A 需要替换成成新的资源 B。不过这里有一个痛点,B 资源在推广到所有 CDN 之前,需要内部或者小范围确认资源的正确性。因此需要一种方式来保证 B 资源哪怕在源端更新了,只有受限的访问;大部分的玩家还是访问的还是 CDN 缓存内的资源 A。等 B 资源验证通过后,才会通过 CDN 刷新推广到所有的节点。
这个需求实现的难点在于:在客户端不做任何修改的情况下,使用相同的 URL 将少量用户请求引导资源 B;资源 A 和资源 B 不能共享缓存,以免引起资源访问冲突。我们采用 CloudFront Continuous Deployment 来实现这个需求:
配置步骤如下 :
CloudFront 持续部署功能在实现上比较直观,用户可以通过控制请求配比方式实现金丝雀式的资源更新;在成本上相比于部署 CloudFront 边缘脚本 CloudFront Function 会更低一些 。
* 注意:我们在新的 origin 中改写了 origin path,使得客户端无需做变更 。
可以使用命令行工具 curl 进行验证:
resource_b 下载:
curl -H 'aws-cf-cd-resource:b' -v -o /dev/null 'https://www.company.com/resource'
resource_a 下载 :
curl -h -v -o /dev / null ' https://www.company.com/resource '
通过观察下载的文件特征如字节数或者 ETAG 判断是否下载了不同内容的资源对象 。
用户在源站正式将 Resource B 覆盖 Resource A 后,需要在 CloudFront 上进行缓存刷新,并删除 staging distribution
游戏在运营过程中会有针对不同渠道投放不同资源的需求,用一个简单模型描述:对于资源 A 和资源 B,从不同渠道进来的玩家会看到不同的资源。这里的痛点为,客户需要针对头部某个字段或者 url 中某个关键字快速匹配对应的资源。
在这个方案构建中,我们将利用到 is Rewrite CloudFront Function 检查请求头部的字段,并根据匹配到的字段进行回源 URL Path 替换,此方案的好处在于,url Path is Rewrite rewrite 对于最终用户是无感知的,符合不同渠道进来的玩家对于某个相同的资源(比如资源 a),回源获取到的内容将会不同 。
配置步骤如下 :
在此需求中,不同渠道的所获取的内容不同,意味着在源站侧(如 S3)上的路径信息不同,如用户请求的文件路径统一为/sample.file,而不同渠道在源服务上所对应的文件真实路径为/a_vendor/sapme.file 或是/b_vendor/sample.file,我们可以根据不同渠道(携带不同的请求头信息),来对请求头值进行提取,并进行回源 URL 替换,具体 CloudFront Function 参考代码如下:
function handler(event) {
// 获取请求头
var request = event.request;
var headers = event.request.headers;
var originUrl = event.request.uri;
// 检查 x-vendor-type 请求头是否存在
if (headers['x-vendor-type']) {
var targetObject = headers['x-vendor-type'].value
//修改回源 URL Path
event.request.uri = '/' + targetObject + originUrl;
}
return request;
}
*注:此处 header 的值不直接取而是先进行判断的原因是,某些客户端可能不会携带 x-vendor-type 这个头,如果不增加判断直接取值,那么 header 不存在的情况将会导致 CloudFront Function 报错,在您部署代码时也可以进行相应的考虑。
CloudFront Function 代码保存完毕后,我们可以在调试界面进行调试并观察效果:
提交调试信息后,可以看到回源路径成功被修改,如下图:
调试无误后对 CloudFront 代码进行部署:
此处,为了方便展示效果,我们在 CloudFront 中的 Behavior 根据需求,进行路径匹配,此处的匹配以“/abtest-demo*”进行展示。
由于此处仅做 URL 改写,不同渠道针对相同 URL 将会拿到不同的内容,此处您还需要在 Behavior 中针对不同的请求头进行缓存上的区分,您可以自定义 Cache Policy,并将 x-vendor-object 请求头作为 Cache Key 的一部分,以进行缓存区分:
自定义 Cache Policy 后,在 Behavior 中进行应用:
在 origin policy 中,需要将自定义的请求头进行透传,以便 CloudFront Function 可以进行请求头的检查,您可以自定义 Origin Policy,也可以选择 AllViewer 将自定义请求头进行透传 。
由于该改写逻辑运行的 event type 是 Viewer Request,您需要在 Behavior 定义中在正确的 event 中应用上述部署的 CloudFront Function 逻辑。
在源服务侧,我们分别针对 A 和 B 渠道存放不同版本的文件,以供调试,此处示例文件对应关系如下:
渠道 A :a_vendor
渠道 B : b_vendor
携带对应的请求头,多次请求后并观测效果:
//在请求头中携带 A 渠道特殊标识,回源真实路径为/a_vendor/example.file
% curl -v http://cloudfront-function.xxxxxxx.com/example.file -H 'x-vendor-type: a_vendor' 2>&1 | egrep 'X-Cache|This content'
< X-Cache: Hit from cloudfront
This content is for a vendor!
//在请求头中携带 B 渠道特殊标识,回源真实路径为/a_vendor/example.file
% curl -v http://cloudfront-function.xxxxxxx.com/example.file -H 'x-vendor-type: b_vendor' 2>&1 | egrep 'X-Cache|This content'
< X-Cache: Hit from cloudfront
This content is for b vendor!
//在请求头中不携带渠道特殊标识,回源真实路径为/example.file
% curl -v http://cloudfront-function.xxxxxxx.com/example.file 2>&1 | egrep 'X-Cache|This content'
< X-Cache: Hit from cloudfront
This content is for general usage without vendor!
通过以上的演示,我们成功的验证了以下三个设置需求:
游戏在运营过程中会有不同玩家有不同访问行为的需求,用一个简单模型描述:对于玩家 A 需要放在白名单中,对于玩家 B 需要放置在黑名单中。
用一个更具体的场景描述:假设需要通过 WAF web ACL 去匹配出 user-agent 中包含 “PostmanRuntime/x.xx.x” 的请求,并且拒绝该请求的访问。
对于上述场景,可以通过检查请求 header 重的 User-Agent 来实现。对于请求来说,通常会经过几个链路:客户端→公网→ AWS CDN 接入点→ 原站。那么将检查 header 的压力放在 CDN 处是比较好的选择,可以有效的减少原站的压力。在 CDN 侧检测也有几种方式。最先想到的是在 CDN 上用 edge function/lambda 来实现。这里会带来的挑战是需要是维护代码。另外一种比较好的方式是利用 WAF 对于规则来进行检查。WAF 在配置 Web ACL 的时候,需要配置允许和阻止的条件。通常包含的条件有:
默认情况下,aw WAF is 过滤器不检查 过滤器不检查 HTTP 请求参数是否存在。要检查 HTTP 请求参数是否存在,可以采取下面两种自定义规则中的任意一种 :
在测试之前我们需要做如下步骤:
对于字符串匹配规则,Web ACL 提供如下几种方式:
根据需求,使用 Start with string 即可,设置如下:
正则表达式规则,Web ACL 提供两种匹配方式:
这里我们选择第二种方式,其设置参考如下
{
"Name": "StringMatch",
"Priority": 0,
"Action": {
"Block": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "StringMatch"
},
"Statement": {
"OrStatement": {
"Statements": [
{
"ByteMatchStatement": {
"FieldToMatch": {
"Headers": {
"MatchScope": "ALL",
"MatchPattern": {
"All": {}
},
"OversizeHandling": "CONTINUE"
}
},
"PositionalConstraint": "STARTS_WITH",
"SearchString": "PostmanRuntime",
"TextTransformations": [
{
"Type": "NONE",
"Priority": 0
}
]
}
},
{
"RegexMatchStatement": {
"FieldToMatch": {
"Headers": {
"MatchScope": "ALL",
"MatchPattern": {
"All": {}
},
"OversizeHandling": "CONTINUE"
}
},
"TextTransformations": [
{
"Type": "NONE",
"Priority": 0
}
],
"RegexString": "/PostmanRuntime[ \\/]+([0-9\\.]+)/gi"
}
}
]
}
}
}
规则建立好后,我们需要将它运用在保护的资源中。假设源站是一个网站,前面为一个 CDN,它只是返回一个 text = ok 。
测试如下(User-Agent 的值为 X-UnrealEngine-Agent):
当请求头,包含了 PostmanRuntime / x.xx.x,可以看到请求被 block
在后台的界面中,也可以统计到过去 5 分钟的 WAF 的表现情况
可以通过以上实验,WAF 对于 CDN 的保护提供了十分灵活的配置规则,可以满足各种不同场景的需求。更进一步,它解放了 CDN 去做规则匹配和检查的压力,让 CDN 去做它更擅长的业务 。
通过亚马逊云科技 CloudFront 服务 — CloudFront 边缘计算服务 — WAF 服务,游戏运营商可以在不改动客户端的情况下,完成游戏内资源在预设条件下的更新发布,提高了业务部署的敏捷性和简易性 。
Amazon CloudFront 部署小指南(一)- 快速构建 CDN 内容分发:https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-one/
Amazon CloudFront 部署小指南 (二)- 进阶部署:https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-two/
Amazon CloudFront 部署小指南 (三)- 持续部署:https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-three/
Amazon CloudFront 部署小指南(四)- CloudFront Function 基础与诊断:https://aws.amazon.com / cn / blog / china / amazon – cloudfront – deployment – handbook – part – four/
Amazon CloudFront 部署小指南(六)- Lambda@Edge 基础与诊断:https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-six/
Amazon CloudFront 部署小指南(七)- 使用 CloudFront Function 模板加 EchoServer 进行快速调试:https://aws.amazon.com/cn/blogs/china/quick-debugging-using-cloudfront-function-templates-and-echoserver/
Amazon CloudFront 部署小指南(八)- 使用中国区 CloudFront 及 CloudFront SSL 插件部署免费证书:https://aws.amazon.com/cn/blogs/china/divert-website-access-traffic-from-ec2-to-amazon-cloudfront/