经典项目问题

2023年7月20日 · 1921 字 · 4 分钟 · 生活

经典问题

  • 主要负责模块是哪块？整体业务流程是怎样的？云仓是什么？
  • 讲一下做的项目中遇到的问题（挑战和复杂是什么）？怎么解决的？（技术难点问题、业务复杂度问题）
  • 项目中你觉得block遇到的问题 ，如何解决的
  • 项目有做代码层面的抽象和复用吗？怎么做的？

团队承担指责（业务复杂度）

  • 作为最上游、下发调用下游不同的系统（链路长，问题第一接触方排查流转不同系统）
  • 监控告警、对账、业务数据看板分析、查询离线数据分析
  • 做对账最上游和最下游单据对状态（影响卡单的问题），数据可视化分析推动各个方修复和优化
  • 根据架构孵化inbound，解耦平台和行业逻辑（业务层面+代码层面）

项目背景[前后]、做了什么、取得效果是什么

业务复杂

  • 需要根据货品绑定的商品类目（日杂、电器、食品、美妆），展示不同的质检模块（ex生鲜类别、3c数码类目不同，需要展示说明书等以及各个模块文字操作提示、示例图片、上传图片的最大和最少数量等），设计模版配置中心（抽象不同模块，设置对应模块编号、文字描述、示例图片url配置等都存储在动态配置中心tcc，能够灵活跟着业务变化而修改）
  • 表设计（以货品纬度的货品质检表，一个货品可能会发起多次质检外键是质检任务ID；货品版本表，货品可能会出现新老包裹交替场景；货品质检明细表，将模块和图片信息拍平，存的明细以单个图片为一条记录，多个记录的模块字段会是相同的；表关系1:N:N）
  • 幂等（兜底+告警）
  • 查询（CQRS）

技术上遇到的问题

  • 链路处理：请求下游和更新自身、或者更新自身后请求下游再更新（使用考虑）
  • 统计业务指标，接入把脉bmq上传每个请求数据，业务分析；rpc重试打点监控配置告警等；使用wire实现生成代码来依赖注入，分层handle service等
  • 其他问题：作为poc遇到下游链路沟通和协调

技术优化：

  • 查询数仓badcase17s -> ClickHouse善于OLAP查询100ms-5s,电商只有一个公用集群不稳定 -> 根据业务场景设置abase理解redis key为每七天和三十天，value是json对象日期+物流分 -> 降到100ms，实现了性能的优化
  • 在项目优化期间，查询数仓平台rpc是按照列返回数据形式，不方便解析，沉淀sdk封装序列化类似gorm方便后续接入

项目应用设计模式

  • 对接不同的链路（toBtoC出入、open/奇门）走不通逻辑（工厂模式+策略）

  • toB入库单创建卡单校验(判断xx效期)（工厂+观察者）

  • Go里面使用wire进行依赖注入，handle、service、dao通过组合方式调用（单例模式）

  • Go使用sync.Once，初始化db、redis等外部依赖资源（单例模式）

  • 技术问题：表设计和链路处理（请求下游和更新自身、或者更新自身后请求下游再更新）；针对不同的模块需要配置不同文字提示和图片示例，需要方便业务调整，设计json通用结构配置到动态配置中心；统计业务指标，接入把脉bmq上传每个请求数据，业务分析；rpc重试打点监控配置告警等；使用wire实现生成代码来依赖注入，分层handle service等

  • 其他问题：作为poc遇到下游链路沟通和协调

  • 查询数仓badcase17s -> ClickHouse善于OLAP查询100ms-5s,电商只有一个公用集群不稳定 -> 根据业务场景设置abase理解redis key为每七天和三十天，value是json对象日期+物流分 -> 降到100ms，实现了性能的优化

  • 在项目优化期间，查询数仓平台rpc是按照列返回数据形式，不方便解析，沉淀sdk封装序列化类似gorm方便后续接入

  • 规划和设计（xx）

微服务实现查询

  1. API组合方式查询，api组合器作为客户端查询多个服务，查询出的数据组合join展示（商家数据、仓数据等）
  • 确定哪个组件作为查询操作的API聚合器？（客户端、API gateway、API组合器实现为独立服务）
  • 如何编写有效聚合逻辑？ 优点：简单方便直观 缺点：需要查询多个服务和查询多个数据库额外的开销；可用性降低的风险（查询多个服务可能某服务不可用）；缺乏事务数据一致性（涉及多个数据库查询，返回不一致的数据问题）
  1. CQRS（Command Query Responsibility. Segregation） 使用事件维护从多个服务复制的数据视图，借此实现对多个服务的数据查询。拆分将持久化数据模型和查询数据模块（命令端、查询端）
  • 命令端：数据模型的创建、更新删除；查询端：数据的查询；
  • 查询端通过订阅命令端发布的事件，使其数据模型和命令端模型保持同步 实践场景：fass消费MySQL的binLog信息，AC单据同步ES（查询uas、wms、货主信息）组合同步到ES中 优点：降低查询多个服务的开销；提升查询模块高可用；具有数据一致性 缺点：实现比api组合方式复杂