跳到主要内容

销售线索管理系统 - 技术设计

上下文​

本系统是为支持公司全球化扩张而构建的全新销售线索管理系统,需要解决以下挑战:

  1. 国际化需求:支持多语言、多时区、多币种、多国家/地区
  2. AI增强:智能抓取线索并自动结构化、打标签
  3. 自动化:自动分配规则、自动回收、自动通知
  4. 数据合规:GDPR合规、跨境数据传输、数据隔离
  5. 性能:批量导入导出、大数据量查询、全球访问

约束条件​

  • 必须支持全球多区域部署
  • 必须满足数据合规要求(GDPR等)
  • 必须支持高并发访问(全球销售团队)
  • 必须保证数据一致性(线索唯一性、客户唯一性)
  • 必须具备良好的扩展性(未来新增更多数据源)

利益相关者​

  • 区域销售代表:需要快速接收高质量线索,便捷跟进
  • 销售主管:需要公平分配资源,实时查看转化率,灵活调整策略
  • 市场经理:需要衡量渠道ROI,优化投放策略
  • 系统管理员:需要配置全球规则,满足数据主权要求
  • 合规团队:需要确保数据处理符合各国法规

目标 / 非目标​

目标​

  • 构建完整的销售线索生命周期管理系统(从获取到转化)
  • 实现AI智能获取线索并自动分配,提升效率40%
  • 支持全球化业务(多语言、多时区、多国家)
  • 确保数据合规(GDPR、跨境传输)
  • 提供灵活的权限控制(角色权限、数据行级隔离)
  • 支持高并发与大数据量(批量导入导出、虚拟滚动)

非目标​

  • 本期不实现数据分析层(报表、可视化) - 留待P3阶段
  • 本期不实现移动端原生应用 - 使用响应式Web
  • 本期不实现语音/视频通话集成 - 仅记录拜访形式
  • 本期不实现预测性AI分析 - 仅实现结构化提取

技术决策​

1. 系统架构​

决策:采用前后端分离架构,微服务设计

原因:

  • 前后端分离便于独立开发、部署和扩展
  • 微服务架构支持按业务域拆分(线索服务、AI服务、通知服务等)
  • 便于全球化部署(不同区域部署不同服务实例)
  • 支持技术栈多样化(前端可用React/Vue,后端可用Java/Go/Node.js)

替代方案:

  • 单体应用 - 开发简单但扩展性差,不适合全球化场景
  • Serverless - 成本优势但技术复杂度高,不确定性较大

2. 数据库选型​

决策:关系型数据库 + NoSQL组合

关系型数据库(MySQL/PostgreSQL):

  • 存储核心业务数据(线索、客户、规则、待办等)
  • 支持复杂查询、事务、索引优化
  • 保证数据一致性(组合唯一性校验)

NoSQL(MongoDB/Redis):

  • MongoDB:存储AI非结构化数据(爬取原始数据、标签)
  • Redis:缓存热点数据(枚举值、国家/地区、用户会话)

替代方案:

  • 纯关系型数据库 - 难以存储非结构化AI数据
  • 纯NoSQL - 数据一致性保证较弱,不支持复杂事务

3. 国际化实现​

决策:服务端存储语言Key,前端按用户语言渲染

方案:

  • 所有UI文案存储为语言Key(如lead.source.official_website)
  • 前端维护语言包文件(JSON格式):en.json、zh.json、ja.json、es.json
  • 前端根据用户语言偏好加载对应语言包并渲染
  • 枚举值同样使用语言Key机制
  • 时间统一存储UTC,前端使用Intl API转换为用户本地时区

替代方案:

  • 服务端存储所有语言版本 - 存储冗余,扩展新语言需修改数据库
  • 前端硬编码文案 - 无法支持多语言切换

4. 权限控制​

决策:RBAC(基于角色的访问控制) + 数据行级权限

