Pekko 作为 Actor 底层框架, 其实内部自带了 Http/Https/WebSocket 扩展, 涵盖日常所需要的短连接和长连接场景.
这部分涉及到以下相关内容:
pekko-http
pekko-websocket
这里为什么推荐采用 WebSocket 做长连接服务?
主流支持非常广泛(现代代浏览器、iOS、Android、物联网设备)
抛弃以往的粘包/拆包、心跳检测、消息校验问题, 不用将心力放在数据流的验证上
CDN 厂家现在逐步有 WebSocket 的支持, 可以利用 CDN 的边缘节点就近接入客户端
当然也可以外置 WebSocket 库挂载服务, 只是采用 Actor 集成更加高效方便, 无缝贴合 Actor 处理
另外需要说明的 WebSocket 支持 text(文本流) 和 binary(二进制流) 传输模式, 这里强烈建议采用二进制流传输.
如果采用 text 文本流, 大部分数据库解析的时候都会做默认的 UTF8 编码转化成 String, 之后内部又会转换成 byte[] 交换数据.
高并发的情况下很容易直接生成大量 ...
Pekko Stream 是一套异步、非阻塞、支持背压(Backpressure)的数据流处理框架,
主要用来解决大数据/高并发场景下的资源管控问题, 避免数据加载时候的 OOM 问题.
pekko 需要依赖以下的组件(采用 Maven 来包管理):
12345678910111213141516171819202122232425262728293031323334353637383940414243444546<!-- 所需依赖 --><dependencies> <!-- Pekko Stream 核心依赖 --> <dependency> <groupId>org.apache.pekko</groupId> <artifactId>pekko-stream_${scala.binary.version}</artifactId> <version>${pekko.version} ...
作为长期使用的维护的远程 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: 负责接 ...
