稻草小站
跳到项目内容
全部项目
商业系统/项目经验整理

思为科技营销云

地产营销业务、数据智能与平台服务的长期演进

Spring BootMyBatis-PlusRedis消息驱动多租户微信生态
2 个
项目集
106 行
仓库清单
140 个
Maven 模块
6 类
核心能力域
  1. 01触达小程序 · 企微 · PC

    访客、顾问、经纪人和管理员进入不同工作入口

  2. 02识别Auth · User Center

    租户、组织、角色和渠道形成统一上下文

  3. 03经营Customer · Activity

    客户、项目、活动、内容和线索协同推进

  4. 04交易Payment · Sign

    支付、签约、佣金和外部 ERP 状态协作

  5. 05事件Event Center

    通知、异步订阅、延迟任务和消费追踪

  6. 06分析CDP · DaaS · NLP

    标签、生命周期、报表和录音智能沉淀经营结果

项目速览

业务背景

思为科技营销云服务地产营销场景，连接微信小程序、企微工作台、管理后台、销冠应用和外部合作系统。项目集同时保留了 company 中的主线与历史业务实现，以及 useproject 中按领域拆分的服务、平台和 AI/NLP 项目。通过用户中心、权限体系、事件中心、支付中心、数据采集与自助分析等公共能力，支撑从访客触达到客户运营、活动转化、交易协同和经营分析的完整链路。

负责范围
  • 梳理 company 主线业务与公共组件边界
  • 整合 useproject 的营销云、Zeus、DaaS、CDP 与 AI/NLP 服务
  • 提炼用户身份、事件、支付、数据分析和第三方接入链路
  • 归纳多租户、服务契约、异步消息、数据一致性和交付经验
  • 以可核对的代码目录、README、POM 与业务文档支撑项目叙事
2 个项目集

代码范围

company 主线与 useproject 服务集共同组成此次项目经验整理范围。

106 行

仓库清单

useproject/repo.txt 记录了营销云、Zeus、DaaS、CDP、开放平台和 AI/NLP 等仓库入口。

140 个

Maven 模块

useproject 扫描到的 pom.xml 数量，体现服务化和公共模块拆分规模；这是归档快照统计，不是线上实例数量。

01

核心业务

思为科技营销云不是单一应用，而是一组围绕地产营销业务持续演进的服务。company 目录保留了主线业务、历史兼容和公共组件；useproject 目录则以仓库清单和服务目录呈现更清晰的领域拆分。两者放在一起，能看到系统从“业务集中承载”走向“领域服务 + 平台能力 + 数据智能”的过程。

业务入口包含微信小程序、企微工作台、PC 管理后台、销冠应用和外部合作系统。用户从访客触达开始，经过身份识别、项目与内容浏览、活动报名、线索和客户经营，最终进入交易、支付、签约、数据分析与运营复盘。系统的难点不是单个接口，而是跨租户、跨角色、跨服务和跨外部平台时仍然保持身份、状态和数据口径一致。

01company：业务主线与历史兼容
包含认证鉴权、权限、客户、用户、活动、内容、签约、项目、企微、支付、第三方和前端项目，保留完整业务链路以及早期系统的表结构、接口和兼容逻辑。
02useproject：领域服务与平台化拆分
围绕营销云、Zeus、开放平台、数据平台和 AI/NLP 建立独立仓库，活动、支付、事件、用户、配置、文件和第三方接入通过 Feign 与 starter 形成服务契约。
03用户与身份
访客、经纪人、顾问、自渠、管理员和系统角色在不同入口产生，但由用户中心、租户、组织和角色关系统一表达，业务服务从上下文读取身份和范围。
04客户经营与营销活动
活动主表、上下架、报名、线索、客户关系、客户描摹、全渠道来源、渠道风控和项目服务共同构成营销云的核心业务层。
05交易、支付与外部协同
支付中心抽离渠道差异，third-platform 统一对接微信等外部平台；签约、佣金、ERP、企微和数据打通服务负责把业务状态传到外部系统。
06数据、分析与智能
埋点、数据采集、用户标签、生命周期、ClickHouse 位图、DaaS 多模型报表和录音 / NLP 服务把业务事实转化为运营洞察。
02

