611 lines
16 KiB
Markdown
611 lines
16 KiB
Markdown
# 天远 API 服务器重构方案
|
||
|
||
## 🎯 重构目标
|
||
|
||
1. **提高代码可维护性** - 清晰的业务边界和模块划分
|
||
2. **增强系统扩展性** - 松耦合的微服务架构
|
||
3. **改善开发效率** - 标准化的开发流程和工具链
|
||
4. **提升系统可靠性** - 完善的监控、测试和部署体系
|
||
|
||
## 🏗️ 架构重构
|
||
|
||
### 1. 业务域重新设计 (DDD)
|
||
|
||
```
|
||
新的业务域架构：
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ API Gateway │
|
||
│ (统一入口网关) │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
│
|
||
┌──────────────┼──────────────┐
|
||
│ │ │
|
||
┌───────────────▼──┐ ┌─────────▼──────┐ ┌────▼──────────┐
|
||
│ 用户域服务 │ │ 金融域服务 │ │ 数据服务域 │
|
||
│ (User Domain) │ │(Financial Domain)│ │(Data Domain) │
|
||
├─────────────────┤ ├─────────────────┤ ├──────────────┤
|
||
│• 用户认证 │ │• 钱包管理 │ │• 风险评估 │
|
||
│• 用户信息 │ │• 支付处理 │ │• 征信查询 │
|
||
│• 企业认证 │ │• 计费结算 │ │• 企业信息 │
|
||
│• 权限管理 │ │• 财务报表 │ │• 数据查询 │
|
||
└─────────────────┘ └─────────────────┘ └──────────────┘
|
||
│
|
||
┌──────────────┼──────────────┐
|
||
│ │ │
|
||
┌───────────────▼──┐ ┌─────────▼──────┐ ┌────▼──────────┐
|
||
│ 产品域服务 │ │ 平台域服务 │ │ 基础设施域 │
|
||
│(Product Domain) │ │(Platform Domain)│ │(Infra Domain) │
|
||
├─────────────────┤ ├─────────────────┤ ├──────────────┤
|
||
│• 产品目录 │ │• 管理后台 │ │• 消息队列 │
|
||
│• 产品订阅 │ │• 系统监控 │ │• 缓存服务 │
|
||
│• 访问控制 │ │• 日志管理 │ │• 配置中心 │
|
||
│• 白名单管理 │ │• 运维工具 │ │• 服务发现 │
|
||
└─────────────────┘ └─────────────────┘ └──────────────┘
|
||
```
|
||
|
||
### 2. 微服务重新设计
|
||
|
||
#### 用户域 (User Domain)
|
||
|
||
```go
|
||
// 用户认证服务
|
||
user-auth-service/
|
||
├── api/
|
||
│ ├── auth.proto # gRPC 接口定义
|
||
│ └── auth.api # HTTP 接口定义
|
||
├── internal/
|
||
│ ├── domain/ # 领域模型
|
||
│ ├── application/ # 应用服务
|
||
│ ├── infrastructure/ # 基础设施
|
||
│ └── interfaces/ # 接口适配器
|
||
└── cmd/
|
||
└── main.go
|
||
|
||
// 企业认证服务
|
||
enterprise-service/
|
||
├── api/
|
||
├── internal/
|
||
└── cmd/
|
||
```
|
||
|
||
#### 金融域 (Financial Domain)
|
||
|
||
```go
|
||
// 钱包服务
|
||
wallet-service/
|
||
├── api/
|
||
├── internal/
|
||
│ ├── domain/
|
||
│ │ ├── wallet/ # 钱包聚合根
|
||
│ │ ├── transaction/ # 交易实体
|
||
│ │ └── balance/ # 余额值对象
|
||
│ ├── application/
|
||
│ └── infrastructure/
|
||
└── cmd/
|
||
|
||
// 支付服务
|
||
payment-service/
|
||
├── api/
|
||
├── internal/
|
||
└── cmd/
|
||
```
|
||
|
||
#### 数据服务域 (Data Service Domain)
|
||
|
||
```go
|
||
// 统一数据服务网关
|
||
data-gateway-service/
|
||
├── api/
|
||
├── internal/
|
||
│ ├── adapters/ # 第三方数据源适配器
|
||
│ │ ├── westdex/ # 西部数据源
|
||
│ │ ├── baidu/ # 百度接口
|
||
│ │ └── aliyun/ # 阿里云接口
|
||
│ ├── domain/
|
||
│ │ ├── query/ # 查询服务
|
||
│ │ ├── risk/ # 风险评估
|
||
│ │ └── credit/ # 征信服务
|
||
│ └── application/
|
||
└── cmd/
|
||
```
|
||
|
||
#### 产品域 (Product Domain)
|
||
|
||
```go
|
||
// 产品管理服务
|
||
product-service/
|
||
├── api/
|
||
├── internal/
|
||
│ ├── domain/
|
||
│ │ ├── product/ # 产品聚合根
|
||
│ │ ├── subscription/ # 订阅实体
|
||
│ │ └── access/ # 访问控制
|
||
│ └── application/
|
||
└── cmd/
|
||
```
|
||
|
||
## 🛠️ 技术重构
|
||
|
||
### 1. 代码结构标准化
|
||
|
||
**采用六边形架构 (Hexagonal Architecture)**：
|
||
|
||
```go
|
||
service/
|
||
├── api/ # 接口定义
|
||
│ ├── grpc/ # gRPC 协议
|
||
│ ├── http/ # HTTP 协议
|
||
│ └── event/ # 事件协议
|
||
├── internal/
|
||
│ ├── domain/ # 领域层
|
||
│ │ ├── entity/ # 实体
|
||
│ │ ├── valueobject/ # 值对象
|
||
│ │ ├── aggregate/ # 聚合根
|
||
│ │ ├── repository/ # 仓储接口
|
||
│ │ └── service/ # 领域服务
|
||
│ ├── application/ # 应用层
|
||
│ │ ├── command/ # 命令处理
|
||
│ │ ├── query/ # 查询处理
|
||
│ │ ├── dto/ # 数据传输对象
|
||
│ │ └── service/ # 应用服务
|
||
│ ├── infrastructure/ # 基础设施层
|
||
│ │ ├── persistence/ # 持久化
|
||
│ │ ├── messaging/ # 消息传递
|
||
│ │ ├── external/ # 外部服务
|
||
│ │ └── config/ # 配置
|
||
│ └── interfaces/ # 接口适配器层
|
||
│ ├── grpc/ # gRPC 适配器
|
||
│ ├── http/ # HTTP 适配器
|
||
│ ├── event/ # 事件适配器
|
||
│ └── cli/ # 命令行适配器
|
||
├── pkg/ # 共享包
|
||
├── test/ # 测试
|
||
├── docs/ # 文档
|
||
├── deployments/ # 部署配置
|
||
├── Dockerfile
|
||
└── go.mod
|
||
```
|
||
|
||
### 2. 技术栈升级
|
||
|
||
**推荐的技术栈**：
|
||
|
||
```yaml
|
||
# 微服务框架
|
||
framework: go-zero v1.6+ 或 go-kit v0.12+
|
||
|
||
# 数据库
|
||
database:
|
||
- PostgreSQL 15+ (替代MySQL, 更好的JSON支持)
|
||
- Redis 7+ (缓存和会话)
|
||
- ClickHouse (日志和分析)
|
||
|
||
# 消息队列
|
||
messaging:
|
||
- Apache Kafka 3.0+ (事件流)
|
||
- RabbitMQ 3.11+ (任务队列)
|
||
|
||
# 服务治理
|
||
service_mesh: Istio 1.17+
|
||
service_discovery: Consul 1.15+
|
||
configuration: Consul KV 或 etcd
|
||
|
||
# 监控和可观测性
|
||
monitoring:
|
||
- Prometheus + Grafana
|
||
- Jaeger (分布式追踪)
|
||
- ELK Stack (日志)
|
||
- SkyWalking (APM)
|
||
|
||
# 安全
|
||
security:
|
||
- Vault (密钥管理)
|
||
- OPA (策略引擎)
|
||
- Keycloak (身份认证)
|
||
```
|
||
|
||
## 📊 数据层重构
|
||
|
||
### 1. 数据库重新设计
|
||
|
||
**按业务域分离数据库**：
|
||
|
||
```sql
|
||
-- 用户域数据库
|
||
user_db:
|
||
- users
|
||
- user_profiles
|
||
- user_sessions
|
||
- enterprise_auth
|
||
|
||
-- 金融域数据库
|
||
financial_db:
|
||
- wallets
|
||
- transactions
|
||
- payment_orders
|
||
- billing_records
|
||
|
||
-- 产品域数据库
|
||
product_db:
|
||
- products
|
||
- product_subscriptions
|
||
- access_policies
|
||
- whitelists
|
||
|
||
-- 平台域数据库
|
||
platform_db:
|
||
- api_logs
|
||
- system_configs
|
||
- admin_users
|
||
- audit_logs
|
||
```
|
||
|
||
### 2. 数据一致性策略
|
||
|
||
**事件驱动架构**：
|
||
|
||
```go
|
||
// 事件定义
|
||
type UserRegistered struct {
|
||
UserID int64 `json:"user_id"`
|
||
Username string `json:"username"`
|
||
Email string `json:"email"`
|
||
Timestamp time.Time `json:"timestamp"`
|
||
}
|
||
|
||
type WalletCreated struct {
|
||
UserID int64 `json:"user_id"`
|
||
WalletID string `json:"wallet_id"`
|
||
Balance float64 `json:"balance"`
|
||
Timestamp time.Time `json:"timestamp"`
|
||
}
|
||
|
||
// 事件处理
|
||
func (h *WalletEventHandler) HandleUserRegistered(event UserRegistered) error {
|
||
// 为新用户创建钱包
|
||
return h.walletService.CreateWallet(event.UserID)
|
||
}
|
||
```
|
||
|
||
## 🔧 开发流程重构
|
||
|
||
### 1. 代码生成和模板
|
||
|
||
**统一的代码生成器**：
|
||
|
||
```bash
|
||
# 使用 protobuf 和 API 定义生成代码
|
||
make generate-service name=user-auth
|
||
make generate-api name=wallet
|
||
|
||
# 生成的目录结构
|
||
generated/
|
||
├── user-auth-service/
|
||
│ ├── pb/ # protobuf 生成
|
||
│ ├── client/ # 客户端代码
|
||
│ ├── server/ # 服务端代码
|
||
│ └── mock/ # 测试桩
|
||
```
|
||
|
||
### 2. 测试策略
|
||
|
||
**多层次测试**：
|
||
|
||
```go
|
||
// 单元测试
|
||
func TestWalletService_Transfer(t *testing.T) {
|
||
// 领域逻辑测试
|
||
}
|
||
|
||
// 集成测试
|
||
func TestWalletAPI_Transfer(t *testing.T) {
|
||
// API 集成测试
|
||
}
|
||
|
||
// 契约测试
|
||
func TestWalletService_Contract(t *testing.T) {
|
||
// 服务间契约测试
|
||
}
|
||
|
||
// 端到端测试
|
||
func TestTransferWorkflow(t *testing.T) {
|
||
// 完整业务流程测试
|
||
}
|
||
```
|
||
|
||
### 3. CI/CD 流水线
|
||
|
||
**GitOps 工作流**：
|
||
|
||
```yaml
|
||
# .github/workflows/service.yml
|
||
name: Service CI/CD
|
||
on:
|
||
push:
|
||
paths: ["services/user-auth/**"]
|
||
pull_request:
|
||
paths: ["services/user-auth/**"]
|
||
|
||
jobs:
|
||
test:
|
||
runs-on: ubuntu-latest
|
||
steps:
|
||
- uses: actions/checkout@v3
|
||
- name: Run tests
|
||
run: make test-user-auth
|
||
|
||
build:
|
||
needs: test
|
||
runs-on: ubuntu-latest
|
||
steps:
|
||
- name: Build image
|
||
run: make build-user-auth
|
||
- name: Push to registry
|
||
run: make push-user-auth
|
||
|
||
deploy:
|
||
needs: build
|
||
runs-on: ubuntu-latest
|
||
if: github.ref == 'refs/heads/main'
|
||
steps:
|
||
- name: Deploy to staging
|
||
run: make deploy-user-auth-staging
|
||
```
|
||
|
||
## 📱 API 设计重构
|
||
|
||
### 1. RESTful API 标准化
|
||
|
||
**统一的 API 设计规范**：
|
||
|
||
```go
|
||
// 资源命名
|
||
GET /api/v1/users # 获取用户列表
|
||
GET /api/v1/users/{id} # 获取用户详情
|
||
POST /api/v1/users # 创建用户
|
||
PUT /api/v1/users/{id} # 更新用户
|
||
DELETE /api/v1/users/{id} # 删除用户
|
||
|
||
// 子资源
|
||
GET /api/v1/users/{id}/wallets # 获取用户钱包
|
||
POST /api/v1/users/{id}/wallets # 创建用户钱包
|
||
|
||
// 统一响应格式
|
||
type APIResponse struct {
|
||
Code int `json:"code"`
|
||
Message string `json:"message"`
|
||
Data interface{} `json:"data,omitempty"`
|
||
Meta *Meta `json:"meta,omitempty"`
|
||
}
|
||
|
||
type Meta struct {
|
||
Page int `json:"page,omitempty"`
|
||
PerPage int `json:"per_page,omitempty"`
|
||
Total int `json:"total,omitempty"`
|
||
TotalPages int `json:"total_pages,omitempty"`
|
||
}
|
||
```
|
||
|
||
### 2. GraphQL 支持
|
||
|
||
**为复杂查询提供 GraphQL**：
|
||
|
||
```graphql
|
||
type User {
|
||
id: ID!
|
||
username: String!
|
||
email: String!
|
||
wallet: Wallet
|
||
subscriptions: [ProductSubscription!]!
|
||
}
|
||
|
||
type Query {
|
||
user(id: ID!): User
|
||
users(filter: UserFilter, pagination: Pagination): UserConnection
|
||
}
|
||
|
||
type Mutation {
|
||
createUser(input: CreateUserInput!): User!
|
||
updateUser(id: ID!, input: UpdateUserInput!): User!
|
||
}
|
||
```
|
||
|
||
## 🔒 安全重构
|
||
|
||
### 1. 认证授权统一化
|
||
|
||
**OAuth 2.0 + RBAC**：
|
||
|
||
```go
|
||
// 角色定义
|
||
type Role struct {
|
||
ID int64 `json:"id"`
|
||
Name string `json:"name"`
|
||
Permissions []Permission `json:"permissions"`
|
||
}
|
||
|
||
type Permission struct {
|
||
ID int64 `json:"id"`
|
||
Resource string `json:"resource"` // users, wallets, products
|
||
Action string `json:"action"` // read, write, delete
|
||
Scope string `json:"scope"` // own, team, all
|
||
}
|
||
|
||
// 中间件
|
||
func AuthMiddleware() gin.HandlerFunc {
|
||
return func(c *gin.Context) {
|
||
token := extractToken(c)
|
||
claims, err := validateToken(token)
|
||
if err != nil {
|
||
c.AbortWithStatus(http.StatusUnauthorized)
|
||
return
|
||
}
|
||
|
||
user, err := getUserFromClaims(claims)
|
||
if err != nil {
|
||
c.AbortWithStatus(http.StatusForbidden)
|
||
return
|
||
}
|
||
|
||
c.Set("user", user)
|
||
c.Next()
|
||
}
|
||
}
|
||
```
|
||
|
||
### 2. 数据安全
|
||
|
||
**端到端加密 + 数据脱敏**：
|
||
|
||
```go
|
||
// 字段级加密
|
||
type User struct {
|
||
ID int64 `json:"id"`
|
||
Username string `json:"username"`
|
||
Email string `json:"email" encrypt:"true"`
|
||
Phone string `json:"phone" encrypt:"true" mask:"***-****-####"`
|
||
}
|
||
|
||
// 自动加密解密
|
||
func (u *User) BeforeSave() error {
|
||
return encrypt.EncryptStruct(u)
|
||
}
|
||
|
||
func (u *User) AfterFind() error {
|
||
return encrypt.DecryptStruct(u)
|
||
}
|
||
```
|
||
|
||
## 📈 监控和可观测性
|
||
|
||
### 1. 分布式追踪
|
||
|
||
**OpenTelemetry 集成**：
|
||
|
||
```go
|
||
func (s *UserService) CreateUser(ctx context.Context, req *pb.CreateUserRequest) (*pb.User, error) {
|
||
span := trace.SpanFromContext(ctx)
|
||
span.SetAttributes(
|
||
attribute.String("user.username", req.Username),
|
||
attribute.String("operation", "create_user"),
|
||
)
|
||
|
||
// 业务逻辑
|
||
user, err := s.userRepo.Create(ctx, req)
|
||
if err != nil {
|
||
span.RecordError(err)
|
||
span.SetStatus(codes.Error, err.Error())
|
||
return nil, err
|
||
}
|
||
|
||
// 发送事件
|
||
event := UserCreatedEvent{UserID: user.ID, Username: user.Username}
|
||
if err := s.eventBus.Publish(ctx, event); err != nil {
|
||
s.logger.Error("failed to publish event", zap.Error(err))
|
||
}
|
||
|
||
return user, nil
|
||
}
|
||
```
|
||
|
||
### 2. 业务指标监控
|
||
|
||
**自定义业务指标**：
|
||
|
||
```go
|
||
var (
|
||
userRegistrations = prometheus.NewCounterVec(
|
||
prometheus.CounterOpts{
|
||
Name: "user_registrations_total",
|
||
Help: "Total number of user registrations",
|
||
},
|
||
[]string{"source", "status"},
|
||
)
|
||
|
||
walletBalance = prometheus.NewGaugeVec(
|
||
prometheus.GaugeOpts{
|
||
Name: "wallet_balance",
|
||
Help: "Current wallet balance",
|
||
},
|
||
[]string{"user_id", "currency"},
|
||
)
|
||
)
|
||
```
|
||
|
||
## 🚀 迁移策略
|
||
|
||
### 阶段 1: 基础设施准备 (1-2 周)
|
||
|
||
1. 搭建新的开发环境
|
||
2. 建立 CI/CD 流水线
|
||
3. 配置监控和日志系统
|
||
|
||
### 阶段 2: 用户域重构 (2-3 周)
|
||
|
||
1. 重构用户认证服务
|
||
2. 迁移用户数据
|
||
3. 更新客户端集成
|
||
|
||
### 阶段 3: 金融域重构 (2-3 周)
|
||
|
||
1. 重构钱包服务
|
||
2. 重构支付服务
|
||
3. 数据一致性验证
|
||
|
||
### 阶段 4: 数据服务域重构 (3-4 周)
|
||
|
||
1. 重构数据网关
|
||
2. 重新组织业务 API
|
||
3. 性能优化
|
||
|
||
### 阶段 5: 产品域重构 (1-2 周)
|
||
|
||
1. 重构产品管理
|
||
2. 重构访问控制
|
||
3. 清理遗留代码
|
||
|
||
### 阶段 6: 平台域完善 (1-2 周)
|
||
|
||
1. 完善管理后台
|
||
2. 优化监控系统
|
||
3. 性能调优
|
||
|
||
## 📋 重构检查清单
|
||
|
||
### 代码质量
|
||
|
||
- [ ] 代码覆盖率 > 80%
|
||
- [ ] 静态代码分析通过
|
||
- [ ] API 文档完整
|
||
- [ ] 性能基准测试
|
||
|
||
### 架构质量
|
||
|
||
- [ ] 服务间松耦合
|
||
- [ ] 明确的业务边界
|
||
- [ ] 数据一致性保证
|
||
- [ ] 容错和恢复机制
|
||
|
||
### 运维质量
|
||
|
||
- [ ] 自动化部署
|
||
- [ ] 监控告警完整
|
||
- [ ] 日志可追溯
|
||
- [ ] 备份恢复测试
|
||
|
||
### 安全质量
|
||
|
||
- [ ] 认证授权机制
|
||
- [ ] 数据加密传输
|
||
- [ ] 漏洞扫描通过
|
||
- [ ] 安全策略文档
|
||
|
||
## 🎯 预期收益
|
||
|
||
1. **开发效率提升 40%** - 通过标准化和自动化
|
||
2. **系统可靠性提升 60%** - 通过完善的测试和监控
|
||
3. **维护成本降低 50%** - 通过清晰的架构和文档
|
||
4. **新功能交付速度提升 3 倍** - 通过模块化设计
|
||
|
||
重构是一个渐进的过程，建议分阶段实施，确保每个阶段都有明确的交付物和验收标准。
|