最近需要填坑处理原来海外的天坑, 基本上处理掉前期的比较基础部分, 还缺少部分估计也是要消耗不少时间处理.
按照目前的节奏针对现有问题做好分类规划:
- 抽离单独的支付平台(已完成, 待优化)
- 构建海外游戏发行平台(已完成, 待优化)
- 游戏业务SDK中心(已完成, 待优化)
- 整合后台管理中心(未完成, 更新中)
因为引入现代 composer 依赖, 所以避免很多问题只能从头做起, 开发效率上面也比较快;
但是中间很多问题都没有做细致处理优化, 后续对于已完成的项目要调整优化下.
支付平台
支付平台最好是单独抽离出做个中心服务, 除非万不得已不要把服务放置整合在一起; 这部分带来的影响很大, 因为作为发行中心的流量本身很巨大, 有时候简单的 php 任务进程可能没办法即时响应.
并且支付系统是带有定时回调处理( notify ), 如果整合成单机可能后续回调 CPU 抢占影响到服务器执行效率
目前流量较少所以采用单机负载, 后续看情况已经预留好可能会拆分支付订单模块的准备
因为目前支付平台是不对外开放的, 都是内部发行的支付系统传递的唯一订单号( reference_id ),
对订单号没有做唯一判断处理, 只是因为默认内部使用就就没有什么大问题, 后续需要补充更新这方面限制.
海外发行平台
这部分实际上考核很久, 主要就是在于作为 H5 海外的游戏平台 ‘容器’ 页面功能,
让游戏渲染在本身 iframe 之中, 大部分还是前端设计界面的问题.
特别需要注意的是海外支付的 embedded 方式, 这种方式就是引入第三方支付的JS-SDK,
在创建订单之后需要把会话参数传递给 JS-SDK, 后续 JS-SDK 会在 body 内插个节点渲染支付窗口.
这样虽然看起来效果还是挺不错的, 但是内部有很多问题:
- 第三方
CDN不稳定, 引入第三方的JS-SDK可能连通性有问题, 直接卡死在等待加载的资源之中 - 插入节点和
css样式出现冲突, 有的插入之后的样式名和类名在项目有出现冲突的样式 - 引发事件绑定异常, 有的SDK库带有动态事件绑定, 可能会直接导致游戏事件混乱
但是不可否认直接在页面内部弹窗唤起的交互效果好很多, 不过最后弹出新窗口去第三方页面支付,
支付完成再跳转会发行对外开发的订单完成窗口去执行 window.close 关闭当前页面.
内嵌式的支付弊端在尝试之后还是问题太多, 而且主要前端设计优先级比较低, 所以哪里方便就处理哪里.
还有一点就是对于 H5 业务来说, 实际上底层都是采用 iframe + postMessage 做通信交互,
SDK 业务中心
这方面实际上就是处理常规功能:
- 常规账号密码和海外 Google/Facebook 登录和登出: CP客户端 -> 发行平台 -> 业务中心
- 发起第三方支付订单请求: CP客户端 -> 发行平台 -> 业务中心
- 事件行为上报: CP客户端 -> 发行平台 -> 业务中心
- CP账号授权回调验证: CP服务端 -> 业务中心
- 回调第三方的入口(实际上是我们自身的支付平台): 支付平台 -> 业务中心 -> CP服务端
这里面大部分都是常规的功能, 主要问题还是在日志收集和行为上报之中.
发行平台肯定不止单款游戏应用, 在登录和注册需要做好日志用于统计当日注册登录和留存等数据, 同时还有CP客户端上报的数据也是比较庞大的, 我有种预感这部分可能是个雷区.
这部分先标记一下, 后续数据量大的情况可能也是要大规模改动的
但是任务时间比较紧迫, 后续这部分模块可能采用 Java|Golang 做处理,
上报的数据流用 kafka + logstash 做消息收集, 目前暂时先单库单表负载处理下.
整合后台管理中心
这部分目前暂时没时间处理太多角色权限分组, 并且为了防止各自之间的交叉权限问题, 这里先区分以下平台入口:
- manager: 最高管理员, 所有数据都可见, 可以初始化游戏应用等, 同时创建其他类型管理员给他们分配应用和渠道
- operator: 运营管理员, 只能看到所绑定的应用信息, 支持配置游戏如 icon 和封面等信息, 还有充值统计和登录留存分析
- channel: 渠道推广员, 只能看到最高管理员给他分配的应用和渠道数据, 没办法看细致分析统计, 仅仅作为获客和充值分成
以上的平台都是整个发行流程当中需要做数据隔离的, 因为大概率后面这些平台都需要再次做扩展开发; 如果全都混合在一起看起来开发起来很便捷, 一套代码可以复用给这么多平台角色; 但是后面业务量起来之后, 权限混合起来让所有代码和业务都合在一起搞得最后维护起来问题更多.
这部分需要点业务经验, 大部分都会去采用通用的 RBAC 处理, 虽然没有错但是后期业务扩展起来很麻烦
项目发行流程就是如同以下来派分任务:
- CP方面联系需求, 方案确认之后最高管理员平台下面初始化游戏应用
- 最高管理员同时创建运营账号并且将初始化的游戏应用绑定在这个运营账号, 创建生成白名单账号用于SDK测试
- 最高管理员提供运营账号(内部有认证 key 和支付 secure 验证信息), 并且提供 CP 需要接入的SDK 准备接入
- 运营管理者可以登录运营后台获取游戏 key 和 secure 用于联调, 并且可以修改游戏应用名称和上传背景图icon等宣传信息
- CP 方面确认之后开始联调接入我们这方面的SDK, 确实最后对应CP的客户端和服务端流程跑通, 可以准备开启支付通道
- CP和发行商务确认开放上线的时间点, 之后最高管理员设置上线时间, 并且需要设置开放的第三方支付通道
- 最高管理员需要找对应的旗下渠道人员来推广, 一般来说会对游戏应用做 ‘分包’ 处理, 需要创建渠道账号并且生成关联渠道码绑定
- 渠道人员管理员可以通过后台获取到分配特定的 下载|安装|游玩 地址, 后台就仅仅展示这部分注册和付费数据(甚至都不需要展示)
这就是总体流程, 如果仅仅作为单一区域受众, 比如中国国内或者某些地区目前基本上已经完成, 但是如果针对海内外那么问题就比较复杂.
问题说明
首先就是最明显的本地化和时区问题, 如果在国内只需要随便生成本地时间戳标识下当地时间就 OK 了.
但是套用到海外问题就不对了, 你的 时间戳是哪个时区? 美国时间? 日本时间? 中国时间? 日本时间?
并且海外推广还有更大的问题就是本地化挑战, 你的项目结构必须最少支持以下语言:
- 英语 - 语言代号: en, 地区代号: US, 地区货币: USD, 语言: en-English, 时区: -5(America/NewYork)
- 简体中文 - 语言代号: zh-CN, 地区代号: CN, 地区货币: CNY, 语言: zh-CN, 时区: +8(Asia/Shanghai)
- 繁体中文 - 语言代号: zh-TW, 地区代号: TW, 地区货币: TWD, 语言: zh-TW, 时区: +8(Asia/Shanghai)
- 日语 - 语言代号: ja, 地区代号: JP, 地区货币: JPY, 语言: ja, 时区: +9(Asia/Tokyo)
- 韩语 - 语言代号: ko, 地区代号: KR, 地区货币: KRW, 语言: ko, 时区: +9(Asia/Tokyo)
海外推广的人员可能不是和你同属区域的人, 所以整体后台面板都要可以动态调控语言和时区, 这也是需要处理做海外产品的时候需要面临的挑战和问题.
所以后续方面设计都要考虑 locale 和 timezone:
- 涉及语言提示都要采用
i18n处理 - 涉及时间方面统一采用
utc毫秒级时间戳 - 涉及订单方面都要追加
region(CN|US|TW|JP...)地区字段和currency(CNY|TWD|USD...)货币字段记录
这些方面的细节处理统一的跨地区和跨时区结算情况, 另外还有个细节就是结算周期和结算汇率的问题, 因为涉及到全球时间周期所以需要以某个地区当作结算, 并且需要按照汇率当作结算金额, 不过这是后续扩展外的问题.