项目集视角

company 主线

业务连续性

保留营销云完整业务链路、历史兼容、公共模块和前端入口。

实现
围绕用户、客户、活动、内容、交易、企微和第三方服务组织代码，并通过公共 starter、Feign 和基础组件复用能力。
输出
可以从一个业务需求追到入口、服务、数据库和外部系统。
边界
历史目录和重复构建产物较多，需要结合 README、POM 和代码入口判断当前职责。

useproject 服务集

领域拆分

把业务服务、平台服务、数据产品和 AI/NLP 项目以仓库清单形式组织。

实现
活动、支付、事件、用户、数据、Zeus、开放平台和智能服务各自维护接口与模块，repo.txt 记录仓库来源。
输出
适合做服务边界、依赖关系、交付路径和项目演进分析。
边界
部分 README 仍是 GitLab 模板，必须结合 POM、目录和技术文档确认实际内容。

数据智能链路

事实到洞察

把埋点、业务数据、标签、生命周期、报表和 NLP 能力连接起来。

实现
采集器和适配器沉淀事实，CDP 与位图完成用户分群，DaaS 模型负责指标和维度，录音与语义服务补充案场经营分析。
输出
运营侧得到可下钻报表、用户人群、行为轨迹和销售接待分析。
边界
指标口径、数据延迟和外部打通质量仍需按租户和交付项目分别验收。
03

技术栈

业务服务
JavaSpring BootMyBatis-PlusMavenFeign
数据与消息
MySQLRedisMongoDBKafka / RabbitMQClickHouse
平台能力
NacosDockerKubernetesXXL-JOBPrometheus
业务接入
微信小程序企微飞书抖音 / 百度OSS支付渠道
数据与智能
DaaS 报表CDP 生命周期用户标签NLP / 录音分析
前端与交付
Vueuni-app / 微信小程序GitLab CI多环境配置
04

系统架构与部署

company 保留主线业务和公共组件，useproject 以领域服务、平台能力和数据智能重新组织；两者通过用户、事件、支付和数据契约连接。

业务入口

微信小程序 / 企微 / PC / 销冠应用 / H5

按用户角色和使用场景提供不同入口，入口层只负责交互与凭据，不重复实现客户、支付和权限规则。

核心服务

Spring Boot / MyBatis-Plus / Feign / Maven

服务按用户、活动、客户、内容、交易和平台能力拆分；公共 starter 和接口模块减少重复接入。

数据与消息

MySQL / Redis / MongoDB / Kafka / RabbitMQ / ClickHouse

关系数据保存业务事实，缓存与锁服务于热路径，消息承担事件传播，分析数据进入报表和标签模型。

运行与交付

Nacos / Docker / Kubernetes / XXL-JOB / GitLab CI

不同环境使用独立配置和发布目标，定时任务、日志、监控和镜像交付共同支撑业务服务运行。

05

能力边界：从业务交付到平台复用

项目经验的价值在于把一次地产客户需求沉淀为可复用的服务能力，同时保留不同客户、租户和渠道的配置差异。

多入口
微信 / 企微 / PC / 销冠

同一用户可能在多个入口出现，身份和权限需要在服务端统一。

多租户
组织 / 项目 / 渠道

业务数据和角色范围按租户、组织和项目隔离，外部打通需要保留来源上下文。

多节奏
同步请求 / 异步事件 / 分析任务

实时接口、消息消费、定时任务和报表查询使用不同的超时、重试和一致性策略。

多系统
微信 / 企微 / ERP / 飞书 / 支付渠道

