在 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 ...
官方文档(需魔法工具): android-library
AAR(Android Archive) 是 Android 专属的库归档格式, 可以理解为和后段的 Jar 包类似的格式:
特性
AAR（Android专属）
Jar（通用Java）
包含内容
编译后的class文件 + 资源（布局/图片/字符串） + AndroidManifest.xml + 原生库（so）
仅编译后的class文件 + 清单（可选）
适用场景
Android组件封装（自定义View、Activity、带资源的工具库）
纯Java逻辑封装（无Android资源依赖）
依赖Android框架
强依赖（需Android SDK编译）
无依赖（可跨平台）
资源处理
自带资源打包，主工程可直接引用库内资源
无资源打包能力
本篇以 海外游戏上架 的 发行方 来说明 AAR 在其中起到什么作用, 其他相关扩展知识可以去网上获取
在现代化当中开发之中, 手机游戏上架涉及到以下方面:
游戏研发方: 负责开发游戏和生成 Android 应用
游戏发行方: 负责提供自己公司的 S ...
考虑到现有 spring-boot 框架内部冗余越来越多, 所以一直想找比较轻量级的网络框架.
在多次从易用性和轻量化考虑之后发现了 Quarkus 号称 极致优化启动速度、内存占用 的框架.
官方网站: Quarkus
主要选择有以下优点:
大厂背书: RedHat 主导开发, 有大厂做代码质量把控
GraalVM: 同时支持 JVM 模式和 Native Image 模式, 可以将应用打包成原生二进制
功能完备: 大部分 spring-boot 相关都有对应替代, 按照文档将需求切换过去问题不大
这里先生成基础的 POM 依赖配置:
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810 ...
之前 传奇类MMORPG 游戏都会去裸写二进制数据来交换, 但是需要客户端去定制处理包装二进制数据.
这种一般和客户端交换数据比较麻烦, 比如定义格式:
12345请求协议二进制: [int32] MSG_ID: 代表对应协议ID[int32] SID: 代表服务器ID, 比如 '游戏1服', 滚服的时候 id 增长很快[int64] UID: 代表数据库用户ID[int32|byte[]] TOKEN: 代表登陆用户的TOKEN, 字符串由 int32(定长的长度) + byte[](顶长二进制) 合并
后续为了出于开发效率和性能大部分采用通用 Google Protobuf 来做数据协议交换:
中文文档
英文文档
因为其广泛跨语言和跨平台特性在游戏应用也很广, 这里主要是选择 Java 版本来引入和生成.
目前的 Protobuf 有以下版本:
proto 2: 很早期的版本, 基本上处于维护, 官方不推荐采用
proto 3: 常规维护版本, 追加比较新特性, 移除部分特性实现
proto ...
官方网站: Pekko
在网络开发中, Actor(参与者模型) 是一种并发编程模型, 核心思想是将程序拆分为一个个独立和自治的 Actor 实体,
每个 Actor 拥有自己的状态和行为, 仅通过异步消息传递进行通信, 互不直接共享内存, 带有以下特性:
独立性: 每个 Actor 都是独立的执行单元且有自己的私有状态, 外部无法直接修改其状态, 只能通过发送消息触发 Actor
内部逻辑来改变状态
异步消息传递: Actor 之间的通信是异步和非阻塞的(
发送方把消息丢给接收方的消息队列后就继续执行,接收方按照消息到达顺序依次处理)
单线程处理: 一个 Actor 在同一时间只会处理一条消息, 天然避免了多线程共享状态的竞态问题, 不需要加锁(如synchronized)
地址与标识: 每个 Actor 有唯一的地址, 发送消息时只需指定地址, 无需关心 Actor 的物理位置(本地或远程),
这为分布式系统提供了天然支持
传统多线程模式需要手动处理锁、线程池、资源竞争, 否则容易出现死锁、数据不一致等问题
Actor 主要解决的问题:
共享状态的并 ...
