MeteorCat

Systemd 技巧 目前 Linux 发行版都集成 SystemCtl 做系统管理, 现在如果要把二进制应用写入成系统应用基本上绕不开. Systemctl 的服务基本可以分为以下类别: service: 常规服务 timer: 定时器 mount: 挂载点 device: 设备 socket: 套接字 这里先从基础的自定义 service 编写服务开始: # ============================================================================ # 基础单元描述信息 # 用于定义服务的基本信息、依赖关系、启动顺序等, 不涉及服务运行逻辑 # ============================================================================ [Unit] # Description: 服务的简短描述 Description=Java Depoly Application # Documentation: 服务的文档地址(如手册、URL) Documentation=https://app.meteorcat.me # After: 指定本单元应在哪些单元之后启动(仅控制顺序不强制依赖), 例如 After=network.target 表示网络就绪后再启动 # 注: 多个应用以空格划分, 允许依赖多个单元之后启动 After=network.target redis.service # Before: 与 After 相反, 指定本单元应在哪些单元之前启动防止被抢断 Before=nginx.service # Requires: 强制依赖, 若依赖的单元启动失败, 本单元也会启动失败; 若依赖单元停止,本单元也会被停止 # 这也是个很有用的配置, 防止数据库等崩溃还继续接收请求执行业务 Requires=mysql.

sudo授权 日常使用自动化脚本的时候常常会出现这种问题: 如果创建专用系统账户如果执行系统服务命令要么需要 sudo 输入密码, 要么就是无法使用命令 像是这种情况在日常当中也是十分常见, 好处也是很明显直接低配权限防止被入侵的时候完全掌控服务器: # 如果想以非 root 用户重启 nginx, 以下命令是无法生效 # 如果你的用户组正好是 sudo 组, 则会提示你必须手动输入用户密码确认启动 systemctl restart nginx # sudo 组则是需要通过以下方式 sudo systemctl restart nginx 但是在自动化运维的时候就很麻烦了, 引入不可能调用这些命令还要让你手动输入密码, 毕竟都自动化了肯定不能这样操作 所以这里就衍生出 visudo 和 NOPASSWD 概念, 通过配置可以让指定用户或用户组执行 sudo 命令时无需输入密码: # 进入 sudo 配置菜单, 注意调用的默认编辑其是 nano 而非 vi/vim sudo visudo 这里内部每一行就是定义权限: username ALL=(ALL) NOPASSWD: ALL # 按照配置顺序依次解释如下: # - username [指定的系统用户, 替换成实际用户名, 如果以 % 开头的就代表用户组] # - ALL [限制该规则生效的访问主机, 默认所有主机 ALL 访问即可] # - (ALL) [限制用户可切换到的用户或组, 比如 devops/root 之类切换允许对应组] # - NOPASSWD: [指定后续命令无需输入密码即可执行, 如果不带该标识则需要输入授权密码] # - ALL [限制允许执行的命令, ALL 表示所有命令, 若指定路径如 /usr/bin/apt 则仅允许该命令] # 这里命令是允许多条共存, 如下给专属账号配置专用, 但是后定义的规则优先级更高所以一般默认命令应该放置到最后 # 最好实践就是专门创建个执行组来做命令执行调用, 比如如下配置就设定只有 devops 用户组的用户才能无密码调用这些命令 %devops ALL=(ALL) NOPASSWD: /usr/bin/apt, /usr/bin/systemctl 另外有的发行版追加了 /etc/sudoers.

Cockpit 运维搭建 Cockpit 是开源的 Linux 服务器图形化管理工具, 专为简化服务器运维工作设计, 适合中小规模环境搭建使用. 一般用于常规 nas 或者 10 台服务器管理规模这类日常服务器运维 基本上主流的 Linux 都集成在包管理之中, 直接运行以下命令就可以安装: # debian 系 sudo apt install cockpit # redhat 系 sudo yum install cockpit 默认启动的服务端口为 9090 cockpit 并不是 EXSI 和 PVE 这种专门虚拟化管理那种专业化的虚拟化平台, 仅仅是作为界面化运维管理; 同时也不具有底层系统级别的管理能力, 且不具有大规模服务集群的能力. 不过如果只是想单独简单管理几台容器化服务, 利用 cockpit 反而更加轻量而无须对系统整个重新构建. cockpit-machines 只能间接管理 KVM 虚拟机, 仅支持基本的启停|创建, 没有快照|克隆|高可用方案 如果是小规模(5台)服务器范围且不需要快照备份功能, 只需要对应 cockpit 就足以满足. 系统级别虚拟化带来的问题就是物理资源有限制(有的虚拟化需要最少4G内存等), 并且系统资源占用也不低(cockpit占用不到100M) cockpit 需要 KVM 虚拟机可以选择 cockpit-machines, 如果需要容器化管理可以选择 cockpit-podman: # debian 系 sudo apt install cockpit-machines sudo apt install cockpit-podman # redhat 系 sudo yum install cockpit-machines sudo yum install cockpit-podman 安装之后启动服务即可:

Jenkins 部署 在项目正式部署上限的过程当中, 有时候需要用到项目 打包 -> 测试 -> 出包 流程, 这个流程一般是重复且复杂的, 所以就衍生 高效、可靠、可追溯的开发与交付体验 为目标的 流水线 部署流程. 目前 Jenkins 自动化构建流程基本支持前后端项目和容器化处理 推荐采用单独的设备来部署 Jenkins, 因为打包中心可能涉及到修改和暴露很多东西, 所以最好做环境方面隔离. 安装部署 推荐直接 Jenkins官网 去下载 LTS 版本, 虽然我是坚定的 apt 一键安装部署推崇者, 但是基于目前的国内网络原因更新下载速度及其离谱(有时候要更新一整晚); 所以最后不得不直接采用安装包来部署, 还能避免污染 apt 源更新(除非国内以后有镜像部署来加速). 不过这里还提供下 APT 部署流程: # 安装源证书 sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \ https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key # 写入镜像源 echo "deb [signed-by=/etc/apt/keyrings/jenkins-keyring.asc]" \ https://pkg.jenkins.io/debian-stable binary/ | sudo tee \ /etc/apt/sources.list.d/jenkins.list > /dev/null # 更新安装依赖组建, 注: JenkinsLTS 目前基于 Java17 构建, 热更版本是基于 Java21 sudo apt-get update sudo apt-get install fontconfig openjdk-17-jre sudo apt-get install jenkins 这里如果自带网络代理的时候, apt 作软件版本维护都挺不错, 可惜就国内网络基本上配置这个源会导致更新系统应用更加缓慢, 只能自己手动部署这个服务(不过一般这种都是作为长期服务启动不需要太频繁维护):

在日常当中对于常规使用 Web 项目都会集成 SpringBoot 工具, 一般来说直接按照以下方式启动就行: # 启动 Jar 并携带启动配置文件 java -jar package.jar -Dspring.config.location=./application.yml 实际上其他简单和非Web应用并不需要集成这么重量级框架, 所以应该回归到传统附带启动参数的方法, 采用第三方库 JCommander 就能直接编写简单高效的命令行启动工具. 建议: 命令行最好全部采用英语而不要用中文emoji等特殊字符说明, 有的环境会因为缺少字符集乱码(英语最通用所以基本默认集成) 按照官方需要引入第三方库: <!-- JCommander 第三方库 --> <dependency> <groupId>org.jcommander</groupId> <artifactId>jcommander</artifactId> <version>2.0</version> </dependency> 这里推荐还需要设置打包工具, 让其打包的时候指定 main 入口类, 避免启动的时候无法找到入口类: <!-- Maven打包配置 --> <build> <plugins> <!-- 编译打包配置 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.13.0</version> <configuration> <source>17</source> <target>17</target> <encoding>UTF-8</encoding> </configuration> </plugin> <!-- Jar打包功能配置 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>3.4.2</version> <configuration> <archive> <manifest> <addClasspath>true</addClasspath> <!-- 这里就是默认启动的入口类文件 com.fusion.game.FusionHttpApplication.java --> <mainClass>com.

Akka Actor服务 这里按照官方说明直接采用多项目 Maven + JDK17 设置, 基础的父根目录框架名为 fusion-framework 需要注意其实还有热更新方案等考虑, 但是这里基于 websocket 对于服务热更要求不高所以直接跳过 另外还需要注意: akka 在 2.6.x 之后的版本转向闭源付费, 仅允许在开发和非生产系统中免费使用, 如果为了规避商业行为清尽量采用 2.6.x 版本二次开发. 或者采用后续开源版本: Pekko <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.meteorcat.fusion</groupId> <artifactId>fusion-framework</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <!-- 全局属性 --> <properties> <java.version>17</java.version> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <spring-boot.version>3.3.10</spring-boot.version> <maven-compiler.version>3.13.0</maven-compiler.version> <lombok.version>1.18.36</lombok.version> <!-- 2023.0.x 又名 Leyton SpringBoot 3.3.x, 3.2.x --> <spring-cloud.version>2023.0.2</spring-cloud.version> <!-- akka3 Actor --> <akka3.version>2.6.21</akka3.version> <scala.binary.version>2.13</scala.binary.version> <logback.version>1.5.18</logback.version> </properties> <!-- 子模块定义 --> <modules> <module>fusion-actor</module> <!-- Actor集群项目 --> </modules> <!

Linux应用打包 这里的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打包 实际上需要按照以下命令来做打包: # 按照文件夹规则放置到其中 dpkg -b 文件夹名称 安装包名称 # 比如以下方式打包, fusion-gateway 是当前目录下的子目录 dpkg -b fusion-gateway fusion-gateway_1.0_amd64.deb 按照以下流程测试打包名为 fusion-gateway 的应用, 该应用基于 Java17-Jre 依赖启动: # 创建并进入目录之中, 注意 DEBIAN 目录是必须的 mkdir -p fusion-gateway/DEBIAN && cd fusion-gateway/DEBIAN # 之后就是包信息文件 control # 关键字首字母大写, 冒号后面必须有空格 # 必填字段: Package、Version、Architecture、Maintainer、Description，且内容不能为空 touch control # postinst(安装后脚本) | prerm(卸载前脚本) # 注意权限必须要 <= 775, 否则会出现包安装失败 touch postinst && chmod 755 postinst touch prerm && chmod 755 prerm 这里为了演示移动文件, 所以下载个 MIT 许可文件放入依赖目录安装之后自动创建目录和移动文件, 文件地址为: MIT License, 下载或者复制内容之后命名为 License.