外部系统差异收敛在适配层，业务服务通过内部 DTO 和事件模型保持稳定。

归档代码和文档能够说明服务边界与设计经验，不能直接替代客户生产环境的容量、SLA 或当前版本验收。

06

核心业务链路

访客从小程序进入客户经营链路

  1. 1微信小程序
  2. 2鉴权 / 用户中心
  3. 3访客与手机号
  4. 4客户关系
  5. 5活动 / 项目服务
  6. 6埋点与标签

访客可能只有 openId，也可能补充 unionId、手机号和渠道信息。用户中心兼容营销云旧表，同时组装 tenantId、domain、channel 等上下文；业务服务不再各自判断用户来源，而是沿统一身份继续处理活动、客户和行为数据。

角色统一让多个入口共享权限

  1. 1顾问 / 自渠 / 经纪人
  2. 2租户与组织
  3. 3系统角色
  4. 4工作台 / PC 管理后台

历史系统中管理员、顾问和自渠的身份判断分散在不同入口。角色统一方案在创建业务身份时建立对应管理员与系统角色关系，登录和用户详情返回身份列表，前端据此决定入口和能力；离职时撤销角色，避免残留权限。

支付中心把渠道差异收进一个边界

  1. 1业务服务下单
  2. 2payment-center
  3. 3third-platform
  4. 4渠道回调
  5. 5支付成功事件
  6. 6业务订阅方

优惠券、报名或其他业务不直接重复编写微信支付逻辑。支付中心保存支付和退款流水，回调确认后发布支付成功事件；业务方按 payPositionType 等业务标识筛选自己的事件并完成后续处理。

事件中心削弱主请求耦合

  1. 1业务动作
  2. 2事件发布
  3. 3MQ / 事件中心
  4. 4订阅服务 / 飞书 / WebHook
  5. 5消费状态

绑定手机号、用户登录、活动变化和支付成功等动作会触发多个下游行为。事件中心统一事件模型、发布、订阅、延迟消息和消费完成度，业务服务只提交事实，下游按订阅关系独立扩展。

数据从业务事实走向自助分析

  1. 1业务表 / 埋点
  2. 2data-collect / statistics-adapter
  3. 3tag-tidy / cdp-lifecycle
  4. 4DaaS 模型
  5. 5报表 / 人群 / 运营动作

埋点采集与业务表同步分别处理，生命周期规则把行为映射为用户状态，ClickHouse 位图支持人群计算，DaaS 通过维度和指标模型生成表格、KPI、图表与导出任务。分析侧复用模型，而不是为每个业务页面单独编写 SQL 接口。

07

关键机制与取舍

01用用户中心承接历史兼容和统一身份

约束
旧表和新平台同时存在，访客、管理员、顾问和自渠在不同端的身份来源不同；直接重写会影响历史业务。
做法
保留 user-info 适配层兼容 im_visitor、公众号记录等旧逻辑，由 Zeus 用户中心承担标准用户创建、查询和上报；在边界处补充租户、渠道和特殊第三方映射，登录接口返回身份列表而不是单个布尔字段。
效果
新入口可以复用统一用户模型，历史业务继续运行，角色扩展从入口判断转为关系数据和权限策略。

02用事件中心拆出跨服务副作用

约束
主业务接口中混入通知、统计、积分、外部同步等逻辑，会让接口变慢，也会让新增订阅方反复改核心服务。
做法
定义 source、type、eventId、time、data 等事件模型，生产方通过 SDK 投递，服务端负责存储、分发、延迟和消费状态；消费方以业务标识幂等处理，必要时支持补偿和重推。
效果
核心请求保持清晰，下游能力可以独立接入；消息重复和消费延迟成为可观测状态，而不是隐藏在接口超时里。

03用支付中心屏蔽渠道差异

