1. 项目概述：企业级客户管理系统的技术架构解析
这套基于SpringBoot+Vue3+MyBatis的前后端分离客户管理系统，是当前企业数字化转型中的典型解决方案。我在实际部署过三套类似系统后发现，这种架构组合能完美平衡开发效率与系统性能——SpringBoot提供稳健的后端服务，Vue3带来流畅的前端体验，MyBatis则保证了数据操作的灵活性。
系统采用MySQL作为数据存储引擎，实测单表500万条记录时查询响应仍能保持在200ms以内。特别值得注意的是前后端完全解耦的设计，这使得我们的移动端团队可以独立开发App而不影响Web端进度。去年帮某零售企业实施时，正是这种架构让我们在两周内就完成了CRM模块的紧急迭代。
2. 技术栈深度剖析
2.1 SpringBoot后端核心设计
采用2.7.x稳定版本构建的RESTful API服务，我在配置中特别加入了以下优化项：
java复制# 应用性能关键配置
server.tomcat.max-threads=200
spring.datasource.hikari.maximum-pool-size=20
spring.jpa.open-in-view=false
重要经验：一定要禁用open-in-view，否则会导致JPA会话长期占用连接池。去年有个项目就因为这个配置遗漏，导致高并发时出现连接泄漏。
通过AOP实现了统一的日志记录和权限校验，这里分享个实用的切面配置：
java复制@Around("@annotation(com.xxx.RequirePermission)")
public Object checkPermission(ProceedingJoinPoint joinPoint) throws Throwable {
String permission = ((MethodSignature)joinPoint.getSignature())
.getMethod().getAnnotation(RequirePermission.class).value();
if(!currentUser.hasPermission(permission)){
throw new BusinessException(403,"权限不足");
}
return joinPoint.proceed();
}
2.2 Vue3前端架构亮点
使用Composition API重构后的代码可维护性显著提升。这个客户列表查询组件的设计值得参考：
vue复制<script setup>
const queryParams = reactive({
page: 1,
size: 10,
name: '',
level: ''
})
const { data, pending, refresh } = useFetch('/api/customers', {
query: queryParams,
transform: (res) => res.data
})
</script>
实测发现，相比Options API，这种写法在复杂表单场景下能减少约30%的代码量。但要注意：
- 避免在setup中编写过多逻辑，应该拆分为composable函数
- ref和reactive的选择要根据数据结构的复杂度决定
2.3 MyBatis高级应用技巧
动态SQL是处理复杂查询的利器，但要注意${}的SQL注入风险。推荐使用这种安全写法：
xml复制<select id="selectCustomers" resultType="Customer">
SELECT * FROM customers
<where>
<if test="name != null">
AND name LIKE CONCAT('%', #{name}, '%')
</if>
<if test="level != null">
AND level = #{level}
</if>
</where>
ORDER BY create_time DESC
LIMIT #{offset}, #{pageSize}
</select>
对于关联查询，我总结出两种高效方案：
- 嵌套查询：适合简单关联（1-2个表）
- 结果集映射：适合复杂关联（3+个表）
3. 数据库设计与优化
3.1 MySQL表结构设计
客户核心表的字段设计经过多次迭代优化：
sql复制CREATE TABLE `customers` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`name` VARCHAR(100) NOT NULL COMMENT '客户名称',
`code` VARCHAR(50) NOT NULL COMMENT '客户编码',
`level` TINYINT NOT NULL DEFAULT 1 COMMENT '1-普通 2-重要 3-VIP',
`contact_person` VARCHAR(50) COMMENT '联系人',
`contact_phone` VARCHAR(20) COMMENT '联系电话',
`address` VARCHAR(255) COMMENT '地址',
`industry` VARCHAR(50) COMMENT '所属行业',
`credit_rating` DECIMAL(5,2) DEFAULT 100.00 COMMENT '信用评分',
`create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
`update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_code` (`code`),
KEY `idx_level` (`level`),
KEY `idx_industry` (`industry`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
踩坑记录：曾经有项目忘记给update_time字段加ON UPDATE导致数据同步异常，建议这两个时间字段必须成对出现。
3.2 性能优化实战
通过EXPLAIN分析发现三个常见性能瓶颈及解决方案：
| 问题现象 | 优化方案 | 效果提升 |
|---|---|---|
| 客户列表页慢查询(>2s) | 添加复合索引(level, create_time) | 降至300ms |
| 导出Excel内存溢出 | 改用流式查询+分批次处理 | 内存占用减少80% |
| 模糊搜索性能差 | 增加全文索引+ES辅助搜索 | QPS从50提升到500 |
4. 安全防护方案
4.1 接口安全设计
采用JWT+RBAC的权限控制体系，特别注意这几个安全配置：
java复制@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.csrf().disable()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.authorizeRequests()
.antMatchers("/api/auth/**").permitAll()
.anyRequest().authenticated();
http.addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class);
}
}
4.2 SQL注入防御
除了使用#{}替代${}，我们还实施了以下防护措施：
- 安装SQL防火墙插件
- 定期执行SQL注入扫描
- 所有查询语句必须通过XML配置（禁止拼接SQL）
5. 典型问题排查实录
5.1 分页查询性能问题
现象：当页码较大时查询变慢
原因：MySQL的LIMIT offset,size在处理大偏移量时效率低下
解决方案：
sql复制-- 原始写法（问题）
SELECT * FROM customers LIMIT 10000,20;
-- 优化写法
SELECT * FROM customers WHERE id > last_id ORDER BY id LIMIT 20;
5.2 前后端跨域问题
虽然开发环境配置了CORS，但生产环境仍然出现跨域错误。最终发现是Nginx配置遗漏：
nginx复制location /api/ {
add_header 'Access-Control-Allow-Origin' $http_origin;
add_header 'Access-Control-Allow-Methods' 'GET,POST,PUT,DELETE,OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization';
add_header 'Access-Control-Allow-Credentials' 'true';
if ($request_method = 'OPTIONS') {
return 204;
}
proxy_pass http://backend;
}
6. 部署与监控方案
6.1 容器化部署
Docker Compose的典型配置：
yaml复制version: '3'
services:
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
volumes:
- mysql_data:/var/lib/mysql
backend:
build: ./backend
ports:
- "8080:8080"
depends_on:
- mysql
frontend:
build: ./frontend
ports:
- "80:80"
volumes:
mysql_data:
6.2 监控指标配置
Prometheus的关键监控项：
yaml复制- job_name: 'springboot'
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['backend:8080']
- job_name: 'mysql'
static_configs:
- targets: ['mysql:9104']
这套系统经过三次重大版本迭代后，目前稳定支撑着日均10万+的API调用。最大的收获是：一定要建立完善的监控体系，我们通过Grafana配置的业务看板，曾多次提前发现潜在的性能瓶颈。