微服务API网关设计 当项目负载规模不大的时候, 基本上单个项目 http://域名/user 和 http://域名/pay 这样访问API就行了, 在之后如果项目规模开始上来最多用 nginx 负载均衡处理一下分流到不同服务器, 但是后续功能业务和流量大规模上来之后也会到达瓶颈. 按照业务程度分布起始就这以下阶段: 简单实现基础 api 功能, 业务功能比较少且接口简单 流量上来需要对请求限流和负载均衡, 与此同时业务接口还是在可控可维护范围 不止接口流量庞大, 同时业务也规模上去(用户模块,订单模块,统计模块,广告模块,….将近上千多个), 这时候单项目维护就很麻烦了 当超大流量的情况把功能集中在单个项目里面, 哪怕按照目录区分(/user,/pay,/activity,...) 也是很耗费精力的事, 所以需要做模块拆分. 拆分出来之后很可能内部不同地址需要统一的网关服务器, 网关负责接收外部请求统一入口并协调转发到内网服务. 对于内网来说就是编写模块下业务并且注册到网关提供服务, 这样的好处就是隔离不同业务服务并且支持热更, 如果某个服务请求过大卡住的时候不会直接影响到其他服务, 只要不是同个模块下的服务都互不影响从而方便开发针对业务调试. 这里也引申出微架构的主要结构: 网关 和 模块 网关负责模块的服务注册和转发, 利用 eureka 可以更加方便做服务注册中心来处理服务重连等情况 模块就是具体业务分层, 启动的时候注册到网关来暴露自己的业务功能, 利用 springCloud 可以直接无缝接入到 eureka 以下方案也是直接采用 eureka 和 springCloud, 同时最低Java版本为17 配置多模块 直接在项目目录下追加 pom.xml, 文件内容如下: <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.meteorcat.fusion</groupId> <artifactId>micro</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <!-- 全局属性 --> <properties> <java.

Neo4J部署 官网提供 搭建教程 涵盖了所有平台, 主要是硬件设备满足即可, 最低需要双核4G配置才能获取到较高效率. 这里采用系统 apt|yum 按照部署: # 注意目前官方对于Java版本有需求, 所以可能需要按照官方处理 # 配置官网源 wget -O - https://debian.neo4j.com/neotechnology.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/neotechnology.gpg echo 'deb [signed-by=/etc/apt/keyrings/neotechnology.gpg] https://debian.neo4j.com stable 5' | sudo tee -a /etc/apt/sources.list.d/neo4j.list sudo apt-get update # 查看安装版本 apt list -a neo4j # Ubuntu的话需要启用 universe 库, 否则可能安装失败 sudo add-apt-repository universe # 这里默认采用社区版, 付费版本需要另外配置 sudo apt-get install neo4j=1:5.26.0 // 社区版 # sudo apt-get install neo4j-enterprise=1:5.26.0 // 企业版 安装完成之后配置跟随启动和启动: # 启动之前最好重置下密码 sudo neo4j-admin dbms set-initial-password 密码 # 首次启动数据库前，建议使用 neo4j-admin 的 set-initial-password 命令定义本地用户 neo4j 的密码 sudo systemctl enable neo4j sudo systemctl start neo4j # 默认会启动WebGUI来提供测试: curl http://localhost:7474/ # 开发环境可以通过配置修改为全网访问, 正式环境别这样处理 # 修改全网访问: server.

接口限流 如果从事过接口开发的时候发现过接口流量异常, 可能有针对接口进行 刷流量 的情况, 所以就需要对接口进行请求限流防止服务崩溃. 如果直接没有对接口进行限流任由网络刷接口会导致数据库|NoSQL服务直接崩溃, 比如数据库 oom kill 这里需要区分开发过程两种网络服务: 脚本语言: PHP等 编译语言: Java等 对于脚本类型的语言开发接口, 脚本服务并不是常驻内存服务就需要 Redis 做内存访问锁, 如下代码处理: $redis = new Redis(); // 假设获取到客户端IP $ip_address = "192.168.1.111"; // 直接判断 redis 之中Key是否存在 // 存在就是目前还在超时或者超时时间偏差值 $key = "timeout_{$ip_address}"; if($redis->exists($key)){ // 这里代表存在该Key需要判断是否超过指定时间 $value = $redis->get($key); // 计算Redis请求时间和当前时间的误差值 $now = time(); if(is_numeric($value) && (($now - $value) > 1) ){ exit("timeout"); // 防止请求过快直接拦截 } } // 写入接口请求的时间戳 $now = time(), $redis->set($key,$now); // 设置该请求时间 $redis->expire($key,1);// 设置1s之后超时销毁 上面是个简单的接口限流方式, 实际上还需要根据请求的路径 PATH_INFO 做限流让各自接口做不同限流方式.