RBAC:

  • 定义角色:销售代表、销售主管、市场经理、系统管理员
  • 每个角色关联菜单权限(如"线索管理"、"公海池管理")
  • 用户登录时加载其角色和权限列表

数据行级权限:

  • 线索数据可见性规则:
    • 登录账号匹配「表单归属人」→ 可见
    • 登录账号所属部门匹配「表单所属部门」→ 可见
    • 其他情况 → 不可见
  • 查询时自动追加权限过滤条件(WHERE子句)

替代方案:

  • 仅RBAC - 无法实现数据行级隔离
  • 仅数据行级权限 - 管理复杂度高,无角色概念

5. 唯一性校验​

决策:应用层校验 + 数据库唯一索引双重保障

组合唯一性:

  • 线索:品牌名称 + 品牌国家/地区 组合唯一
  • 客户:客户名称、企业识别码类型 + 企业识别号码 双重唯一

实现:

  • 数据库层:创建复合唯一索引(brand_name, brand_country)
  • 应用层:保存前先查询数据库校验,冲突则抛出友好错误提示
  • 并发控制:使用数据库事务隔离级别SERIALIZABLE或乐观锁

替代方案:

  • 仅应用层校验 - 并发场景下可能产生重复数据
  • 仅数据库索引 - 错误提示不友好,无法自定义业务逻辑

6. AI爬虫集成​

决策:异步任务队列 + 失败重试机制

方案:

  • 使用消息队列(RabbitMQ/Kafka)实现异步任务
  • 定时任务触发爬虫任务(如每天凌晨2点)
  • AI爬虫服务独立部署,可水平扩展
  • 失败重试:指数退避策略(1分钟、5分钟、30分钟、2小时)
  • 审计日志:记录每次爬取结果(成功数、失败数、失败原因)

爬虫来源:

  • 国内:窄门、红餐、老板内参、大众点评、小火锅餐饮O2O
  • 海外:大众点评海外站、EASI、foodpanda、Uber Eats、饭团外卖、yelp、咖门、小红书

替代方案:

  • 同步调用 - 阻塞用户操作,体验差
  • 无重试机制 - 爬取失败率高,数据丢失风险大

7. 文件存储​

决策:CDN全球加速 + 对象存储

方案:

  • 对象存储(如AWS S3、阿里云OSS):存储门店Logo、名片等文件
  • CDN:全球加速访问,提升用户体验
  • 文件上传限制:
    • 单个文件≤10MB
    • 支持格式:png/jpg/gif/pdf
  • 存储路径国际化:按国家/地区分目录存储

替代方案:

  • 本地文件系统 - 无法支持全球访问,扩展性差
  • 数据库BLOB - 性能差,成本高

8. 定时任务​

决策:分布式任务调度框架

方案:

  • 使用Quartz(Java)或Celery(Python)实现定时任务
  • 支持集群部署,避免任务重复执行
  • 任务类型:
    • AI爬取任务(定时触发)
    • 自动分配任务(新线索进入公海池时触发)
    • 回收任务(定时扫描超时未跟进线索)
  • 支持多时区:任务执行时间按服务器时区,展示按用户时区

替代方案:

  • 单机定时任务(Cron) - 无法支持集群,存在单点故障
  • 手动触发 - 效率低,易出错

9. 通知服务​

决策:异步发送 + 多语言模板

方案:

  • 通知触发:业务事件(如分配线索、回收线索)发送消息到队列
  • 通知服务:消费队列消息,异步发送邮件/企微通知
  • 多语言模板:根据用户语言偏好选择对应模板
  • 通知类型:
    • 线索分配通知(发给归属人)
    • 线索回收通知(发给原归属人)
    • 待办提醒通知(到期前1小时)

替代方案:

  • 同步发送 - 阻塞业务操作,性能差
  • 固定语言模板 - 无法支持全球化

10. 数据合规​

决策:数据分类 + 访问控制 + 审计日志

