注意: 需要前置学习 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 主要解决的问题:
共享状态的并 ...
在 Java 项目开发中, 多模块(Multi-Module) 是基于 Maven|Gradle 等构建工具实现的项目结构设计模式,
主要核心是将一个大型项目拆分为多个功能独立和职责单一的子模块(Module), 通过构建工具管理模块间的依赖和打包流程.
看起来很理想, 将代码合并在共同项目下复用大量的功能逻辑从而避免重复开发, 可以减少大项目之后大量冗余代码.
但是实际操作问题点很多, 最终在大量现实问题当中只能直接放弃 Java 的多项目管理, 这里说下主要踩坑的点:
无法单独项目独立: 项目都是寄放在同个 git 仓库, 也就是代表 clone 就能把所有业务秘密全导出(加密哈希和字段检验方式)
循环交叉依赖: 有时候业务很容易出现双方模块做交叉依赖, B 项目交叉用到 A 项目的验证库, C 项目也依赖 A 项目, 升级都要跟随升级
模块编译复杂度提升: 因为归到同个 git 库(比如区分 user/pay 等业务), 某个业务增加新业务提交上去一变动就要全部检测编译
业务堆叠在相同版本库: 所有业务都集中在一个版本库, 日积月累所有人提交版本导致堆叠在一起, ...
最新版本版本的 nginx 相关源(debian 及其发行版)已经集成 Nginx 的 Lua 扩展,
不需要再去手动编译处理相关依赖就能让 Nginx 运行些简单的 Lua 服务:
123456789# 安装 nginx 和 nginx-lua 扩展sudo apt install nginx nginx-extras libnginx-mod-http-lua# 确认是否配置完成, 有输出即可ls -l /usr/lib/nginx/modules/|grep lua# 生成测试配置, 后续在此操作sudo mkdir -p /etc/nginx/lua.d/lib # 生成被 nginx 调用的目录 sudo touch /etc/nginx/conf.d/lua.conf # 测试访问 Lua 功能配置
首先必须要要提醒一下: 不要将日常需求业务在网络基建实现!
能够在 nginx 运行 lua 也就代表能够运行业务代码, 但是这种操作是具有毁灭性的;
业务代码大部分时候逻辑复杂且需要用到大量现代技术(线程池|连接池等), 而内部的 Lua 模块仅仅作为内迁脚本系统是无法实现复 ...
有时候需要提供将影视资源 影片点播 这种类似的功能, 方便将服务器的影片直接在线播放;
虽然 mp4 文件直接挂个 nginx 服务播放, 但是影片资源不止有 mp4, 还有其他主流比如 flv 等格式.
大部分资源只是按照通用格式采用 mp4, 还有其他类似 .avi/mov/wmv/mkv/flv 等, 浏览器仅能支持 mp4
所以我们需要处理的就是将资源利用 ffmpeg 推流, 可以类似于直播一样播放我们服务器的影片资源
注意: 不止播放家庭影视资源, 还能涉及到家里监控推到自己内网服务器保存, 还有其他很多种玩法
需要明确在推流过程当中的定义:
要实现全天推流需要提供 推送端(推) 和 发布端(拉), 本质上就是要构建视频流推/拉流
需要搭建支持 rtmp 等协议的 hls 流媒体网络服务(充当转发平台)
需要 ffmpeg(服务端)|OBS(桌面端) 做流推送到流转发平台
默认的源安装 Nginx 不支持 nginx-rtmp-module 相关模块, 手动编译就感觉没什么必要,
不过在 debian 系的 Linux 发行版的源追加第三方扩展方便直 ...
传统都是依靠 /etc/resolv.conf 来处理 DNS 解析, 但是新的 linux-systemd 系统转而采用 resolved.service 处理网络解析服务.
而目前如果只要不是太老的 linux 版本建议都直接采用 resolved 相关工具链来维护处理服务器 DNS 相关;
resolved 实际上是一整套的工具链, 本质上其实就是在本地开启开启个小型的 DNS 服务端, 常规操作如下:
1234567891011121314151617181920# 查看目前的服务器解析路由状态, 可以看到所有网口链路sudo resolvectl status# 查看目前的DNS系统单元状态sudo systemctl status systemd-resolved.service# 上面的命令都可以看到网口对应 DNS 服务及其上游# 当然借助这个工具可以手动指定全局 DNS 公共服务器sudo resolvectl dns all 8.8.8.8 223.5.5.5# 也可以指定 eth0 网口服务采用的 DNS 服务器sudo resolvectl dns eth0 8 ...
