0、请做一下自我介绍可选开场使用问题请做一下自我介绍。回答各位领导、同事大家好。我是后端开发主要负责寄存柜业务系统后端模块的设计与开发工作。本次落地的寄存柜业务系统面向出行旅客、商圈用户提供就近寄存柜查询、点位导航、寄存使用指引全流程线上服务。在项目中我主导整体模块拆分、接口设计、性能优化、异常兜底方案落地搭建了「公共支撑底座 四大垂直业务模块」分层架构完整承载用户定位、城市切换、寄存点地图检索、寄存指南展示整条业务链路。接下来我结合项目内容逐一进行介绍。1、请介绍一下你最近做的项目需求问题请介绍一下你最近做的项目。回答我近期主要负责寄存柜前端配套后端业务系统开发。随着线下寄存柜点位持续铺设业务侧需要一套线上系统让用户可以在线查找身边可用寄存柜支撑多城市规模化运营。 基于业务目标我们整体采用分层架构进行设计整体分为两大板块底层公共支撑基础模块上层四大核心业务模块。 公共支撑模块作为系统统一底座向下封装通用基础能力包含六大子模块接口鉴权与限流、多级缓存、全链路日志与用户行为埋点、数据存储与索引、监控告警、通用工具封装。底座模块被所有业务模块复用避免重复开发、统一系统技术标准。 上层四大业务模块按照用户操作流程依次搭建第一是用户定位模块作为业务入口自动获取用户地理位置第二是城市选择模块支持用户自主切换服务城市第三是寄存点地图搜索模块属于项目核心模块根据坐标筛选附近寄存点位第四是寄存指南模块承载运营图文指引内容。 整套系统需要实现这些核心需求第一安全需求所有接口做好访问管控防范恶意刷取第二性能需求高峰期大量用户同时查询点位接口响应速度必须达标第三体验需求完善各类异常、空白场景兜底策略不能因为单个功能异常导致整个页面无法使用第四运营需求支持城市灰度开放、页面文案动态配置运营人员调整内容不需要发布新版本第五可观测需求完整日志、监控告警方便线上问题快速定位。 最终目标是打通用户「打开页面 - 自动定位 - 切换城市 - 查找附近寄存柜 - 查看使用规则」完整闭环支撑后续百城寄存柜业务拓展。2、你做的内容有什么难点为什么会出现难点问题你做的内容有什么难点为什么会出现回答在项目落地过程中我主要遇到三大核心难点。 第一个难点寄存点地理位置范围检索性能压力大。业务要求根据用户实时坐标查询指定范围内由近到远排序的寄存点。最直观的方式是数据库实时计算两点之间直线距离但是距离计算属于高开销运算。一旦大量用户同时发起点位查询请求数据库 CPU 会快速打满查询延迟急剧上升。同时随着后续点位数量持续上涨全表计算距离的方式完全无法支撑并发场景。出现这个难点的根本原因传统关系型数据库并不擅长大规模空间范围检索运算。 第二个难点多模块联动场景下缓存数据一致性难以保障。定位、城市选择、寄存点搜索三个模块存在强上下游依赖。当用户重新定位、手动切换城市时需要同步刷新寄存点位数据。系统使用缓存降低数据库压力若缓存刷新时机处理不当就会出现缓存脏数据造成前端展示点位和当前选择城市不匹配、定位刷新之后点位信息没有同步更新等问题。难点根源在于多个业务模块共享同一批缓存数据用户主动操作触发状态变更时缺少统一、可靠的缓存刷新机制。 第三个难点边界场景繁多异常链路复杂全场景兼容成本高。用户侧会出现多种多样异常情况手机定位权限关闭、定位服务超时、网络波动、用户选择暂未开通寄存业务的城市、当前 5 公里范围内没有任何寄存点位。只要任意一个环节出现异常如果缺少降级兜底逻辑就会出现页面空白、接口报错、流程中断。之所以会存在这个难点是因为线上用户设备环境、网络环境各不相同我们无法保证上游定位服务、数据库查询每次都 100% 成功必须主动考虑各类失败场景。除此之外还有衍生难点业务持续扩张后续会不断新增城市、新增寄存点位架构设计必须具备良好扩展性不能后期新增需求就大规模重构代码。3、你是如何解决的解决问题面对这些难点你是如何解决的回答针对上面梳理的难点我针对性设计并落地对应的解决方案。 首先针对地理位置检索性能问题。第一为寄存点数据表建立空间索引依靠数据库原生空间能力做范围筛选避免遍历全表计算距离第二增加查询范围限制默认只检索用户周边 5 公里范围点位缩小扫描数据范围第三引入多级缓存机制对车站、商圈等人流密集的热点区域点位进行缓存高频请求直接读取缓存减少数据库查询次数第四限制单次接口返回点位最大条数防止一次性返回上千条数据造成前端与后端双重压力。其次针对多模块联动缓存一致性问题。我统一封装全局缓存操作工具标准化缓存 key 设计明确数据归属城市标识。约定触发缓存失效场景用户手动切换城市、主动刷新定位、后台新增 / 修改寄存点位时主动清理对应城市下寄存点位缓存。同时统一上下游模块数据结构体定位模块、城市模块向外输出标准化城市编码保证缓存筛选条件统一减少数据解析错乱问题。然后针对海量异常边界场景。我牵头梳理完整异常清单对所有接口分级设计降级策略。定位服务调用失败系统自动兜底展示默认城市检索范围内不存在寄存点前端展示定制化空状态提示文案接口调用超时增加合理重试机制所有异常情况全部打印全链路日志同时进行埋点统计。保证无论出现哪种异常业务流程不会直接崩溃用户依旧可以正常操作页面。最后面向业务拓展性严格按照高内聚低耦合思路拆分模块公共能力下沉到底层底座业务功能独立拆分。后续新增功能直接复用鉴权、缓存、监控等通用能力不需要重复开发降低后续迭代成本。4、是否有其它解决方案拓展问题针对以上问题是否还有其它解决方案回答针对项目里的核心问题我在方案设计阶段对比过多种备选方案下面分开说明。 第一地理位置检索方案。当前我们采用「数据库空间索引 热点缓存」方案。备选方案是引入 Elasticsearch依托 ES 内置的地理空间检索能力完成附近点位查询。ES 更适合点位数量达到百万级、超高并发检索场景。但是现阶段我们寄存点位总量不大如果引入 ES需要新增中间件部署、运维成本增加项目复杂度。综合项目当前体量现阶段数据库方案投入成本更低等到未来点位规模大幅上涨之后可以平滑迁移至 ES 方案。第二缓存一致性方案。目前我们采用主动失效缓存方案。备选方案可以引入消息队列后台点位数据变更之后发送消息消费端异步完成缓存清理。但是当前业务变更频次较低引入 MQ 会增加运维组件提升系统复杂度。短期主动清理方案完全满足需求未来后台点位频繁批量更新场景出现后可以引入消息队列实现最终一致性。第三定位能力实现方案。当前采用 GPS 定位优先、IP 定位兜底的策略。备选方案可以直接对接高德、百度地图高精度定位第三方接口。优势是定位成功率、精度更高劣势是持续产生第三方接口调用费用。结合成本考量当前自研降级方案可以平衡用户体验与资金成本。第四异常兜底层面。长期方案可以搭建统一熔断组件对定位服务、数据库查询配置熔断策略连续多次失败自动触发熔断保护下游资源。现阶段异常量可控依靠代码内降级逻辑足够支撑运行作为后续优化储备方案。5、项目中做过哪些优化效果怎么样优化问题项目中做过哪些优化效果怎么样回答项目开发与上线阶段我从性能、业务体验、运维能力三个维度落地了多项优化工作。 第一项接口性能专项优化。统一规范接口分页逻辑限制点位查询最大返回数量调整数据库索引删除无效索引优化 SQL 执行计划。优化完成后定位接口响应耗时稳定控制在 200ms 以内寄存点查询接口 P95 耗时稳定低于 300ms。高峰期上千用户同时访问没有出现大面积接口超时性能指标达到业务预期标准。第二项缓存策略精细化优化。区分冷热数据只对高频访问城市点位进行缓存设置差异化过期时间。避免冷数据长期占用缓存空间同时平衡数据实时性。优化完成后寄存点位查询对应的数据库 QPS 下降大约 40%显著减轻数据库压力。第三项运营能力与用户体验优化。把空状态提示、引导文案、城市提示全部改造为后台可动态配置内容运营人员可以随时修改文案不再依赖开发发版迭代。同时完善全量用户行为埋点持续采集定位失败、无寄存点位、城市切换等场景数据。产品和业务团队可以依托埋点数据分析用户痛点指导线下点位铺设规划。第四项线上可观测能力优化。完善监控告警规则针对接口平均耗时、P95 耗时、错误率设置阈值告警。一旦线上出现性能波动、报错突增运维人员可以第一时间收到通知。故障发现时长相比优化前大幅缩短降低线上故障带来的影响。第五项代码工程优化。统一封装公共异常、统一返回格式消除各个模块重复代码完善接口注释、数据库文档新人接手项目可以快速理解模块依赖关系降低后期维护成本。整体来看一系列优化落地之后系统并发承载能力、稳定性、运营灵活度都得到明显提升能够平稳支撑当前业务流量同时为后续业务放量预留性能空间。6、对新趋势新技术有什么了解能否用到你的项目中双新问题对新趋势新技术有什么了解能否用到你的项目中回答平时我持续关注后端开发领域新技术、新趋势结合寄存柜系统现状梳理出几项可以结合业务落地的技术方向。第一空间向量检索技术。目前我们依靠空间索引筛选附近寄存点。向量数据库可以把地理位置信息转化为向量实现邻近检索。未来业务发展到下一阶段我们不止要展示附近寄存柜还可以结合用户存取行李行为数据构建用户行为向量实现寄存点位个性化智能推荐。向量检索技术可以作为下一代空间检索方案备选当点位体量持续上涨后进行技术升级。第二Serverless 云函数技术。系统内寄存指南、静态说明类接口访问流量波动极大大部分时间访问量很低。这类低频静态接口可以改造部署在 Serverless 云函数。流量低的时候自动释放计算资源高峰自动扩容能够有效节约长期服务器资源成本适合后续渐进式改造落地。第三低代码可视化运营平台。当前运营配置能力比较单一只能修改基础文案。引入低代码平台之后运营人员可以自主配置活动页面、点位介绍、弹窗内容减少大量简单需求的开发排期释放研发人力聚焦核心业务开发。第四分布式链路追踪技术。当前我们具备基础日志能力但完整链路串联能力不足。接入分布式链路追踪组件之后可以完整串联「定位请求 - 城市筛选 - 点位查询」整条调用链路问题定位效率会进一步提升适合后续系统模块持续增多之后引入。同时我也会理性看待技术选型不会盲目追求新技术。现阶段系统首要目标保障业务稳定可靠新技术不会立刻大规模上线。我们会在现有架构预留扩展接口持续跟进业务增长情况分阶段评估、平稳引入适配业务场景的新技术做到技术服务于业务。