RESTful 是接口架构风格(而非标准), 其核心原则包括资源导向、HTTP 方法语义化、状态码标准化、无状态等;
也就是将接口行为抽象关联成 HTTP 响应方法:
GET: 获取数据, 参数以 ?xxx=yyy 方式附加查询
POST: 创建数据, 以内部 form/json 结构体方式提交
PUT: 更新数据, 和 POST 类似, 但是要求以 ?id=1 或者 /id/1 方式更新指定数据
DELETE: 删除数据, 也是针对 ?id=1 或者 /id/1 方式删除数据
RESTful API 请求方法和具体语义挂钩, 将请求地址视为 资源(Resources), 我们需要处理的就是对资源的 增删改查.
但是这种方式仅仅作为 理想状态下, 实际上业务层面的事情复杂得多, 并且还带有其他外部影响.
曾经我也是纯正的 RESTful 原教旨主义, 但是日常经过大量业务积累之后发现很多业务单纯 RESTful 简直是折磨
这里就说明下具体业务场景, 说明下日常可能出现的问题.
网关异常
这是首当其冲的问题, 一般来说正式上线的项目请求流量过大都会购买 “高防服务器” 来做流量 ...
在大部分情况下, 常规的 MySQL/PostgreSQL 就足够常规业务的 CURD 操作, 当业务扩展出来就开始有瓶颈.
最能体现这种情况就是 日志系统, 数据库当中的系统日志具有以下特征:
写入量极大且写入频繁: 查询比较少(就后台管理最多不超过100人), 但是写入量极大, 会出现单表超过50GB情况
查询条件复杂: 日志查询通常是按时间范围、关键字、级别、服务名等维度的组合查询, 细致一点还有针对某些属性查询
数据复用率低: 很多日志可能只需要查询半年或者90天数据, 其他时间段很少被查询到
数据结构可能比较灵活: 日志内容常包含 JSON、自由文本等非结构化数据(如接口请求参数、异常堆栈信息)
传统数据库虽然也能做此类数据保存, 但是在查询方面卡顿会非常严重, 并且 CPU 直接暴涨超过 100%.
也基于这种情况而需要外部其他工具来辅助, 也就是日常见到的传统分层处理架构:
MySQL/PostgreSQL(冷存储): 负责冷数据落地
Kafka(消息队列): 削峰填谷, 承接高并发日志写入, 同时作为热数据缓冲区
其他服务API: 负责接 ...
作为发行的 H5-SDK 一般都是类似于 iframe 嵌套外部网页地址的模式:
1234<!-- 假设访问的游戏主页面 HTML, 也就是发行方的访问地址 --><body><iframe src="{内部的 iframe 地址就是游戏页面地址}"></iframe></body>
而游戏研发方就需要引入发行方的一段 JS 脚本, 让研发方的来接入对应功能:
12<!-- 在研发方的 HTML5 游戏页面当中引入 --><script src="https://{发行商提供的域名}/static/sdk/PinoSDK.js"></script>
一般不推荐将这个文件下载到本地资源再应用, 否则可能无法及时更新对应 API 接口, 内部 SDK.js 需要实现以下功能：
init(单向, 只需要监听): 初始化, 监听 iframe 上层返回的数据信号
login(单向, 只需要监听): 授权登录, 由 ...
海外发行其实和国内发行差不多, 主要核心是打通 “内容 / 产品适配 - 合规准入 - 渠道分发 - 运营变现 - 本地化服务” 的全链路.
主要问题点就是海外和国内合规有所不同：
数据合规: 遵循 GDPR(欧盟)、CCPA(加州)、PIPL(中国跨境数据)等,做好数据本地化存储、用户授权、数据跨境传输备案规定
内容合规: 规避宗教、政治、文化禁忌, 如中东市场避免暴露性内容, 欧美市场注意版权和商标, 主要还是设计暴露程度等
行业合规: 游戏需获取各国评级(ESRB、PEGI、CERO), 影视需通过当地审查机构认证
支付合规: 海外大部分都是采用信用卡在线支付, 需要利用 3DS 来做支付安全检测
不过这些不是开发者应该关注, 作为开发者我们需要处理的就是对接和构建 发行方 和 研发方 的产品接入.
需要注意游戏也当作应用的一种, 所以会采用应用来代指发行
首先作为 发行方 需要提供以下后台系统来方便业务接入:
核心后台(发行内部): 用于提供最高权限后台, 可以新增修改平台/渠道/应用, 也可以查看具体支付和上报信息
渠道后台(发行-推广): 提 ...
在 PHP 目前在经过不断迭代之后完善了 包管理 机制, 可以通过正规包管理来部署对应的第三方包和项目维护.
包管理工具: PHP-Composer
这里如果是日常开发安装即可, 而 Linux 环境可能需要在服务器部署对应服务:
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465# 这边采用 debian 环境, 所以可以直接采用 apt 源部署# 虽然直接官网配置能够安装最新版本, 但是还是习惯直接默认做源依赖好点sudo apt install composer # 很简单就安装上, 之后就是开始包管理, 这里先进入测试目录cd /tmp# 如果要初始化自己化的项目可以按照一下命令安装初始化mkdir owner-project && cd owner-project # 创建并进入目录composer init # 执行初始化# 在命令行当中可以输入以下内容# Pack ...
官方文档: validation
Quarkus 集成 Jakarta Validation(原 Bean Validation) 能优雅地完成请求参数和方法入参/返回值的合法性校验, 无需手写大量逻辑.
除了挂载 Rest 相关组件需要引入以下依赖:
12345678<!-- 其他略 --><dependencies> <!-- 核心 Validation 依赖 --> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-hibernate-validator</artifactId> </dependency></dependencies>
官方简单的例子, 需要先定义验证结构体, 这里推荐采用高版本的 record 特性, 能节省大量编写样板代码:
123456789101112131415161718192021222324252627 ...
官方文档: hibernate-orm-panache
Quarkus 推荐使用 Hibernate ORM with Panache 来处理数据库操作, 并且支持原生 JPA/Hibernate ORM.
支持原生 JPA 主要是为了兼容 spring-boot 迁移过来的项目集, 方便其不需要修改内部数据层代码就可以直接复用.
这部分需要引入扩展第三方库:
12345678910111213141516171819202122232425262728<!-- 其他略 --><dependencies> <!-- Quarkus ORM 依赖, 后续选择指定数据库 JDBC 驱动 --> <!-- 具体驱动列表参照: https://quarkus.io/guides/hibernate-orm#setting-up-and-configuring-hibernate-orm --> <dependency> <groupId>io.quarkus</groupId> ...
这里主要针对的是引入 AAR 之后需要区分启动之后的渠道包, 涉及到对引入 AAR 配置的重新打包, 也就是 CPS 包.
CPS(Cost Per Sale): 按销售付费追踪包, 用于订单归因、数据上报、返佣计算、链接生成加载统计有效买量成本
比如你作为 发行商, 第三方 研发商 在平台上架游戏, 我们就可能会帮助生成指定渠道包给线下推广或者直播主来付费推广.
这时候的付费推广安装包必须在启动的时候就获得属于自己的 标识, 从而方便把后续登陆/支付(买量和付费成本)纳入分成统计.
这样处理可以方便统计以下数据:
指定渠道的获取用户绩效: 某些渠道拉取新用户多, 方便其渠道下面用户维护其注册用户
指定渠道的付费转化率: 某些渠道付费转化率优秀, 这部分可以转化成推广佣金分成
需要区分 CPS 和 渠道包 的差别, 这两者虽然都是有特殊标识, 但是作用是完全不一样的:
渠道包: 指定平台(比如抖音/快手/谷歌)会单独出个包额外做标识, 独有的渠道标识区分平台来源
CPS: 针对自己推广下的来源标识, 用于自身做统一的推广渠道佣金分成
这里有几种 ARR 注入 ...
注意: 需要前置学习 Quarkus 集成 Pekko 篇章配置 Quarkus + Pekko 作为服务端基础
这里的篇章暂时不涉及 集群 概念, 一旦引入集群概念可能 Actor 概念更加复杂.
参考之前说的 skynet 的源码配置就可以知道, 一般都会启动 socket 连接之后会动态创建 Actor 挂载:
连接建立时动态创建 Actor 并挂载
连接断开时销毁 Actor
所有业务逻辑通过 Actor 异步处理, 天然实现连接级别的隔离和并发安全
如果是初学者推荐采用 WebSocket 做网络数据交换成, 主要原因是:
协议简单: 内部已经做好数据分包, 不需要手动去将包划分
数据可视化: 数据内容可以比较直观通过客户端发送数据(Postman之类应用可以直接发送)
集成度广泛: 基本上全平台通用, 甚至于随便编写 html 页面也能作为客户端
而 WebSocket 的基本回调事件如下, 需要先提前封装对应事件信号(这里的生命周期名称可以随便修改):
生命周期名称
触发时机
核心作用
Actor 场景适配
Connect ...
如果要做比较高并发的游戏服务端, 单独采用以下技术栈会有以下问题:
Quarkus: 作为集成框架缺少对应 Actor 底层游戏架构, 所以得自己手动实现
Pekko: 作为 Actor 缺少容器托管和快捷数据库 ORM 框架
所以需要将两者结合起来, 就能设计开发出稳定高效的游戏游戏服务端框架, 这里提供简单的 POM 项目依赖文件:
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451 ...
