3、核心组件安装：策略引擎安装、数据库初始化、消息队列配置
好，咱们进入正题。这一章讲的是策略执行点部署里最核心的基建活儿——把策略引擎、数据库、消息队列这三兄弟安顿好。说实话，我在不少项目里见过因为这一步图省事，后面线上出问题排查到崩溃的情况。所以咱们慢慢来，把每个坑都踩明白。
3.1 策略引擎安装
策略引擎是整个系统的“大脑”。你给它输入条件，它给你输出决策。我习惯把它拆成两个部分来理解：规则解析器和执行上下文。
核心要点：策略引擎的安装本质上是一个 Java 应用部署，但它的依赖和配置项比普通 Web 服务要多。重点关注 JVM 参数、规则库路径、以及扩展点目录。
3.1.1 环境准备
先看看你需要什么。我列个清单，你对着准备就行：
| 组件 | 版本要求 | 备注 |
|---|---|---|
| JDK | 11+ (推荐 17 LTS) | 我用的是 OpenJDK，Oracle JDK 也行 |
| 操作系统 | CentOS 7+ / Ubuntu 20.04+ | 内核参数需要调一下，后面说 |
| 磁盘 | SSD，至少 50GB | 规则库和日志会膨胀，别省这个钱 |
| 内存 | 最低 8GB，推荐 16GB+ | JVM 堆内存至少给 4GB |
注意：千万不要用 JDK 8。我在一个老项目里吃过亏——JDK 8 的 G1 垃圾回收器在策略引擎高并发场景下会频繁 Full GC，导致决策超时。换成 JDK 17 后，问题直接消失。
3.1.2 安装步骤
嗯，这里我直接给操作步骤。你跟着敲就行：
# 1. 创建专用用户（别用 root 跑）
useradd -m -s /bin/bash pep-engine
su - pep-engine
# 2. 解压安装包
tar -xzf pep-engine-3.2.1.tar.gz -C /opt/pep-engine
# 3. 配置环境变量
cat >> ~/.bashrc << 'EOF'
export PEP_HOME=/opt/pep-engine
export PATH=$PEP_HOME/bin:$PATH
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
EOF
source ~/.bashrc
# 4. 初始化配置文件
cp $PEP_HOME/conf/engine.yaml.example $PEP_HOME/conf/engine.yaml
配置文件里，有几个参数我建议你重点关注：
- rule.base.path：规则库存放路径。我习惯把它挂载到独立的数据盘上，方便后续扩容。
- engine.worker.threads：工作线程数。公式是
CPU核心数 * 2，别贪多，线程切换也是有开销的。 - engine.cache.size：规则缓存大小。默认 10000 条，如果你的规则数量超过这个数，记得调大。
小技巧：启动前先用 pep-engine check 命令做一次配置校验。它能帮你发现 YAML 格式错误、路径不存在、端口冲突这类低级问题。我曾经有一次漏了冒号，排查了半小时……
3.2 数据库初始化
策略引擎需要数据库来存规则元数据、执行日志、以及一些运行时状态。我推荐用 PostgreSQL，当然 MySQL 8.0+ 也行。但说实话，PostgreSQL 在复杂查询和 JSON 支持上更顺手。
3.2.1 建库建表
先创建数据库和用户。安全起见，权限别给太大：
-- 创建专用数据库
CREATE DATABASE pep_db WITH ENCODING 'UTF8' LC_COLLATE='en_US.UTF-8' LC_CTYPE='en_US.UTF-8';
-- 创建专用用户
CREATE USER pep_admin WITH PASSWORD 'YourStrongPassword!';
-- 只给必要权限
GRANT CONNECT ON DATABASE pep_db TO pep_admin;
GRANT ALL PRIVILEGES ON DATABASE pep_db TO pep_admin;
表结构不用手写。策略引擎安装包里自带了一个 schema.sql，直接跑就行：
psql -h localhost -U pep_admin -d pep_db -f $PEP_HOME/sql/schema.sql
跑完之后，你会看到这些核心表：
| 表名 | 用途 | 数据量预估 |
|---|---|---|
pep_rules |
规则定义表 | 几千到几万条 |
pep_rule_versions |
规则版本历史 | 规则数的 10-20 倍 |
pep_execution_log |
执行日志 | 每天几百万条 |
pep_decision_cache |
决策结果缓存 | 取决于缓存策略 |
注意：pep_execution_log 表会快速增长。我建议你提前规划好分区策略——按天分区，保留最近 30 天的数据。否则半年后，一张表几百 GB，查询和清理都成问题。
3.2.2 连接池配置
策略引擎用的是 HikariCP 连接池。配置在 engine.yaml 的 datasource 段：
datasource:
url: jdbc:postgresql://localhost:5432/pep_db
username: pep_admin
password: YourStrongPassword!
driver-class-name: org.postgresql.Driver
hikari:
maximum-pool-size: 20
minimum-idle: 5
idle-timeout: 300000
connection-timeout: 30000
max-lifetime: 1800000
这里有个坑——max-lifetime 一定要比数据库侧的 wait_timeout 短。我遇到过连接被数据库侧断开，但连接池不知道，还在用“死连接”的情况。设成 30 分钟，基本能避开这个问题。
3.3 消息队列配置
策略引擎不直接处理所有请求。它通过消息队列来解耦——接收决策请求，异步返回结果。我推荐用 RabbitMQ 或 Kafka。小规模用 RabbitMQ 就够了，大规模（日均千万级请求）上 Kafka。
3.3.1 为什么需要消息队列？
你想想看，如果没有消息队列，每次决策请求都直接打到策略引擎。高峰期一来，引擎扛不住，整个系统就瘫了。有了消息队列，请求先排队，引擎按自己的节奏处理。说白了，就是给系统加了个“缓冲带”。
核心逻辑：请求方只管往队列里扔消息，策略引擎只管从队列里拿消息。两边互不依赖，各自独立扩缩容。
3.3.2 RabbitMQ 配置示例
我以 RabbitMQ 为例，讲一下怎么配。先创建虚拟主机和用户：
# 创建虚拟主机
rabbitmqctl add_vhost pep_vhost
# 创建用户
rabbitmqctl add_user pep_mq YourMQPassword
# 授权
rabbitmqctl set_permissions -p pep_vhost pep_mq ".*" ".*" ".*"
然后在策略引擎的配置文件里，加上消息队列的配置：
mq:
type: rabbitmq
host: localhost
port: 5672
virtual-host: pep_vhost
username: pep_mq
password: YourMQPassword
queues:
decision-request:
name: pep.decision.request
durable: true
prefetch-count: 100
decision-response:
name: pep.decision.response
durable: true
prefetch-count: 50
prefetch-count 这个参数很关键。它控制每个消费者一次能拿多少条消息。设得太小，消费者吃不饱；设得太大，消息堆积在消费者内存里，容易 OOM。我一般根据单条消息的处理耗时来算——如果处理一条要 10ms，prefetch 设 100，刚好 1 秒的缓冲量。
3.3.3 消息格式约定
消息体用 JSON，结构尽量简单。我习惯这样定义：
{
"requestId": "uuid-xxxx",
"timestamp": 1700000000000,
"context": {
"userId": "user_123",
"resourceType": "api",
"resourceId": "api_456",
"attributes": {
"ip": "192.168.1.1",
"method": "GET"
}
}
}
为什么要有 requestId？方便追踪。线上排查问题时，拿着这个 ID 去查日志、查数据库、查消息队列，一条链路就串起来了。
小技巧：消息队列的监控一定要做。我建议你至少监控三个指标：队列深度、消费延迟、消费失败数。队列深度超过阈值就告警，别等到消息堆积到几百万条才发现。
3.4 整体架构图
说了这么多，咱们用一张图把这三者的关系理清楚：
这张图把流程讲得很清楚了。请求方发消息到队列，策略引擎从队列拿消息，处理过程中读写数据库，处理完把结果放回队列。整个链路是异步的，谁都不等谁。
3.5 验证与测试
装完别急着上线。先跑一轮验证，确保每个环节都通：
- 检查引擎状态：
pep-engine status，看进程是否在运行，端口是否监听。 - 测试数据库连接：用
psql连上去，跑一条SELECT count(*) FROM pep_rules;，确认能查到数据。 - 测试消息队列：往队列里发一条测试消息，看引擎能不能消费到，并且日志里有没有报错。
- 端到端测试：模拟一次完整的决策请求，从发消息到拿结果，全链路走通。
小技巧：我习惯在测试环境里故意制造一些异常场景——比如把数据库停掉、把消息队列停掉，看引擎会不会优雅降级。如果它直接崩溃，那说明容错没做好，得回去改代码。
好了，核心组件的安装就这些。每一步都不难，但细节多。你按这个流程走，基本不会出大问题。如果遇到什么奇怪的报错，先看日志，日志里通常有答案。