借助其赛博菩萨 Cloudflare 的 Workers 实现动态 IP 与域名的自动绑定, 简单来说就是只需要域名就能将本地宽带内部服务暴露到公网,
并且还同时享受到 Cloudflare 的CDN|DDoS防护|IP代理隐藏等额外优势, 仅仅只需要把域名移交给 cloudflare 管理.
这里首先就是需要以下条件:
cloudflare 账号: 官网地址
cloudflare 托管的域名: 不要用国内的任何域名, 因为国内可能需要做网证等验证
一台能够持续运行的 linux 服务器
这里依赖 Cloudflare Zero Trust, 其实就是要求本地局域网运行的 Cloudflare 守护程序,
与 Cloudflare 云端通信, 从而将云端请求数据转发到本地网络的 IP + 端口.
通过依赖 Cloudflare Tunnel 业务实现内网穿透, 但是国内特殊国情, 可能在国内访问速度不快并有断流的情况发生
上面提到的国情问题导致实际上体验方面可能很不好, 所以如果想长期稳定使用还是要购买公网IP服务.
另外需要说明下的是启用 Cloudflare ...
目前 Linux 发行版都集成 SystemCtl 做系统管理, 现在如果要把二进制应用写入成系统应用基本上绕不开.
Systemctl 的服务基本可以分为以下类别:
service: 常规服务
timer: 定时器
mount: 挂载点
device: 设备
socket: 套接字
这里先从基础的自定义 service 编写服务开始:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142 ...
日常使用自动化脚本的时候常常会出现这种问题: 如果创建专用系统账户如果执行系统服务命令要么需要 sudo 输入密码, 要么就是无法使用命令
像是这种情况在日常当中也是十分常见, 好处也是很明显直接低配权限防止被入侵的时候完全掌控服务器:
123456# 如果想以非 root 用户重启 nginx, 以下命令是无法生效# 如果你的用户组正好是 sudo 组, 则会提示你必须手动输入用户密码确认启动systemctl restart nginx# sudo 组则是需要通过以下方式sudo systemctl restart nginx
但是在自动化运维的时候就很麻烦了, 引入不可能调用这些命令还要让你手动输入密码, 毕竟都自动化了肯定不能这样操作
所以这里就衍生出 visudo 和 NOPASSWD 概念, 通过配置可以让指定用户或用户组执行 sudo 命令时无需输入密码:
12# 进入 sudo 配置菜单, 注意调用的默认编辑其是 nano 而非 vi/vimsudo visudo
这里内部每一行就是定义权限:
12345678910username ALL=(ALL) NOPASSW ...
Cockpit 是开源的 Linux 服务器图形化管理工具, 专为简化服务器运维工作设计, 适合中小规模环境搭建使用.
一般用于常规 nas 或者 10 台服务器管理规模这类日常服务器运维
基本上主流的 Linux 都集成在包管理之中, 直接运行以下命令就可以安装:
12345# debian 系sudo apt install cockpit# redhat 系sudo yum install cockpit
默认启动的服务端口为 9090
cockpit 并不是 EXSI 和 PVE 这种专门虚拟化管理那种专业化的虚拟化平台, 仅仅是作为界面化运维管理;
同时也不具有底层系统级别的管理能力, 且不具有大规模服务集群的能力.
不过如果只是想单独简单管理几台容器化服务, 利用 cockpit 反而更加轻量而无须对系统整个重新构建.
cockpit-machines 只能间接管理 KVM 虚拟机, 仅支持基本的启停|创建, 没有快照|克隆|高可用方案
如果是小规模(5台)服务器范围且不需要快照备份功能, 只需要对应 cockpit 就足以满足.
系统级别虚拟化带来的问题就是 ...
在项目正式部署上限的过程当中, 有时候需要用到项目 打包 -> 测试 -> 出包 流程,
这个流程一般是重复且复杂的, 所以就衍生 高效、可靠、可追溯的开发与交付体验 为目标的 流水线 部署流程.
目前 Jenkins 自动化构建流程基本支持前后端项目和容器化处理
推荐采用单独的设备来部署 Jenkins, 因为打包中心可能涉及到修改和暴露很多东西, 所以最好做环境方面隔离.
安装部署
推荐直接 Jenkins官网 去下载 LTS 版本,
虽然我是坚定的 apt 一键安装部署推崇者, 但是基于目前的国内网络原因更新下载速度及其离谱(有时候要更新一整晚);
所以最后不得不直接采用安装包来部署, 还能避免污染 apt 源更新(除非国内以后有镜像部署来加速).
不过这里还提供下 APT 部署流程:
12345678910111213# 安装源证书sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key# 写入镜像源 e ...
本篇章主要实现多人在线的帧同步流程, 首先是定义客户端和服务端会用到的游戏交互事件 Protobuf:
12345678910111213141516171819202122232425262728293031syntax = "proto3";// 初始化最新的序列帧 - 这个事件是服务端和客户端双向共享, 也就是 Request-Response 响应方式// 其实就是从服务端获取的最新序列帧ID, 然后挂载客户端目前已经执行的序列化帧上等待下个帧运行// 后续需要初始化玩家坐标信息,场景信息也是通过该初始化事件加载; 比如下面声明初始化坐标位置[其实应该定义个 Vec2(x,y) 坐标结构]message InitFrame{ int32 frame = 1; // 后续初始化内容在以下扩充 float x = 2; float y = 3;}// 广播单项 - 玩家引发的发生帧变动// 核心的 frame 字段是帧序列的编号, 需要确保客户端和服务端对发生帧做同步// 当网络丢包重传的时候, 就能明确从那一个帧序列开始丢帧从而采用 ...
记录下海外第三方支付开发的一些关键点, 常见的海外第三方开发推荐按照以下方式处理.
时间戳记录
统一采用 UTC 的时间戳处理, 避免采用服务器地区时间戳导致的跨时区异常, 日常使用的时间戳获取:
Java: System.currentTimeMillis()
Python: round(time.time() * 1000)
.Net: DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()
PHP: round(microtime(true) * 1000)
并且推荐时间戳记录记录在数据库当中采用毫秒级, 可以精确到具体高精度时间.
唯一订单号
这里推荐数据库的订单号类型为 varchar(32) 或者 varchar(64) 且可以设置为数据库表主键, 具体生成时间相关格式订单如下:
12345678910111213141516/** * PHP生成和时间关联尽可能防止碰撞的订单号 * @return string */function order(): string { $microtime = mi ...
这里的Linux打包其实总共分以下几类, 更多是方便内网一键部署的情况:
Debian(.deb) 系列包系统: dpkg -i xxx.deb(安装)|dpkg -r xxx(卸载)
RedHat(.rpm) 系列包系统: rpm -ivh xxx.rpm(安装)|rpm -e xxx.rpm(卸载)
Docker 直接编写 Dockerfile 和 docker-compose 部署
一般来说如果是打包有分为 命令行 和 桌面应用, 这里主要是用于部署服务端所以采用命令行操作
这里需要先采用 debian 打包方式说明, 适用于 Debian|Ubuntu 系列的虚拟环境, 其他因为不常用所以后续再补充.
deb打包
实际上需要按照以下命令来做打包:
12345# 按照文件夹规则放置到其中dpkg -b 文件夹名称 安装包名称# 比如以下方式打包, fusion-gateway 是当前目录下的子目录dpkg -b fusion-gateway fusion-gateway_1.0_amd64.deb
按照以下流程测试打包名为 fusion-gateway 的应用, 该应用基 ...
如果 Chrome 浏览器版本比较新就可以直接让其安装到桌面上作为应用来处理:
无论手机还是桌面浏览器都能将网页安装到桌面从而变成 APP 来使用.
这里实现的方法其实十分简单, 只需要在 html 页面上追加 manifest 声明网页元数据:
123<head> <link rel="manifest" href="manifest.json"></head>
这里的 manifest.json 就是声明 PWA 的 JSON 格式配置文件, 实际上就是相当于调用本地浏览器的 Web 应用入口,
也就是 轻应用 的概念的由来, 无须复杂的桌面|移动端开发来构建的应用.
manifest.json 配置是所有浏览器通用的, 这里提供 Mozilla
的官方说明: Mozilla Manifest
配置的样例如下:
lines123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495 ...
近些年游戏序列化工具不断迭代更新, 比较知名的是 Protobuf|MessagePack 这种序列化,
如果性能要求不高甚至 JSON|XML 这种广泛集成语言也是可以作为游戏数据载体.
但是实际在项目使用当中发现其实 Protobuf 问题也很多, 包括以下问题:
项目引入不可预测的复杂性, 有时候版本可能出现冲突( ProtobufV2 和 ProtobufV3 )
没办法适应性动态处理数据, 结构变动必须要对 proto 文件再编译导入游戏当中
而且对于小众语言来说, 可能根本没有具体实现处理
有的H5游戏上架平台对于底层数据读写功能要求很严格导致可能无法引入
特别是游戏项目, 很多都不采用外网软件库当中的项目引入而是自己内网重写相关功能,
所以对于游戏数据传输其实推荐更加采用原生二进制读写:
基本上是编程语言都支持, 真正跨平台处理, 不需要额外引入别的依赖
序列化过程可以自己动态处理, 不需要编译直接热更
这里采用 Java 语言做示例, 讲解怎么二进制在游戏当中怎么构建和传输.
数据结构
网络传输的数据结构一般常规以下几种:
byte| ...
