iam-tenant 服务
根据项目分析，这是一个包含 47个微服务 的企业级
ERP 系统。以下是部署和开发顺序：
部署顺序
```
第0层：基础设施
PostgreSQL → Redis → Vault → Etcd → Kafka →
ClickHouse
第1层：核心 IAM 服务（必须最先部署）
顺序: 1
服务: iam-tenant
说明: 租户管理（多租户基础）
────────────────────────────────────────
顺序: 2
服务: iam-identity
说明: 身份认证（用户、OAuth、2FA）
────────────────────────────────────────
顺序: 3
服务: iam-access
说明: 访问控制（RBAC、权限策略）
第2层：系统服务
┌──────┬────────────────┬────────────────────┐
│ 顺序 │ 服务 │ 说明 │
├──────┼────────────────┼────────────────────┤
│ 4 │ sys-core │ 编号范围、配置管理 │
├──────┼────────────────┼────────────────────┤
│ 5 │ sys-notify │ 通知服务 │
├──────┼────────────────┼────────────────────┤
│ 6 │ org-enterprise │ 组织架构 │
└──────┴────────────────┴────────────────────┘
第3层：主数据服务
┌──────┬──────────────┬────────────────┐
│ 顺序 │ 服务 │ 说明 │
├──────┼──────────────┼────────────────┤
│ 7 │ mdm-bp │ 业务伙伴主数据 │
├──────┼──────────────┼────────────────┤
│ 8 │ mdm-material │ 物料主数据 │
└──────┴──────────────┴────────────────┘
第4层：业务服务（可并行部署）
模块: 财务 FI
服务: fi-gl, fi-coa, fi-ap, fi-ar, fi-co, fi-tr
────────────────────────────────────────
模块: 采购 PM
服务: pm-po, pm-ct, pm-se, pm-vs, pm-sa, pm-iv
────────────────────────────────────────
模块: 销售 SD
服务: sd-so, sd-pe, sd-rr, sd-an
────────────────────────────────────────
模块: 供应链 SC
服务: sc-wm, sc-im, sc-tp, sc-df, sc-vs, sc-bt
────────────────────────────────────────
模块: 制造 MF
服务: mf-pp, mf-om, mf-kb, mf-qi, mf-sf, mf-eng
────────────────────────────────────────
模块: 人力 HR
服务: hr-ta, hr-ex
────────────────────────────────────────
模块: 客服 CS
服务: cs-cb, cs-fd, cs-wc
────────────────────────────────────────
模块: 资产 AM
服务: am-pm, am-gs, am-ah, am-eh
────────────────────────────────────────
模块: 研发 RD
服务: rd-pl, rd-ps
第5层：网关
顺序: 最后
服务: gateway
说明: API 网关（路由、认证、限流）
开发顺序
阶段1：基础框架（已完成）
crates/common → crates/errors → crates/config →
crates/telemetry
→ crates/auth-core → crates/domain-core →
crates/cqrs-core
→ crates/event-core → crates/bootstrap
阶段2：适配器层（已完成）
adapter-postgres → adapter-redis → adapter-vault
→ adapter-etcd
→ adapter-kafka → adapter-clickhouse →
adapter-elasticsearch
→ adapter-minio → adapter-email →
adapter-rabbitmq
阶段3：核心服务开发
- iam-tenant ← 当前分支正在开发
- iam-identity ← 已有24个迁移文件
- iam-access ← 已有7个迁移文件
阶段4：系统与主数据
sys-core → sys-notify → org-enterprise → mdm-bp
→ mdm-material
阶段5：业务模块（可并行开发）
按业务优先级选择模块并行开发。
依赖关系图
┌─────────────────┐
│ 基础设施 │
│ PG/Redis/Vault │
│ Kafka/ClickHouse│
└────────┬────────┘
│
┌────────▼────────┐
│ iam-tenant │
└────────┬────────┘
│
┌────────▼────────┐
│ iam-identity │
└────────┬────────┘
│
┌────────▼────────┐
│ iam-access │
└────────┬────────┘
│
┌──────────────────┼──────────────────┐
│ │
│
┌──────▼──────┐ ┌───────▼───────┐
┌──────▼──────┐
│ sys-core │ │ sys-notify │
│org-enterprise│
└──────┬──────┘ └───────────────┘
└─────────────┘
│
┌──────▼──────┐
│ mdm-bp │
│ mdm-material│
└──────┬──────┘
│
┌──────▼─────────────────────────────────────
─────┐
│ 业务服务层
│
│ FI / PM / SD / SC / MF / HR / CS / AM / RD
│
└────────────────────────────────────────────
─────┘
当前 iam-tenant
分支正在开发租户服务，这是正确的开发顺序起点。
```
总结
关键发现：项目中没有使用 Envoy 配置
虽然 README.md 提到使用 Envoy 作为服务网格代理，但实际上 项目中没有 Envoy 配置文件。服务间通信采用
直连模式。
实际的访问方式
1. 网关到 iam-tenant 的连接配置
┌──────────┬────────────────────────┐
│ 配置项 │ 值 │
├──────────┼────────────────────────┤
│ 环境变量 │ TENANT_ENDPOINT │
├──────────┼────────────────────────┤
│ 默认端点 │ http://127.0.0.1:50053 │
├──────────┼────────────────────────┤
│ 协议 │ gRPC (HTTP/2) │
├──────────┼────────────────────────┤
│ 连接超时 │ 10秒 │
├──────────┼────────────────────────┤
│ 请求超时 │ 30秒 │
└──────────┴────────────────────────┘
2. 配置文件位置
- 网关配置: gateway/src/config.rs:8 - tenant_endpoint 字段
- gRPC 客户端: gateway/src/grpc/mod.rs:18 - TenantServiceClient
3. 服务启动
- iam-tenant 使用 bootstrap crate 统一启动
- 配置通过环境变量和 Vault 管理
- services/iam-tenant/config/ 目录为空
当前状态
- REST API 路由已实现 (gateway/src/tenant.rs) 但被注释掉
- gRPC 直连已配置并可用
- 没有 Envoy sidecar 或 bootstrap 配置
如果你需要添加 Envoy 配置，需要创建相应的 envoy.yaml 文件并配置服务发现（Consul）集成。
✻ Baked for 2m 5s
❯ 是要使用dokcer吗 我不打算使用docker
⏺ 根据探索结果，不需要使用 Docker。
当前架构
项目采用的是 直连模式，不依赖 Envoy 或 Docker：
Gateway (网关) --gRPC--> iam-tenant 服务
| |
| |
端口: 配置中指定 端口: 50053
配置方式
只需设置环境变量即可：
# 网关连接 iam-tenant
export TENANT_ENDPOINT="http://127.0.0.1:50053"
# 网关连接 iam-access
export IAM_ENDPOINT="http://127.0.0.1:50051"
本地开发启动
直接运行 Rust 服务：
# 终端 1: 启动 iam-tenant 服务
cd services/iam-tenant
cargo run
# 终端 2: 启动网关
cd gateway
cargo run
结论
- 不需要 Docker
- 不需要 Envoy
- README 中提到的 Envoy/Consul 是规划中的生产架构，但代码中并未实现
- 本地开发直接用 cargo run 启动各服务，通过环境变量配置端点地址即可
问题总结
iam-tenant 服务缺少配置文件，services/iam-tenant/config/ 目录是空的。
这意味着：
1. 服务启动时 AppConfig::load("config") 会失败（找不到 default.toml）
2. 没有定义 server.port，无法知道服务监听哪个端口
3. 网关配置的 TENANT_ENDPOINT=http://127.0.0.1:50053 是硬编码的默认值，但 iam-tenant
服务本身没有配置监听 50053
生产环境的灾难点：
- 服务端口没有统一管理
- 网关用硬编码默认值连接后端服务
- 没有服务发现机制
- 配置分散在代码和环境变量中
需要我为 iam-tenant 创建配置文件吗？参考其他服务的模式，需要创建：
- services/iam-tenant/config/default.toml - 基础配置
- services/iam-tenant/config/development.toml - 开发环境
- services/iam-tenant/config/production.toml - 生产环境
当前架构分析
现状：
1. 每个服务都有自己的 config/ 目录，存放 default.toml、development.toml、production.toml
2. bootstrap 调用 AppConfig::load(config_dir) 从本地文件加载配置
3. Vault 用于敏感信息（数据库密码、JWT secret 等），但服务端口、主机等仍在本地 toml 文件
问题：
- 配置分散在几十个服务的 config/ 目录中
- 服务端口硬编码在各自的 toml 文件里
- 网关用硬编码默认值连接后端（灾难）
- 没有服务注册/发现机制
统一配置方案
有几种选择：
┌────────────────────┬─────────────────────────────────────────────┬────────┐
│ 方案 │ 描述 │ 复杂度 │
├────────────────────┼─────────────────────────────────────────────┼────────┤
│ A. Vault 集中配置 │ 把所有服务配置（包括端口）存入 Vault │ 中 │
├────────────────────┼─────────────────────────────────────────────┼────────┤
│ B. etcd 配置中心 │ 用 etcd 做配置中心 + 服务发现 │ 中高 │
├────────────────────┼─────────────────────────────────────────────┼────────┤
│ C. 根目录统一配置 │ 创建 /config/services.toml 统一管理所有服务 │ 低 │
├────────────────────┼─────────────────────────────────────────────┼────────┤
│ D. Consul 服务发现 │ 用 Consul 做服务注册/发现 │ 高 │
└────────────────────┴─────────────────────────────────────────────┴────────┘
你倾向哪种方案？
考虑到你已经有 Vault 和 etcd 的适配器，方案 A 或 B 可能更适合：
- Vault: 已经用于敏感配置，可以扩展存储服务端点
- etcd: 更适合做配置中心和服务发现，支持 watch 变更
当前状态分析
已有组件
┌────────┬───────────────────┬─────────────────────────────────────┐
│ 组件 │ 状态 │ 用途 │
├────────┼───────────────────┼─────────────────────────────────────┤
│ Vault │ ✅ 已实现 │ 敏感配置（JWT密钥、数据库密码等） │
├────────┼───────────────────┼─────────────────────────────────────┤
│ etcd │ ✅ 已实现 │ KV存储、Watch、分布式锁、租约、事务 │
├────────┼───────────────────┼─────────────────────────────────────┤
│ Consul │ ❌ 仅在README提及 │ 未实现 │
├────────┼───────────────────┼─────────────────────────────────────┤
│ Envoy │ ❌ 仅在README提及 │ 未实现 │
└────────┴───────────────────┴─────────────────────────────────────┘
当前问题
1. 服务发现：网关通过硬编码环境变量连接后端服务
2. 配置管理：分散在环境变量中，缺乏统一管理
3. 健康检查：没有服务级别的健康检查机制
4. 负载均衡：单点直连，无负载均衡
推荐方案：etcd + Envoy
考虑到项目已经有完善的 etcd 适配器，推荐使用 etcd 作为配置中心和服务注册中心，配合 Envoy 做服务代理。
架构设计
┌─────────────────────────────────────────────────────────────────┐
│ 客户端请求 │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Envoy Front Proxy │
│ (HTTP/gRPC 路由、负载均衡、熔断、限流、TLS终止) │
└─────────────────────────────────────────────────────────────────┘
│
┌───────────────────────┼───────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ Gateway │ │ iam-access │ │ iam-tenant │
│ (REST→gRPC) │ │ :50051 │ │ :50053 │
└───────────────┘ └───────────────┘ └───────────────┘
│ │ │
└───────────────────────┼───────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ etcd │
│ - 服务注册 (/services/iam-tenant/instances/xxx) │
│ - 配置管理 (/config/iam-tenant/...) │
│ - 领导选举 (/election/...) │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Vault │
│ (敏感配置：JWT密钥、数据库密码等) │
└─────────────────────────────────────────────────────────────────┘
让我先查看 bootstrap 的实现，了解服务启动流程。
最佳方案：etcd 服务注册/发现 + Vault 敏感配置
为什么选择 etcd 而不是 Consul？
┌─────────────┬────────────────────────────────────────────────┬─────────────────┐
│ 对比项 │ etcd │ Consul │
├─────────────┼────────────────────────────────────────────────┼─────────────────┤
│ 当前状态 │ ✅ 已有完整适配器（KV、Watch、锁、租约、事务） │ ❌ 需要从零开发 │
├─────────────┼────────────────────────────────────────────────┼─────────────────┤
│ 配置管理 │ ✅ 原生支持 │ ✅ 支持 │
├─────────────┼────────────────────────────────────────────────┼─────────────────┤
│ 服务发现 │ ✅ 通过租约+Watch实现 │ ✅ 原生支持 │
├─────────────┼────────────────────────────────────────────────┼─────────────────┤
│ 健康检查 │ 需要自己实现（但 bootstrap 已有） │ 原生支持 │
├─────────────┼────────────────────────────────────────────────┼─────────────────┤
│ 复杂度 │ 中等 │ 较高 │
├─────────────┼────────────────────────────────────────────────┼─────────────────┤
│ 与 K8s 集成 │ ✅ 原生（K8s 就用 etcd） │ 需要额外配置 │
└─────────────┴────────────────────────────────────────────────┴─────────────────┘
结论：etcd 已经具备所有能力，且适配器完善，是最佳选择。
---
架构设计
┌─────────────────────────────────────────────────────────────────────┐
│ 架构总览 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ Client │ │
│ └──────┬──────┘ │
│ │ HTTP/gRPC │
│ ▼ │
│ ┌─────────────┐ 服务发现 ┌─────────────┐ │
│ │ Gateway │◄────────────────────►│ etcd │ │
│ │ :8080 │ (Watch) │ 配置中心 │ │
│ └──────┬──────┘ │ 服务注册 │ │
│ │ └──────┬──────┘ │
│ │ gRPC (动态端点) │ │
│ ▼ │ │
│ ┌─────────────────────────────────────┐ │ │
│ │ 微服务集群 │ │ │
│ │ ┌───────────┐ ┌───────────┐ │ │ │
│ │ │iam-access │ │iam-tenant │ ... │◄───┘ 服务注册 │
│ │ │ :50051 │ │ :50053 │ │ (租约+心跳) │
│ │ └───────────┘ └───────────┘ │ │
│ └
当前网关的问题
gateway/src/config.rs:
iam_endpoint: env::var("IAM_ENDPOINT").unwrap_or_else(|_| "http://127.0.0.1:50051".to_string())
tenant_endpoint: env::var("TENANT_ENDPOINT").unwrap_or_else(|_|
"http://127.0.0.1:50053".to_string())
gateway/src/main.rs:103-108:
let grpc_clients = grpc::GrpcClients::new_multi(
config.iam_endpoint.clone(),
config.tenant_endpoint.clone()
).await.expect("Failed to connect to services");
问题：
1. 服务端点是硬编码的环境变量默认值
2. 启动时一次性连接，没有动态发现
3. 服务挂了或迁移了，网关不知道
4. 新增服务需要改代码添加新的 endpoint 配置
---
最佳方案：etcd 服务注册/发现
架构图
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────┐ HTTP/gRPC ┌──────────────────┐ │
│ │ Client │ ──────────────────────────►│ Gateway │ │
│ └──────────┘ │ :8080 │ │
│ └────────┬─────────┘ │
│ │ │
│ ┌──────────────────────┼──────────────┤
│ │ │ │
│ │ Watch 服务变更 │ gRPC 调用 │
│ │ /services/* │ (动态端点) │
│ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ etcd │ │
│ │ │ │
│ │ /services/iam-access/instances/uuid1 = {host, port, ...} │ │
│ │ /services/iam-tenant/instances/uuid2 = {host, port, ...} │ │
│ │ /services/gateway/instances/uuid3 = {host, port, ...} │ │
│ │ │ │
│ │ /config/gateway/... = {...} │ │
│ │ /config/iam-tenant/... = {...} │ │
│ │ │ │
│ └──────────────────────────────────────▲──────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────┼─────────────────────┐ │
│ │ │ │ │
│ │ 服务注册 (租约 + 心跳) │ │ │
│ │ │ │ │
│ ┌────┴─────┐ ┌───────────┐ ┌─────┴─────┐ │ │
│ │iam-access│ │iam-tenant │ │ 其他服务 │ │ │
│ │ :50051 │ │ :50053 │ │ ... │ │ │
│ └──────────┘ └───────────┘ └───────────┘ │ │
│ │
└─────────────────────────────────────────────────────────────────────┘
需要实现的组件
┌──────────────────┬───────────────────────────────────────┬────────────────────────┐
│ 组件 │ 位置 │ 功能 │
├──────────────────┼───────────────────────────────────────┼────────────────────────┤
│ ServiceRegistry │ crates/adapters/etcd/src/registry.rs │ 服务注册（租约+心跳） │
├──────────────────┼───────────────────────────────────────┼────────────────────────┤
│ ServiceDiscovery │ crates/adapters/etcd/src/discovery.rs │ 服务发现（Watch+缓存） │
├──────────────────┼───────────────────────────────────────┼────────────────────────┤
│ bootstrap 集成 │ bootstrap/src/starter.rs │ 启动时自动注册 │
├──────────────────┼───────────────────────────────────────┼────────────────────────┤
│ gateway 集成 │ gateway/src/grpc/mod.rs │ 动态获取服务端点 │
└──────────────────┴───────────────────────────────────────┴────────────────────────┘
etcd 键结构设计
/services/{service_name}/instances/{instance_id}
└── JSON: {
"id": "uuid",
"name": "iam-tenant",
"host": "192.168.1.10",
"port": 50053,
"health_port": 51053,
"status": "healthy",
"metadata": {
"version": "1.0.0",
"region": "cn-east"
},
"registered_at": "2024-01-01T00:00:00Z"
}
/config/{env}/{service_name}/...
└── 服务配置（非敏感）
---
要我开始实现这个方案吗？需要：
1. 扩展 etcd 适配器 - 添加 ServiceRegistry 和 ServiceDiscovery
2. 修改 bootstrap - 服务启动时自动注册到 etcd
3. 修改 gateway - 从 etcd 动态获取服务端点，Watch 变更
4. 删除各服务的 config/ 目录 - 统一使用 etcd 配置
完成总结
已成功实现 etcd 服务注册/发现 方案，以下是完成的工作：
1. 扩展 etcd 适配器
新增文件：
- crates/adapters/etcd/src/registry.rs - 服务注册模块
- ServiceInstance - 服务实例数据结构
- ServiceRegistry - 服务注册器（租约、心跳、注销）
- RegistryConfig - 注册配置
- crates/adapters/etcd/src/discovery.rs - 服务发现模块
- ServiceDiscovery - 服务发现器（缓存、Watch、负载均衡）
- ServiceDiscoveryBuilder - 构建器模式
- LoadBalanceStrategy - 轮询/随机/首个
2. 修改 bootstrap
新增文件：
- bootstrap/src/service_registry.rs - 服务注册管理器
修改文件：
- bootstrap/src/starter.rs - run() 函数现在会：
- 启动时自动注册服务到 etcd
- graceful shutdown 时自动注销
3. 修改 gateway
新增文件：
- gateway/src/discovery.rs - 服务发现管理器
修改文件：
- gateway/src/config.rs - 添加 etcd 配置
- gateway/src/main.rs - 集成服务发现
4. iam-tenant 配置
新增文件：
- services/iam-tenant/config/default.toml
- services/iam-tenant/config/development.toml
- services/iam-tenant/config/production.toml
- scripts/init-etcd-config.sh
---
使用方式
本地开发（不使用 etcd）：
# 直接启动，使用静态配置
cargo run -p iam-tenant
cargo run -p gateway
生产环境（使用 etcd）：
# 1. 初始化 etcd 配置
./scripts/init-etcd-config.sh prod
# 2. 启动服务（自动注册到 etcd）
ETCD_ENDPOINTS
✻ Brewed for 13m 15s
❯ 继续
⏺ 好的，让我继续完善说明文档。
生产环境（使用 etcd）：
# 1. 初始化 etcd 配置
./scripts/init-etcd-config.sh prod
# 2. 启动服务（自动注册到 etcd）
export ETCD_ENDPOINTS="http://etcd1:2379,http://etcd2:2379,http://etcd3:2379"
cargo run -p iam-tenant
cargo run -p iam-access
# 3. 启动网关（自动从 etcd 发现服务）
export ETCD_ENDPOINTS="http://etcd1:2379,http://etcd2:2379,http://etcd3:2379"
export ENABLE_SERVICE_DISCOVERY=true
cargo run -p gateway
---
架构流程
服务启动流程:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ bootstrap │────►│ etcd │◄────│ gateway │
│ run() │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
│ ▲ │
│ 1. 注册服务 │ 3. Watch │ 2. 发现服务
│ (租约+心跳) │ 服务变更 │ 获取端点
▼ │ ▼
┌─────────────┐ │ ┌─────────────┐
│ iam-tenant │───────────┘ │ gRPC 调用 │
│ :50053 │◄───────────────────────│ │
└─────────────┘ └─────────────┘
etcd 键结构
/services/
├── iam-access/
│ └── instances/
│ └── {uuid} → {"host":"192.168.1.10","port":50051,"status":"healthy",...}
├── iam-tenant/
│ └── instances/
│ └── {uuid} → {"host":"192.168.1.11","port":50053,"status":"healthy",...}
└── gateway/
└── instances/
└── {uuid} → {"host":"192.168.1.12","port":8080,"status":"healthy",...}
环境变量
┌──────────────────────────┬───────────────────────────┬───────────────────────┐
│ 变量 │ 说明 │ 示例 │
├──────────────────────────┼───────────────────────────┼───────────────────────┤
│ ETCD_ENDPOINTS │ etcd 端点列表（逗号分隔） │ http://localhost:2379 │
├──────────────────────────┼───────────────────────────┼───────────────────────┤
│ ENABLE_SERVICE_DISCOVERY │ 是否启用服务发现 │ true │
├──────────────────────────┼───────────────────────────┼───────────────────────┤
│ SERVICE_HOST │ 服务注册时使用的主机地址 │ 192.168.1.10 │
├──────────────────────────┼───────────────────────────┼───────────────────────┤
│ POD_IP │ K8s Pod IP（自动检测） │ - │
└──────────────────────────┴───────────────────────────┴───────────────────────┘
---
这个方案的优点：
1. 向后兼容 - 不配置 etcd 时使用静态端点
2. 自动注册 - 服务启动时自动注册，关闭时自动注销
3. 心跳续约 - 30秒租约，10秒心跳，服务挂掉自动剔除
4. 动态发现 - gateway Watch 服务变更，实时更新
5. 负载均衡 - 支持轮询、随机、首个可用策略
构建结果
✅ bootstrap - 编译成功
✅ gateway - 编译成功 (7 warnings)
✅ iam-tenant - 编译成功 (35 warnings)
所有核心组件都已成功构建。警告主要是：
- gateway: 一些未使用的导入和方法（预留的功能）
- iam-tenant: 大量未使用的领域方法和仓库方法（服务还在开发中）
gRPC 服务实现已经完成了所有 23 个 RPC 方法。让我总结一下当前状态：
gRPC 服务实现状态
已实现的 23 个 RPC 方法：
分类: 租户 CRUD
方法: CreateTenant, GetTenant, UpdateTenant, DeleteTenant, ListTenants
状态: ✅
────────────────────────────────────────
分类: 生命周期
方法: ActivateTenant, SuspendTenant, StartTrial
状态: ✅
────────────────────────────────────────
分类: 订阅管理
方法: CreateSubscription, GetSubscription, UpgradeSubscription, DowngradeSubscription
状态: ✅
────────────────────────────────────────
分类: 配额管理
方法: CheckQuota, UpdateQuota, GetQuota, ListQuotas
状态: ✅
────────────────────────────────────────
分类: 特性开关
方法: CheckFeatureEnabled, GetFeatureFlag, ToggleFeature
状态: ✅
────────────────────────────────────────
分类: 租户配置
方法: GetConfig, UpdateConfig
状态: ✅
────────────────────────────────────────
分类: 跨服务集成
方法: GetTenantStatus, BatchGetTenantStatus
状态: ✅
编译警告分析：
警告主要来自领域层中尚未通过 gRPC 暴露的方法：
- resume() - 恢复租户
- mark_payment_overdue() - 标记付款逾期
- start_offboarding() - 开始下线流程
- archive() - 归档租户
- delete() - 删除租户（硬删除）
- set_custom_domain() - 设置自定义域名
- migrate_region() - 迁移区域
这些是 8 状态状态机的一部分，但尚未有对应的 gRPC 接口。
下一步选择：
1. 扩展 gRPC 接口 - 为上述领域方法添加 RPC 定义和实现
2. 清理警告 - 暂时用 #[allow(dead_code)] 标记或移除未使用代码
3. 继续 Gateway 集成 - 当前 gRPC 服务已可用
4. 添加测试 - 为已实现的方法编写测试
浙公网安备 33010602011771号