1. 项目背景与核心目标
去年接手这个项目时，客户只给了一个模糊的需求方向："做一个能解决实际问题的系统"。经过三个月的需求梳理和技术验证，我们最终确定要开发一套面向中小型制造企业的生产管理平台。这个项目的特别之处在于，我们需要从零开始搭建整个技术架构，同时还要兼顾客户快速迭代的需求。
这个系列文章会完整记录从技术选型到上线的全过程。作为项目负责人，我不仅要考虑技术方案的可行性，还要平衡开发成本、团队能力和交付周期。今天这篇主要分享项目初期的架构设计和关键技术决策过程。
2. 技术架构设计思路
2.1 基础架构选型
我们最终选择了微服务架构，主要基于以下几点考虑：
- 客户需求变化频繁，需要系统具备快速迭代能力
- 不同业务模块的负载特征差异明显（如订单系统需要高并发，报表系统需要复杂计算）
- 团队有Spring Cloud的实战经验
具体技术栈如下：
- 服务框架：Spring Boot 2.7 + Spring Cloud 2021.0.x
- 服务注册：Nacos（替代Eureka，因为需要配置中心功能）
- API网关：Spring Cloud Gateway
- 消息队列：RabbitMQ（相比Kafka更轻量，适合中小规模场景）
重要提示：微服务不是银弹。如果团队规模小于10人，或者业务复杂度不高，单体架构可能更合适。我们选择微服务是因为预见到后期会有多个子系统并行开发的需求。
2.2 数据库设计策略
面对制造业复杂的业务关系，我们采用了多数据库混合的方案：
| 数据类型 | 数据库选型 | 理由 |
|---|---|---|
| 核心业务数据 | MySQL 8.0 | 事务支持完善，团队熟悉度高 |
| 报表分析 | PostgreSQL | 复杂查询性能优秀 |
| 实时监控数据 | TimescaleDB | 时序数据专用，压缩比高 |
| 文档类数据 | MongoDB | 灵活的模式设计 |
特别要注意的是，我们为MySQL设计了明确的分库分表策略：
- 按业务域垂直分库（订单库、生产库、质量库）
- 大表按时间水平分表（如订单表按月拆分）
3. 核心模块实现细节
3.1 订单服务开发实录
订单模块是系统的核心，我们实现了以下关键功能：
- 订单状态机设计：
java复制// 使用Spring StateMachine实现
public enum OrderStates {
DRAFT, CONFIRMED, PRODUCING,
QUALITY_CHECK, DELIVERED, CANCELLED
}
public enum OrderEvents {
CONFIRM, START_PRODUCTION,
COMPLETE_QUALITY, DELIVER, CANCEL
}
- 分布式事务处理：
- 采用Seata的AT模式处理订单创建→库存扣减的分布式事务
- 关键配置参数：
properties复制# Seata配置
seata.tx-service-group=order-service-group
seata.service.vgroup-mapping.order-service-group=default
seata.service.disable-global-transaction=false
- 性能优化措施：
- 二级缓存：Redis + Caffeine
- 批量处理：使用MyBatis的批量插入代替单条插入
- 异步日志：订单操作日志通过RabbitMQ异步写入
3.2 生产排程算法实现
制造业最复杂的生产排程模块，我们实现了基于遗传算法的智能排产：
- 染色体设计：用二维数组表示机器-时间-任务的分配关系
- 适应度函数：考虑交货期、设备利用率、换模时间等权重
- 关键参数调优：
python复制# 遗传算法参数
POPULATION_SIZE = 100
MUTATION_RATE = 0.02
CROSSOVER_RATE = 0.8
MAX_GENERATIONS = 500
实际测试发现，当工单数超过500时，算法耗时呈指数增长。最终我们增加了以下优化：
- 采用分治策略：按车间分区计算
- 引入模拟退火进行局部优化
- 使用多线程并行计算
4. 踩坑经验与性能调优
4.1 Nacos配置中心的高可用问题
初期我们直接使用Nacos的默认配置，结果在服务启动高峰期出现了配置读取超时。解决方案：
- 调整Nacos集群配置：
yaml复制# nacos-cluster.conf
192.168.1.101:8848
192.168.1.102:8848
192.168.1.103:8848
- 客户端增加重试机制：
java复制@Configuration
public class NacosConfig {
@Bean
public ConfigService configService() throws NacosException {
return NacosFactory.createConfigService(
PropertiesUtil.assembleNacosProperties(serverAddr, retryTimes, configLongPollTimeout)
);
}
}
4.2 分布式锁的选型对比
我们对比了三种方案后选择了Redisson：
| 方案 | 优点 | 缺点 |
|---|---|---|
| 数据库乐观锁 | 实现简单 | 高并发下性能差 |
| ZooKeeper | 可靠性高 | 部署复杂 |
| Redisson | 性能好，API丰富 | 依赖Redis稳定性 |
实际使用中发现锁自动续期是个大坑，最终采用以下配置：
java复制RLock lock = redissonClient.getLock("orderLock");
try {
// 等待时间30s，锁自动释放时间60s
boolean res = lock.tryLock(30, 60, TimeUnit.SECONDS);
if (res) {
// 业务处理
}
} finally {
lock.unlock();
}
5. 部署架构与监控方案
5.1 Kubernetes部署实践
我们使用K8s进行容器编排，主要配置要点：
- 资源限制配置示例：
yaml复制resources:
limits:
cpu: "2"
memory: 4Gi
requests:
cpu: "1"
memory: 2Gi
- HPA自动扩缩容配置：
yaml复制apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: order-service-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: order-service
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
5.2 全链路监控方案
监控体系搭建的几个关键点：
- 指标采集：Prometheus + Grafana
- 日志收集：ELK栈（Filebeat -> Logstash -> ES）
- 链路追踪：SkyWalking
- 告警规则示例：
yaml复制- alert: HighErrorRate
expr: rate(http_server_requests_errors_total[1m]) > 0.1
for: 5m
labels:
severity: critical
annotations:
summary: "High error rate on {{ $labels.instance }}"
description: "Error rate is {{ $value }}"
6. 项目总结与改进方向
经过6个月的开发，系统已经稳定运行3个月，日均处理订单量达到2万+。几个关键数据：
- API平均响应时间：<200ms
- 系统可用性：99.95%
- 最大支持并发：5000TPS
后续改进重点：
- 引入服务网格优化服务间通信
- 实现基于机器学习的异常检测
- 构建数据湖统一管理各类数据
这个项目让我深刻体会到：架构设计不是越复杂越好，而是要找到业务需求和技术实现的平衡点。下篇文章我会分享如何在资源有限的情况下做好技术债务管理。