2、核心概念：规则引擎定义、服务目录定义、Policy Check在微服务中的角色
在深入通信机制之前，必须统一对三个核心概念的认知：规则引擎、服务目录以及Policy Check在微服务体系中的定位。这三者构成了整个策略体系的执行、发现与决策基础。
2.1 规则引擎定义
规则引擎是一种将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策的组件。它接受数据输入，解释业务规则，并根据规则逻辑输出决策结果。
| 维度 | 说明 |
|---|---|
| 核心功能 | 将复杂的、频繁变化的业务/安全策略从硬编码中解耦，实现动态决策。 |
| 输入 | 事实（Fact）：来自服务请求的上下文数据，如用户角色、资源类型、环境标签。 |
| 处理逻辑 | 规则集（Rule Set）：由条件（Condition）与动作（Action）组成的逻辑单元。 |
| 输出 | 决策结果：允许（Allow）、拒绝（Deny）、告警（Warn）或自定义动作。 |
| 典型实现 | Drools、Easy Rules、Open Policy Agent (OPA)、自研轻量引擎。 |
关键认知：规则引擎不负责数据存储，也不负责服务发现。它的职责是“纯计算”——给定事实与规则，输出决策。这种职责单一性使其在微服务中易于横向扩展。
2.2 服务目录定义
服务目录是微服务架构中的“活地图”。它维护了所有已注册服务的元数据信息，包括服务名称、实例地址、接口端点、健康状态、版本号以及自定义标签（如环境、团队、安全等级）。
- 注册中心：服务启动时向目录注册自身信息，下线时注销。
- 健康检查：定期探测服务实例状态，剔除不健康节点。
- 元数据存储：存储服务间的依赖关系、流量权重、策略标签。
- 查询接口：提供按服务名、标签、版本等维度的实时查询能力。
实践提示：在 Policy Check 体系中，服务目录不仅仅是服务发现工具，更是策略数据的“上下文源”。规则引擎在决策时，经常需要从目录中获取目标服务的安全等级、所属域等信息。
2.3 Policy Check在微服务中的角色
Policy Check 是连接规则引擎与服务目录的“决策执行点”。它在微服务通信链路中扮演着策略执行网关的角色，确保每一次服务间调用都经过策略校验。
其核心职责可归纳为以下四点：
- 拦截请求：在服务间调用（HTTP/gRPC/消息队列）的入口处拦截请求。
- 上下文组装：从请求中提取调用方身份、目标资源、环境信息，并从服务目录中补充目标服务的元数据。
- 策略评估：将组装好的上下文（事实）发送给规则引擎，触发规则匹配。
- 执行决策：根据规则引擎返回的结果，放行、拒绝或降级请求，并记录审计日志。
架构陷阱：Policy Check 不应成为性能瓶颈。它必须设计为无状态、低延迟的旁路组件。如果规则引擎计算耗时超过 5ms，应考虑异步评估或缓存策略结果。
2.4 三者协作关系
规则引擎、服务目录与 Policy Check 并非孤立组件，而是形成了一条完整的策略决策链路：
| 步骤 | 组件 | 动作 | 数据流 |
|---|---|---|---|
| 1 | Policy Check | 拦截服务间调用请求 | 请求头 + 调用方身份 |
| 2 | Policy Check | 向服务目录查询目标服务元数据 | 服务名 → 安全等级、域、标签 |
| 3 | Policy Check | 组装事实上下文 | 调用方角色 + 目标标签 + 环境 |
| 4 | 规则引擎 | 匹配规则集，输出决策 | 事实 → Allow/Deny/Warn |
| 5 | Policy Check | 执行决策并记录审计日志 | 决策结果 → 放行/拒绝 |
架构收益：这种分离设计使得规则变更无需重启服务，服务目录的扩展不影响策略逻辑，Policy Check 可以独立升级。三者各司其职，共同构建可演进的微服务治理体系。