约束
多个业务服务各自对接微信支付会复制报文、回调和退款代码，后续接入支付宝、银联等渠道的成本会线性增加。
做法
payment-center 负责统一请求对象、支付 / 退款流水和回调入口，third-platform 负责对外渠道协议；支付成功后进入事件中心，业务方根据自己的业务位置处理结果。
效果
渠道接入和业务处理分离，支付流水可在后台统一查询，业务服务只依赖稳定的支付契约。

04用模型复用支撑自助分析

约束
营销云报表维度和指标多，直接为每个页面写接口会造成 SQL 复制、口径漂移和多模型组合困难。
做法
DaaS 以模型定义维度、聚合指标、虚拟指标和过滤条件；查询时按指标选择模型，通过共享维度在内存中关联结果，并将用户中心 iid 用于圈人过滤和位图计算。
效果
报表从接口开发转为模型配置，支持多维查询、下钻、导出和定时任务，业务团队可以复用同一套指标定义。

05用事实数据和异步通知处理一致性

约束
外部回调、消息投递和数据同步都可能重复、延迟或中断，单次成功响应不能证明全链路完成。
做法
业务服务先保存本地事实，再通过事件、任务或同步适配器推进下游；消费记录、状态字段、业务唯一键和补偿任务共同约束重复处理，数据打通问题通过增量 / 存量分开治理。
效果
能够区分“本地已成功、消息未达、外部未确认、数据待修复”等状态，排障和回放有明确入口。
08

项目经验沉淀

整理这组项目时，先以目录和仓库清单建立范围，再用 README、POM、接口模块和业务文档核对职责，最后将经验写成可复用的业务与技术链路。

  1. 1建立地图区分 company 主线、useproject 服务集、前端、文档和构建产物
  2. 2确认边界从 POM、README、Feign、starter 和源码包名确认服务职责
  3. 3串联链路把用户、活动、支付、事件、数据和外部系统放进同一条业务路径
  4. 4提炼取舍围绕身份统一、异步解耦、支付抽象、模型复用和事实一致性写出约束
  5. 5标注证据区分代码快照、方案文档、业务复盘和归档统计，避免把推断写成线上指标
  6. 6持续复用将服务边界、排障路径和交付判断沉淀为后续架构与项目实践素材
目录 + 代码

服务边界

用仓库、模块、POM 和源码包名确认项目不是只按文件夹命名。

方案 + 复盘

业务因果

用用户中心、事件中心、审批、数据分析和业务周报补足代码之外的目标与约束。

事实 + 边界

表达口径

把归档扫描统计和已验证事实分开，不把项目快照包装成当前生产容量承诺。

没有采用的表达方式

  • 按项目名堆目录目录只能说明存在什么，不能解释业务怎样流动；文章改用用户、事件、支付和数据链路串联。
  • 把 company 和 useproject 当成两个互不相关的系统两者更像主线实现与服务化项目集的不同视角，文章保留演进关系。
  • 把技术栈当成项目成果Spring Boot、Redis 和消息队列只是工具，成果需要落到身份、状态、一致性和交付能力。
  • 把归档统计当成生产指标仓库数量和模块数量用于说明范围，不替代线上容量、SLA 或客户验收数据。
09

产品界面

思为科技营销云 · 业务域与服务集思为科技营销云：业务主线、领域服务和数据智能的长期演进。
10

阶段成果

  • 把 company 与 useproject 中分散的业务、平台、数据和智能项目组织成一张营销云能力地图。
  • 形成从用户触达、身份统一、客户经营、活动转化、支付交易到数据分析的完整叙述。
  • 提炼出事件解耦、支付抽象、模型复用、租户角色和事实优先等可迁移的工程判断。
  • 项目经验以代码目录、服务 README、POM 依赖、技术方案和业务复盘相互印证，避免只按项目名推测。

继续浏览

思为科技营销云 · 思为科技营销云 · 业务域与服务集
100%
思为科技营销云放大预览

思为科技营销云 · 业务域与服务集

别急，先让缓存热一下。