CangLu Knowledge Base

总览

5分钟阅读

总览

airsky 总索引 | 工程架构分析 索引

评审日期：2026-05-31 ｜ 范围：仓库组织 / 后端微服务与网关 / 分层 / 多租户 / 部署 / 前端 / 安全 / 测试 依据：本仓库实际代码与配置，结论均标注文件/行号（见 事实锚点索引）

图清单

核心结论

AirSky 是面向 B2B 外贸的中台系统，工程素养不错：领域划分清晰、分层统一、测试覆盖高、多租户行级隔离有中间件兜底。

但从微服务最佳实践看，当前本质是 分布式单体：9 个服务共享同一 Go module、同一套实体层、同一个 MySQL 库；service 层之间是编译期跨域直接调用；部署上 9 个二进制塞进同一容器由一个脚本批量拉起。结果是付出了微服务的复杂度，却没拿到独立部署、独立伸缩、故障隔离的收益。

一句话：模块化单体的代码 + 微服务的部署外壳。要么承认它是模块化单体（更省心），要么补齐真正的服务边界（更彻底），骑墙的中间态成本最高。

现状评分

维度评分简评
领域划分 / 模块边界★★★★☆域目录清晰，但 service 层跨域直连削弱边界
分层规范★★★☆☆handler→service 统一，但缺 repository，service 直接持有 DB
部署架构★★☆☆☆单容器跑 9 进程，违背独立部署初衷
网关能力★★☆☆☆仅反向代理，无统一鉴权/限流/熔断
配置与密钥★★☆☆☆配置治理存在风险，需完成敏感配置外置与示例值脱敏
测试工程★★★★☆覆盖率高，本项目最大亮点
CI/CD★☆☆☆☆无任何流水线，全靠手动脚本
前端工程★★★★☆Vue3+TS+Vite 现代栈，结构规整

技术栈与规模

  • 后端：Go 1.25 + Gin + gin_core 框架 + GORM，约 32000 行（不含 vendor/测试），60 handler + 68 service。
  • 前端：Vue 3.5 + TypeScript 6 + Vite 6 + Element Plus + Pinia + ECharts，170 个 .vue，13 个 API 模块。
  • AI 服务：Node.js + Egg.js + LangChain（独立进程 8090）。
  • 基础设施：MySQL 8 / Redis / RabbitMQ / Elasticsearch / MinIO。
  • 测试：后端 110 个 _test.go，前端 70 个测试 + Playwright E2E。

1. 整体架构图

flowchart TD
  FE[前端 Vue3 SPA<br/>Nginx 8989]
  GW[网关 8080<br/>仅反向代理]
  subgraph C[同一后端容器 9 进程]
    AUTH[auth 8081]
    SYS[system 8088]
    CRM[crm 8082]
    TRADE[trade 8083]
    SUPPLY[supply 8084]
    FIN[finance 8085]
    ANA[analytics 8086]
    ADMIN[admin 8087]
  end
  AI[ai-service 8090<br/>独立容器]
  DB[(MySQL 单库 airsky)]
  RDS[(Redis)]

  FE --> GW
  GW --> AUTH
  GW --> SYS
  GW --> CRM
  GW --> TRADE
  GW --> SUPPLY
  GW --> FIN
  GW --> ANA
  GW --> ADMIN
  GW --> AI
  AUTH --> DB
  CRM --> DB
  TRADE --> DB
  ANA --> DB
  CRM --> RDS

说明：网关按 /api/v1/{域} 前缀静态路由转发，仅做代理，不做鉴权/限流。鉴权下沉到每个业务服务。所有业务服务共享同一个 MySQL 库 airsky。

2. 分布式单体的耦合关系

flowchart TD
  TRADE[trade 服务]
  CRM[crm 服务]
  SYS[system 服务]
  LOG[logistics 包]
  COMM[communication 包]

  TRADE -->|编译期 import| CRM
  TRADE -->|编译期 import| LOG
  TRADE -->|编译期 import| SYS
  CRM -->|编译期 import| COMM
  CRM -->|编译期 import| SYS

说明：跨域调用走的是进程内函数调用而非服务间 RPC。这意味着 trade 进程里链接了 crm 的全部代码，无法真正独立部署。详见 改进建议 的架构定调部分。

关键事实

  • 嵌套 Git + 文档不一致：backend/、frontend/ 是裸嵌套仓库（无 submodule）；ai-service/ 被 compose 引用但根目录不存在，直接 compose up 会构建失败。
  • 网关仅转发：gateway/router.go 静态路由表 + 反向代理，无鉴权/限流/熔断。
  • 无 repository 层：service 直接 app.DB.Model(...)，与 GORM 和表名强耦合。
  • 敏感配置治理不足：部分配置与示例值存在公开仓库不宜暴露的风险，建议统一改为环境变量占位并完成轮换。
  • 无 CI/CD：高质量测试资产没有任何流水线自动利用。

关系图谱