经典问题
- 主要负责模块是哪块？整体业务流程是怎样的？云仓是什么？
- 讲一下做的项目中遇到的问题（挑战和复杂是什么）？怎么解决的？（技术难点问题、业务复杂度问题）
- 项目中你觉得 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）
微服务实现查询
- API 组合方式查询，api 组合器作为客户端查询多个服务，查询出的数据组合 join 展示（商家数据、仓数据等）
- 确定哪个组件作为查询操作的 API 聚合器？（客户端、API gateway、API 组合器实现为独立服务）
- 如何编写有效聚合逻辑？ 优点：简单方便直观 缺点：需要查询多个服务和查询多个数据库额外的开销；可用性降低的风险（查询多个服务可能某服务不可用）；缺乏事务数据一致性（涉及多个数据库查询，返回不一致的数据问题）
- CQRS (Command Query Responsibility. Segregation) 使用事件维护从多个服务复制的数据视图，借此实现对多个服务的数据查询。拆分将持久化数据模型和查询数据模块（命令端、查询端）
- 命令端：数据模型的创建、更新删除；查询端：数据的查询；
- 查询端通过订阅命令端发布的事件，使其数据模型和命令端模型保持同步 实践场景：fass 消费 MySQL 的 binLog 信息，AC 单据同步 ES（查询 uas、wms、货主信息）组合同步到 ES 中 优点：降低查询多个服务的开销；提升查询模块高可用；具有数据一致性 缺点：实现比 api 组合方式复杂