网站建设现状调查研究,苏州网页制作免费,网页特效,株洲做网站 省心磐石网络内容简介 游戏内资源包括玩家的装备/弹药/材料等素材#xff0c;对游戏内资源的发布和更新是游戏运营商的一个常规业务流程#xff0c;使用频率会十分高#xff0c;所以游戏运营商希望该流程可以做到简化和可控。针对这个需求#xff0c;我们设计了 3 个架构#xff0c;面… 内容简介 游戏内资源包括玩家的装备/弹药/材料等素材对游戏内资源的发布和更新是游戏运营商的一个常规业务流程使用频率会十分高所以游戏运营商希望该流程可以做到简化和可控。针对这个需求我们设计了 3 个架构面向游戏内资源更新发布的 3 个典型场景来优化游戏内资源更新发布流程。3 个场景分别为 游戏内资源灰度更新游戏内资源分渠道投放游戏内资源黑白名单 该 3 个架构围绕亚马逊云科技 Amazon CloudFront 服务 — CloudFront 边缘计算服务 — WAF 服务展开实现。 场景一游戏内资源灰度更新 游戏在运营过程中会有资源更新的需求用一个简单模型来描述老的资源 A 需要替换成成新的资源 B。不过这里有一个痛点B 资源在推广到所有 CDN 之前需要内部或者小范围确认资源的正确性。因此需要一种方式来保证 B 资源哪怕在源端更新了只有受限的访问大部分的玩家还是访问的还是 CDN 缓存内的资源 A。等 B 资源验证通过后才会通过 CDN 刷新推广到所有的节点。 这个需求实现的难点在于在客户端不做任何修改的情况下使用相同的 URL 将少量用户请求引导资源 B资源 A 和资源 B 不能共享缓存以免引起资源访问冲突。我们采用 CloudFront Continuous Deployment 来实现这个需求 配置步骤如下 创建 Staging Distribution功能验证调度流量正式上线 CloudFront 持续部署功能在实现上比较直观用户可以通过控制请求配比方式实现金丝雀式的资源更新在成本上相比于部署 CloudFront 边缘脚本 CloudFront Function 会更低一些。 创建 Staging Distribution ▪ 在 CloudFront 生产 distribution 下点击“create staging distribution” ▪ 可以输入 Staging Distribution 的描述然后点击“Next” ▪ 创建一个新的源站。用户可以对应创建一个新的源站部署资源 B使用相同目录结构也可以在现有源站上将资源 B 部署到另外一个目录中然后创建新的 Host 容器并且在 DNS 服务器上创建指向新的 Host 容器的记录 *注意我们在新的 origin 中改写了 origin path使得客户端无需做变更。 ▪ 流量配置选择“header-based ”比例先选择为 0 ▪ 创建 Staging Distribution ▪ 至此 Staging Distribution 创建完毕等待 10 分钟左右部署完毕 功能验证 可以使用命令行工具 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 判断是否下载了不同内容的资源对象。 调度流量 ▪ 点击‘Edit Policy’ ▪ 在弹出窗口中修改流量调度策略调度 1%的流量进行灰度发布 正式上线 用户在源站正式将 Resource B 覆盖 Resource A 后需要在 CloudFront 上进行缓存刷新并删除 Staging Distribution 场景二游戏内资源分渠道投放 游戏在运营过程中会有针对不同渠道投放不同资源的需求用一个简单模型描述对于资源 A 和资源 B从不同渠道进来的玩家会看到不同的资源。这里的痛点为客户需要针对头部某个字段或者 url 中某个关键字快速匹配对应的资源。 内容概述 在这个方案构建中我们将利用到 CloudFront Function 检查请求头部的字段并根据匹配到的字段进行回源 URL Path 替换此方案的好处在于URL Path Rewrite 对于最终用户是无感知的符合不同渠道进来的玩家对于某个相同的资源比如资源 A回源获取到的内容将会不同。 配置步骤如下 创建 CloudFront Function创建 Behavior 匹配存在不同渠道的 URL Path实验验证及结论 创建 CloudFront Function 在此需求中不同渠道的所获取的内容不同意味着在源站侧如 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 代码进行部署 创建 Behavior 匹配 存在不同渠道的 URL Path 此处为了方便展示效果我们在 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 21 | egrep X-Cache|This contentX-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 21 | egrep X-Cache|This contentX-Cache: Hit from cloudfront
This content is for b vendor!//在请求头中不携带渠道特殊标识回源真实路径为/example.file
% curl -v http://cloudfront-function.xxxxxxx.com/example.file 21 | egrep X-Cache|This content X-Cache: Hit from cloudfront
This content is for general usage without vendor! 左滑查看更多 通过以上的演示我们成功的验证了以下三个设置需求 您可以清楚的看到针对相同的 URL path 为/example.file通过不同的 x-vendor-type 指定内容我们成功的改写了回源 URL并根据获取到了不同渠道所对应的内容。如果客户端不是通过渠道发起的请求不携带特殊标识头也可以成功拿到内容。在命中缓存的情况下由于 Cache Policy 将 x-vendor-type 作为缓存的一部分在 URL 相同的情况下请求依然可以按照预期命中到各自对应缓存。 场景三游戏内资源黑白名单 场景描述 游戏在运营过程中会有不同玩家有不同访问行为的需求用一个简单模型描述对于玩家 A 需要放在白名单中对于玩家 B 需要放置在黑名单中。 用一个更具体的场景描述假设需要通过 WAF web ACL 去匹配出 user-agent 中包含 “PostmanRuntime/x.xx.x” 的请求并且拒绝该请求的访问。 对于上述场景可以通过检查请求 header 重的 User-Agent 来实现。对于请求来说通常会经过几个链路客户端→公网→Amazon CDN 接入点→ 原站。那么将检查 header 的压力放在 CDN 处是比较好的选择可以有效的减少原站的压力。在 CDN 侧检测也有几种方式。最先想到的是在 CDN 上用 edge function/lambda 来实现。这里会带来的挑战是需要是维护代码。另外一种比较好的方式是利用 WAF 对于规则来进行检查。WAF 在配置 Web ACL 的时候需要配置允许和阻止的条件。通常包含的条件有 请求是否表现为包含恶意脚本允许或阻止请求 → 跨站点脚本匹配条件请求源自的 IP 地址允许或阻止请求 →IP 匹配条件请求源自的国家/地区允许或阻止请求 → 地理匹配条件请求是否超过指定长度允许或阻止请求 → 大小约束条件请求是否表现为包含恶意 SQL 代码允许或阻止请求 →SQL 注入匹配条件出现在请求中的字符串允许或阻止请求 →字符串匹配条件出现在请求中的正则表达式模式允许或阻止请求 → 正则表达式匹配条件 默认情况下Amazon WAF 过滤器不检查 HTTP 请求参数是否存在。要检查 HTTP 请求参数是否存在可以采取下面两种自定义规则中的任意一种 使用字符串匹配规则使用正则表达式匹配规则 环境准备 在测试之前我们需要做如下步骤 1. 进入 Amazon Website Service Console 界面选择 WAF 服务然后在左边导航栏选择 WAF ACLs。 2. 创建一个 Rule根据业务需求命名。然后保护的对象可以是 CDN 也可以是负载均衡器之类的对外服务。资源部分可以现在就填写也可以等待 Rule 创建完毕后再绑定。 3. 完成 Web ACL 的信息录入之后在第二部我们选择自定义规则。 4. 在自定义规则中我们选择 Rule Builder。并且设置好 Rule 的名字。 5. 在 inspect 中选择 All headersheader content 选择默认的所有 keys and values当然可以根据业务需求只监控特定的 header 和 content。 字符串匹配规则 对于字符串匹配规则Web ACL 提供如下几种方式 Exact matches string严格匹配字符串Start swith string匹配字符串开头Ends with string匹配字符串结尾Contains string/word包含某个字符串 根据需求使用 Start with string 即可设置如下: 正确表达式匹配规则 正则表达式规则Web ACL 提供两种匹配方式 ▪ regex pattern set正则表达式集合可以提前设置在面板中选取即可 ▪ regular expression正则表达式临时设置 这里我们选择第二种方式其设置参考如下 最终规则的 Json 格式参考 {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它只是返回一个 textok。 测试如下User-Agent 的值为 X-UnrealEngine-Agent 当请求头包含了 PostmanRuntime/x.xx.x可以看到请求被 block 在后台的界面中也可以统计到过去 5 分钟的 WAF 的表现情况 可以通过以上实验WAF 对于 CDN 的保护提供了十分灵活的配置规则可以满足各种不同场景的需求。更进一步它解放了 CDN 去做规则匹配和检查的压力让 CDN 去做它更擅长的业务。 总结 通过亚马逊云科技 CloudFront 服务 — CloudFront 边缘计算服务 — WAF 服务游戏运营商可以在不改动客户端的情况下完成游戏内资源在预设条件下的更新发布提高了业务部署的敏捷性和简易性。 亚马逊云科技 CloudFront 部署小指南系列文章 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/blogs/china/amazon-cloudfront-deployment-handbook-part-four/ Amazon CloudFront 部署小指南六- LambdaEdge 基础与诊断 https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-six/ 本篇作者 叶明 亚马逊云科技边缘产品架构师负责 CloudFront 和 Global Accelerator 服务在中国和全球的市场拓展专注于互联网用户访问云上服务的感受的优化以及数据洞察。在互联网基础设施领域有丰富的实践经验。 万曦 亚马逊云科技解决方案架构师负责基于亚马逊云科技的云计算方案的咨询和架构设计。坚实的 Amazon Builder 文化拥抱者。拥有超过 12 年的游戏研发经验参与过数个游戏项目的管理和开发对于游戏行业有深度理解和见解。 王骏兴 亚马逊云科技边缘产品架构师负责亚马逊云科技 Edge 服务领域在中国的技术推广。在 CDN 内容分发以及 WAF 领域拥有多年实战经验专注于边缘服务设计以及体验优化。 听说点完下面4个按钮 就不会碰到bug了
