作为长期使用的维护的远程 API 接口, 大部分都是用类似于 /v1/user/login 之类做版本控制管理;
但是实际上其实内部问题也很多, 比如长期运行的路由表堆积问题, 并且基于 Path 匹配导致没办法做到无感知升级.
之后接口设计我更加推崇的是 Header 版本字段控制, 请求时附加以下 Header 字段(以下字段都可以自定义, 最好做成动态配置):
X-Version: 请求的版本字段
X-Sign: 请求的字段签名
X-Authorization: 请求的授权 Token
X-App-Id: 可选配置, 如果采用多应用管理才需要, 一般单应用接口不需要用到
然后后续都是采用统一的请求接口 /user/login 之类, 而内部就是直接通过 Header 相关参数来调配转发到对应版本.
这里还是用 Quarkus 来做接口请求
按照常规的接口配置之后就编写控制器类来做接收请求:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464 ...
之前买 Orange 5Pro 来设计 NAS 的时候顺带买个 Orange 3B, 因为嫌弃性能不够一直没拆封过;
最近跨年整理的时候才发现这块开发板, 想着闲着也是闲着就看看能干点什么.
最后想着搭配手里的8寸便携式显示器直接改造成简单的小型 Steam Machine, 通过连接 XBOX 蓝牙手柄来游玩游戏.
OrangePI 3B 后面简称为 opi3
这套方案的具体配置如下:
RockChip RK3566 瑞芯微四核 64 位 ARM 处理器, 主频最高 1.8GHz
8GB LPDDR4/4X 自带内存
120GB SATA 廉价朗科固态硬盘(这是我额外购买扩展固态硬盘)
支持 Wi-Fi5/蓝牙/HDMI 方案
Armbian 系统(Debian的 iot 方案)
支持 OpenGL ES 1.1/2.0/3.2 | OpenCL 2.0 | Vulkan 1.1(Vulkan是重中之重)
需要注意: 这块开发板默认只启用的 NVME 协议, 直接接入 SATA 协议的固态是没办法识别的.
如果固态是 SATA 协议就需要修改 A ...
Steam 挂卡的核心原理是通过模拟游戏运行状态向 Steam 服务器发送 “游戏正在运行” 的心跳请求从而高效获取集换式卡牌.
注意: Steam 服务条款禁止第三方工具模拟游戏运行, 可能导致账号警告、限制市场功能或封禁, 所以本质上这种行为是带有风险
这部分功能目前已经有第三方实现并开源, 具体可以查看 ArchiSteamFarm
以下部分也是基于 ArchiSteamFarm 项目来搭建处理, 注意这里是基于 Debian 发行版搭建处理, 官方也提供更加方便的 Docker.
建议需要挂卡的账号配置 Steam 所有安全登陆配置(官方2FA), 避免挂载过程之后泄漏登陆密码或者 Token 相关
安装部署
按照官方安装指南来部署环境配置, 内部采用命令行模式而无需运行游戏界面来节约大量资源处理, 需要执行以下命令:
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162# 参照文档: http ...
针对 Linux 大部分性能指标采集, 需要用到对应相关的工具集, 这里提供目前比较主流的 Linux 检测手段:
perf: CPU 性能检测采集
iperf3: 网络性能检测采集
iostat: 磁盘IO监控
sar: 全能监控数据采集
CPU 性能检测
perf 是 Linux 系统下的性能分析工具(Performance Counters for Linux), 用于针对
CPU|内存|磁盘I/O|网络|进程/线程等系统资源的使用情况进行全方位的采样和分析.
这里采用 Debian 发行版来说明, 其他发行版只需要找 perf|performance 相关包安装即可:
123456# 安装依赖, 这里有的教程说是 linux-perf 或者 perf, 可能有的版本变迁之后更改包名sudo apt install performance-tools# 查看目前监控工具版本# 需要注意: 系统性能采集本身是很高级的功能, 所以大部分情况都是需要用到 root 高级权限sudo perf --version # 这里目前版本为 perf version 6.14.11
这里之后 ...
常规上报数据需要实现以下功能:
削峰 - 避免高并发写入过载, 保证大规模数据入库的时候不会直接让存储过程崩溃, 避免瞬时高并发、流量突增造成数据写入异常
压缩 - 降低存储数据的占用, 日志数据本身属于很尴尬的数据, 过期之后很少去查询到, 但是统计要让其后续保存待用
分页 - 大量数据需要被前端做页面数据处理, 大数据分页的时候 OFFSET + LIMIT 会有大量性能问题
高并发网络流量突发请求上来的大数据会瞬间引发数据锁抢占, 直接让数据库承载不了这部分数据写入, 卡死整个数据接口
这部分最通用的方案: 消息队列 + 列数据库, 而这方面目前的通用选型就是 Kafka + ClickHouse
Kafka + ClickHouse 是经过业内验证过, 最为高效且便捷的技术栈
Kafka 和 ClickHouse 的搭建流程可以参照其他文章说明, 这里是提出可用的技术方案:
Maven: 后台的包管理方案, 后端不要搞什么 Gradle 破坏性更新频繁来做包维护
Java17: 高版本支持 record 特性, 可以节约时间避免写入样板代码(我不喜欢 lom ...
传统 MySQL/PostgreSQL 在单表动不动超过 100G 之后就会考虑用分库分表硬抗, 但是本身就是治标不治本的问题.
哪怕分表出来, 后台也是需要分页查询展示数据, 单表 100G 以上多表合并分页分页查询要CPU和内存占满都要几十秒
基于这种大规律数据日志的情况, 传统的 MySQL/PostgreSQL 已经很难负载这部分功能, 需要寻求其他数据库支持.
也是在这种情况下, 就需要了解到 列存数据库(Column-Oriented Storage) 和 行存数据库(Row-Oriented Storage) 的概念.
在此过程之中就了解到列数据库 - ClickHouse:
特性
行存数据库（MySQL/PostgreSQL）
列存数据库（ClickHouse）
存储方式
按行存储，一行的所有列数据连续存放
按列存储，一列的所有行数据连续存放
查询效率
适合整行读取（如事务、单条记录查询），但查询少量列时需加载整行数据，IO开销大
适合列投影查询（如统计、聚合、筛选少数列），仅加载需要的列，IO效率极高
压缩比
同列数据类型分散，压缩率低（通常 ...
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 来做支付安全检测
不过这些不是开发者应该关注, 作为开发者我们需要处理的就是对接和构建 发行方 和 研发方 的产品接入.
需要注意游戏也当作应用的一种, 所以会采用应用来代指发行
首先作为 发行方 需要提供以下后台系统来方便业务接入:
核心后台(发行内部): 用于提供最高权限后台, 可以新增修改平台/渠道/应用, 也可以查看具体支付和上报信息
渠道后台(发行-推广): 提 ...