GDPR合规:

  • 欧盟线索数据特殊标识(brand_country = "EU"国家)
  • 数据处理:欧盟数据存储在欧洲区域服务器
  • 用户权利:支持数据导出、删除请求

数据隔离:

  • 按国家/地区控制数据可见性(用户只能看到其授权区域的数据)
  • 跨境传输审批:欧盟数据传至非欧盟国家需审批

审计日志:

  • 记录所有数据变更操作(创建、修改、删除)
  • 记录内容:操作人、操作时间、操作类型、变更内容
  • 日志保留:至少3年

风险 / 权衡​

风险1: AI爬虫可靠性​

风险:第三方平台反爬虫机制导致爬取失败

缓解措施:

  • 实现失败重试机制(指数退避)
  • 多爬虫实例冗余部署
  • 人工复核机制(置信度低的线索标记为待审核)
  • 定期维护爬虫代码,适应平台变化

风险2: 数据一致性​

风险:高并发场景下线索/客户重复创建

缓解措施:

  • 数据库唯一索引约束
  • 应用层乐观锁或分布式锁
  • 事务隔离级别设置为SERIALIZABLE(关键操作)
  • 定时任务扫描并清理重复数据(兜底方案)

风险3: 性能瓶颈​

风险:全球高并发访问导致系统性能下降

缓解措施:

  • 数据库索引优化(查询字段、唯一性校验字段)
  • 缓存热点数据(枚举值、国家/地区、用户权限)
  • 分页查询(避免全表扫描)
  • 虚拟滚动(前端大数据量列表)
  • 数据库读写分离
  • CDN加速静态资源

风险4: 国际化复杂度​

风险:多语言、多时区、多国家导致系统复杂度高

缓解措施:

  • 前端语言包模块化设计,便于扩展新语言
  • 时间统一存储UTC,前端Intl API转换时区
  • 国家/地区数据使用国际标准(ISO 3166)
  • 充分测试各国场景(时区转换、电话格式、地址格式)

风险5: 数据合规风险​

风险:违反GDPR等法规导致法律风险

缓解措施:

  • 聘请合规团队审核系统设计
  • 实现数据分类与访问控制
  • 实现审计日志(记录所有操作)
  • 实现跨境传输审批流程
  • 定期进行合规审计

迁移计划​

阶段1: 基础设施搭建 (2周)​

  • 搭建开发、测试、生产环境
  • 配置数据库、缓存、消息队列、对象存储
  • 搭建CI/CD流水线
  • 配置监控与告警系统

阶段2: 核心功能开发 (8周)​

  • 线索来源管理 (1周)
  • 公海池管理 (2周)
  • 自动分配规则 (2周)
  • 个人线索管理 (1周)
  • 待办管理 (1周)
  • 成为客户流程 (1周)

阶段3: AI增强功能 (3周)​

  • AI爬虫集成 (2周)
  • AI结构化与打标签 (1周)

阶段4: 国际化与合规 (2周)​

  • 多语言支持 (1周)
  • 数据合规实现 (1周)

阶段5: 测试与优化 (2周)​

  • 集成测试 (1周)
  • 性能优化 (1周)

阶段6: 上线与灰度 (持续)​

  • 小范围灰度(1个区域)
  • 逐步扩大灰度范围
  • 全量上线

回滚策略​

  • 保留旧系统并行运行1个月
  • 新系统出现重大问题时快速切换回旧系统
  • 数据同步:旧系统数据实时同步至新系统

开放问题​

  1. 技术栈选型:前端使用React还是Vue?后端使用Java、Go还是Node.js?
  2. 爬虫合规性:部分平台可能禁止爬虫,如何处理法律风险?
  3. AI结构化准确性:AI提取的准确率如何保证?是否需要人工审核?
  4. 数据迁移:现有系统数据如何迁移?映射关系是什么?
  5. 成本预算:全球化部署的云服务成本预算是多少?
  6. 团队技能:团队是否具备AI爬虫、国际化、数据合规相关经验?