写在前面
这篇文章和大家分享一下最近和团队成员一起重构的围栏服务真实案例分享，二话不说，先上图:
重构前后对比(单台docker服务压测结果)
| 对比项 | QPS | 平均RT | P995耗时 | 说明 |
| 重构前 | 120 | 50ms | 800ms | 压测达到性能瓶颈 |
| 重构后 | 5000 | 5ms | 50ms | 压测未到达性能瓶颈 |
重构之后性能提升40倍，效果非常明显。
下面分享详细技术方案。
技术方案
一、背景/现状
- 多次压测反馈，目前线上机器8台docker大概只能支撑1k/QPS, 单机120/QPS。
- 无城市查询围栏场景，会循环判断该业务线下全国的围栏是否命中，耗CPU严重，高峰期性能瓶颈特别明显。
二、目标
- 1.派单围栏服务流程重构，通过派单系统自建空间索引RTree方式， 利用空间换时间的方式，先通过 RTree搜索围栏，再判断坐标是否在围栏内。
- 2.现有资源不变情况下，提升接口性能，并且支持水平扩展。
三、重构方案
1.重构前流程图
2.重构后流程图
3.RTREE数据结构简介: 每个节点是能把对应的围栏包起来 的最小外包矩形
四、里程碑节点
| 阶段 | 事项 | 开发时间 |
| 开发阶段 | 1. 围栏系统自建Rtree开发 2. 灰度方案开发(按流量灰度，支持header指定强制走新系统(方便压测)， 3. 数据对比: 通过抓取线上日志，通过流量回放，同时请求新老围栏系统，判断结果是否完全一致。 4. 异常补偿: 强制刷新Rtree接口) |
5d |
| 测试阶段 | 由测试同学评估,开发提供影响范围 | 2d |
| 灰度阶段 | 1. 按流量灰度平滑迁移 2. 压测 | 5d |
五、灰度方案
按接口请求流量灰度
| 一阶段 | 二阶段【压测】 | 三阶段 | 四阶段 | 阶段 |
| 万分之一 | 1% | 20% | 50% | 100% |
六、所需资源
无需新增资源
总结:
本次重构优化效果很明显，其实改动并不是很大，可见合理的技术方案是非常重要的。作为技术人，我认为写代码是其次的，也是最基本的，除此之外应该多深入思考一下，多问问自己:"这样实现会不会有什么瓶颈？有没有更好的方案？我这样实现之后能不能水平扩展？如果不能，我有什么应对方案？"。
另外，借鉴之前老大说的一句话:"只要人觉得可能出现问题的地方，就一定会出问题！" ，敬畏心也是非常重要的，所以灰度方案，也是非常重要的。
刚接手这个新团队不久，重构之路刚刚启程，这篇文章也是记录一下心路历程，希望对大家也有所感悟和帮助。
