点评系统架构优化实战：从性能瓶颈到全链路改造

1. 项目背景与改造动机

作为技术团队的核心开发人员，我负责的点评系统已经稳定运行了三年多。随着业务量从最初的日均几百单增长到现在的数万单，原有架构开始暴露出诸多问题：高峰期API响应时间波动明显、数据库查询效率下降、部分页面加载出现明显卡顿。

这次改造不是简单的功能迭代，而是对系统进行全方位的深度优化。我决定将整个改造过程以学习笔记的形式记录下来，一方面作为团队内部的技术文档，另一方面也希望能给面临类似问题的同行提供参考。不同于普通的开发日志，这些笔记会着重记录技术决策背后的思考过程，以及那些在官方文档中找不到的实战经验。

2. 系统现状分析与痛点定位

2.1 性能瓶颈诊断

我们使用NewRelic对生产环境进行了为期两周的监控，发现主要性能问题集中在三个层面：

1. API层：点评列表查询接口平均响应时间达到780ms（P95在1.2s）
2. 数据库：商品表JOIN操作消耗了65%的查询时间
3. 缓存：本地缓存命中率仅有42%，大量请求穿透到数据库

通过火焰图分析，发现最耗时的操作是用户画像计算（占API时间的38%），这部分逻辑是在每次请求时实时生成的。同时发现Nginx日志中有大量重复查询参数完全相同的请求，说明客户端缓存策略存在问题。

2.2 架构债务梳理

系统最初采用典型的单体架构，随着功能迭代出现了明显的模块耦合：

• 用户服务直接调用了店铺服务的内部DAO
• 优惠券计算逻辑分散在5个不同的Service中
• 使用MySQL的TEXT字段存储JSON格式的扩展属性

更棘手的是历史数据问题：早期设计的评分表没有考虑分库分表，目前单表已经达到280GB，简单的COUNT查询都需要8-9秒。

3. 核心技术改造方案

3.1 服务拆分与重构

我们采用渐进式重构策略，首先将最核心的点评模块抽离为独立服务。具体步骤：

1. 新建comment-service项目，保留与原系统的双向兼容接口
2. 使用Spring Cloud Gateway配置路由规则，逐步将流量切换到新服务
3. 关键点：保持新旧两套API的cookie/session互通

在数据迁移时，我们开发了特殊的双写适配器。这个过程中最大的教训是：不要直接复制实体类字段。我们遇到了JPA的@Version注解在异构系统间不同步导致的乐观锁冲突，最终采用自定义版本号生成器解决。

3.2 查询性能优化

针对点评列表查询，我们实施了三级缓存策略：

1. 客户端缓存：通过ETag实现304响应，减少30%的重复请求
2. 边缘缓存：在CDN节点缓存热门商家的前3页数据
3. 服务端缓存：使用Redis的zset实现分页缓存，并开发了防雪崩的二级回源机制

一个特别有效的优化是对用户画像进行预计算。我们开发了基于Flink的实时处理作业，将原本在请求链路中进行的计算提前到用户行为发生时处理，使得API响应时间直接降低40%。

4. 数据架构升级

4.1 分库分表实施

选择ShardingSphere作为分片中间件，按照商家ID进行水平分片。在迁移过程中，我们总结出几个关键经验：

1. 先双写再迁移：保持旧库同步写入至少两周
2. 使用影子表验证：在测试环境完整模拟分片查询
3. 开发特殊工具处理热点商家：对Top 1%的商家采用特殊分片规则

最复杂的部分是处理历史JOIN查询。我们最终采用冗余字段+异步更新的方式，将需要跨片JOIN的字段提前物化到主表。

4.2 新型存储引入

针对不同的数据特性采用差异化存储：

• 核心事务数据：仍保留在MySQL
• 用户行为日志：迁移到Elasticsearch
• 图片/视频元数据：存储在MongoDB
• 社交关系图谱：尝试使用Neo4j

这里有个值得分享的细节：我们为ES开发了特殊的索引预热策略。通过分析查询模式，在每天流量低谷时段提前加载热门索引，避免高峰期的冷查询惩罚。

5. 改造效果与监控体系

5.1 性能指标对比

经过三个月改造，关键指标变化如下：

• API平均响应时间：780ms → 210ms
• 数据库负载峰值：85% → 32%
• 缓存命中率：42% → 89%
• 异常错误率：1.2% → 0.15%

特别值得注意的是P99延迟的改善：从原来的3.4秒降低到560毫秒，这对用户体验提升最为明显。

5.2 全链路监控建设

我们建立了四层监控体系：

1. 前端：使用Sentry捕获JS错误
2. 网关：自定义Metric记录路由延迟
3. 服务：通过Micrometer暴露Prometheus指标
4. 基础设施：对K8s集群进行节点级监控

最有价值的是开发了业务指标看板，将技术指标与业务KPI（如转化率、客单价）关联分析。例如发现当API延迟超过400ms时，用户提交点评的意愿会下降18%。

6. 经验总结与后续规划

这次改造最大的收获不是技术方案本身，而是确立了可持续优化的机制。我们建立了架构评审委员会，规定所有新功能必须通过性能影响评估。同时制定了季度性的技术债务清理计划。

在工具链方面，有两个特别推荐的自研工具：

1. 接口契约测试工具：基于OpenAPI生成边界用例
2. 数据迁移验证器：自动对比新旧系统输出差异

未来半年重点会放在智能化方向：尝试用机器学习预测用户点评质量，自动识别水军账号；实验性地将部分服务迁移到Service Mesh架构；探索HTAP在实时数据分析中的应用。