业务主线
业务连续性承载营销云完整业务链路、历史兼容逻辑、公共模块和前端入口。
- 实现
- 围绕用户、客户、活动、内容、交易、企微和第三方服务组织代码，通过公共 starter、Feign 和基础组件复用能力。
- 输出
- 存量客户的入口、表结构和接口保持可用，新需求可以追到入口、服务、数据库和外部系统。
- 边界
- 历史表结构和兼容逻辑仍在主线中，改动需要评估旧入口影响。
Skip to content
跳到项目内容多个入口先经过鉴权与用户中心，客户、活动和交易服务产生业务事实；支付中心和第三方接入服务处理渠道协议，事件中心把事实分发给数据与智能链路。 业务入口、公共能力与数据智能营销云的业务入口、公共能力与数据智能分层。
- 01触达小程序 · H5 · 企微 · PC · 销冠
访客、顾问、经纪人和管理员进入不同工作入口
- 02识别Auth · User Center
租户、组织、角色和渠道形成统一上下文
- 03经营Customer · Activity
客户、项目、活动、内容和线索协同推进
- 04交易Payment · Sign
支付、签约、佣金和外部 ERP 状态协作
- 05事件Event Center
通知、异步订阅、延迟任务和消费追踪
- 06分析CDP · DaaS · NLP
标签、生命周期、报表和录音智能沉淀经营结果
项目速览
业务背景
思为科技营销云服务地产营销场景，业务入口包括微信小程序、企微工作台、PC 管理后台、销冠应用和 H5，并与外部合作系统打通。系统在保持存量业务运行的同时，把用户中心、权限体系、事件中心、支付中心、数据采集与自助分析抽成公共能力，营销云业务按领域拆分，数据平台和 AI/NLP 服务独立演进，覆盖访客触达、客户运营、活动转化、交易协同和经营分析。
负责范围
- 后端负责人：划分营销云服务边界，推进业务主线向领域服务拆分
- 用户中心兼容旧表，统一租户、组织与角色关系
- 事件中心与支付中心的模型、投递、回调和幂等约定
- CDP 标签、生命周期与 DaaS 指标模型的数据链路
- 多环境配置、容器化发布与定时任务的运行规范
106 项
服务仓库
营销云领域服务、平台底座、DaaS、CDP、开放平台和 AI/NLP 等仓库的登记条目。
140 个
Maven 模块
服务与公共模块的拆分规模，是代码统计，不代表线上实例数量。
5 类
业务入口
微信小程序、企微工作台、PC 管理后台、销冠应用和 H5 共用同一套身份与权限模型。
01
核心业务
思为科技营销云面向地产营销团队，业务入口包括微信小程序、企微工作台、PC 管理后台、销冠应用和 H5，并与外部合作系统打通。访客从项目和内容浏览开始，经过身份识别、活动报名、线索与客户经营，最终进入交易、支付、签约和经营复盘。难点不在单个接口，而在跨租户、跨角色、跨服务、跨外部平台时，身份、状态和数据口径仍然一致。
系统经历了两个阶段。早期的业务主线集中承载用户、客户、活动、内容、签约和企微等能力，并保留大量历史表结构与兼容逻辑。随后在不中断存量业务的前提下，把身份、事件、支付、配置、文件和第三方接入抽成平台能力，营销云业务按领域拆分，数据平台和 AI/NLP 服务独立演进。
- 01业务主线与历史兼容
- 认证鉴权、权限、客户、用户、活动、内容、签约、项目、企微、支付和前端入口保持完整链路，早期表结构、接口和兼容逻辑继续服务存量客户。
- 02领域服务与平台能力
- 营销云领域服务、平台底座（租户、用户、网关、应用）、开放平台、数据平台和 AI/NLP 独立维护；活动、支付、事件、用户、配置、文件和第三方接入通过 Feign 接口与 starter 形成服务契约。
- 03用户与身份
- 访客、经纪人、顾问、自渠、管理员和系统角色来自不同入口，由用户中心、租户、组织和角色关系统一表达，业务服务从上下文读取身份和数据范围。
- 04客户经营与营销活动
- 活动主表、上下架、报名、线索、客户关系、客户描摹、全渠道来源、渠道风控和项目服务构成营销云的核心业务层。
- 05交易、支付与外部协同
- 支付中心收敛渠道差异，第三方接入服务统一对接微信等外部平台；签约、佣金、ERP、企微和数据打通服务把业务状态同步到外部系统。
- 06数据、分析与智能
- 埋点、数据采集、用户标签、生命周期、ClickHouse 位图、DaaS 多模型报表和录音 / NLP 服务把业务事实转化为运营洞察。
02
演进阶段
领域服务化
服务契约把身份、事件、支付、配置、文件和第三方接入抽成平台能力，营销云业务按领域拆分。
- 实现
- 平台底座承担租户、用户、网关和应用；业务服务通过 Feign 接口模块和 starter 依赖平台能力，各自独立发布。
- 输出
- 公共能力只实现一次，新业务按契约接入，发布和故障范围按服务收敛。
- 边界
- 服务数量增加后，跨服务调用链和接口版本需要靠契约与链路追踪约束。
数据智能
事实到洞察把埋点、业务数据、标签、生命周期、报表和 NLP 能力连接起来。
- 实现
- 采集器和适配器沉淀事实，CDP 与位图完成用户分群，DaaS 模型负责指标和维度，录音与语义服务补充案场接待分析。
- 输出
- 运营侧得到可下钻报表、用户人群、行为轨迹和销售接待分析。
- 边界
- 指标口径、数据延迟和外部打通质量需要按租户分别验收。
03
技术栈
- 业务服务
- JavaSpring BootMyBatis-PlusMavenFeign
- 数据与消息
- MySQLRedisMongoDBKafka / RabbitMQClickHouse
- 平台能力
- NacosDockerKubernetesXXL-JOBPrometheus
- 业务接入
- 微信小程序企微飞书抖音 / 百度OSS支付渠道
- 数据与智能
- DaaS 报表CDP 生命周期用户标签NLP / 录音分析
- 前端与交付
- Vueuni-app / 微信小程序GitLab CI多环境配置
04
系统架构与部署
业务入口
微信小程序 / 企微 / PC / 销冠应用 / H5按用户角色和使用场景提供不同入口，入口层只负责交互与凭据，不重复实现客户、支付和权限规则。
核心服务
Spring Boot / MyBatis-Plus / Feign / Maven服务按用户、活动、客户、内容、交易和平台能力拆分；公共 starter 和接口模块减少重复接入。
数据与消息
MySQL / Redis / MongoDB / Kafka / RabbitMQ / ClickHouse关系数据保存业务事实，缓存与锁服务于热路径，消息承担事件传播，分析数据进入报表和标签模型。
运行与交付
Nacos / Docker / Kubernetes / XXL-JOB / GitLab CI不同环境使用独立配置和发布目标，定时任务、日志、监控和镜像交付共同支撑业务服务运行。
05
复杂度：四个“多”决定了服务边界
同一套服务要同时面对多个入口、多个租户、多种处理节奏和多套外部系统，边界划分围绕这四类差异展开。
- 多入口
- 小程序 / H5 / 企微 / PC / 销冠
- 多租户
- 组织 / 项目 / 渠道
- 多节奏
- 同步请求 / 异步事件 / 分析任务
- 多系统
- 微信 / 企微 / ERP / 飞书 / 支付渠道
同一用户可能在多个入口出现，身份和权限在服务端统一。
业务数据和角色范围按租户、组织和项目隔离，外部打通保留来源上下文。
实时接口、消息消费、定时任务和报表查询使用不同的超时、重试和一致性策略。
外部系统差异收敛在适配层，业务服务通过内部 DTO 和事件模型保持稳定。
以上是架构层面的约束与取舍，不代表某个客户环境的容量或 SLA 承诺。
06
核心业务链路
访客从小程序进入客户经营链路
- 1微信小程序
- 2鉴权 / 用户中心
- 3访客与手机号
- 4客户关系
- 5活动 / 项目服务
- 6埋点与标签
访客可能只有 openId，也可能补充 unionId、手机号和渠道信息。用户中心兼容营销云旧表，同时组装 tenantId、domain、channel 等上下文；业务服务不再各自判断用户来源，而是沿统一身份继续处理活动、客户和行为数据。
角色统一让多个入口共享权限
- 1顾问 / 自渠 / 经纪人
- 2租户与组织
- 3系统角色
- 4工作台 / PC 管理后台
历史系统中管理员、顾问和自渠的身份判断分散在不同入口。角色统一方案在创建业务身份时建立对应管理员与系统角色关系，登录和用户详情返回身份列表，前端据此决定入口和能力；离职时撤销角色，避免残留权限。
支付中心把渠道差异收进一个边界
- 1业务服务下单
- 2支付中心
- 3第三方接入服务
- 4渠道回调
- 5支付成功事件
- 6业务订阅方
优惠券、报名或其他业务不直接重复编写微信支付逻辑。支付中心保存支付和退款流水，回调确认后发布支付成功事件；业务方按支付所属业务位置等标识筛选自己的事件并完成后续处理。
事件中心削弱主请求耦合
- 1业务动作
- 2事件发布
- 3MQ / 事件中心
- 4订阅服务 / 飞书 / WebHook
- 5消费状态
绑定手机号、用户登录、活动变化和支付成功等动作会触发多个下游行为。事件中心统一事件模型、发布、订阅、延迟消息和消费完成度，业务服务只提交事实，下游按订阅关系独立扩展。
数据从业务事实走向自助分析
- 1业务表 / 埋点
- 2数据采集 / 统计适配
- 3用户标签 / 生命周期
- 4DaaS 模型
- 5报表 / 人群 / 运营动作
埋点采集与业务表同步分别处理，生命周期规则把行为映射为用户状态，ClickHouse 位图支持人群计算，DaaS 通过维度和指标模型生成表格、KPI、图表与导出任务。分析侧复用模型，而不是为每个业务页面单独编写 SQL 接口。
07
关键机制与取舍
01用用户中心承接历史兼容和统一身份
- 约束
- 旧表和新平台同时存在，访客、管理员、顾问和自渠在不同端的身份来源不同；直接重写会影响历史业务。
- 做法
- 保留用户信息适配层兼容旧访客表、公众号记录等旧逻辑，由平台用户中心承担标准用户创建、查询和上报；在边界处补充租户、渠道和特殊第三方映射，登录接口返回身份列表而不是单个布尔字段。
- 效果
- 新入口可以复用统一用户模型，历史业务继续运行，角色扩展从入口判断转为关系数据和权限策略。
02用事件中心拆出跨服务副作用
- 约束
- 主业务接口中混入通知、统计、积分、外部同步等逻辑，会让接口变慢，也会让新增订阅方反复改核心服务。
- 做法
- 定义 source、type、eventId、time、data 等事件模型，生产方通过 SDK 投递，服务端负责存储、分发、延迟和消费状态；消费方以业务标识幂等处理，必要时支持补偿和重推。
- 效果
- 核心请求保持清晰，下游能力可以独立接入；消息重复和消费延迟成为可观测状态，而不是隐藏在接口超时里。
03用支付中心屏蔽渠道差异
- 约束
- 多个业务服务各自对接微信支付会复制报文、回调和退款代码，后续接入支付宝、银联等渠道的成本会线性增加。
- 做法
- 支付中心负责统一请求对象、支付 / 退款流水和回调入口，第三方接入服务负责对外渠道协议；支付成功后进入事件中心，业务方根据自己的业务位置处理结果。
- 效果
- 渠道接入和业务处理分离，支付流水可在后台统一查询，业务服务只依赖稳定的支付契约。
04用模型复用支撑自助分析
- 约束
- 营销云报表维度和指标多，直接为每个页面写接口会造成 SQL 复制、口径漂移和多模型组合困难。
- 做法
- DaaS 以模型定义维度、聚合指标、虚拟指标和过滤条件；查询时按指标选择模型，通过共享维度在内存中关联结果，并将用户中心 iid 用于圈人过滤和位图计算。
- 效果
- 报表从接口开发转为模型配置，支持多维查询、下钻、导出和定时任务，业务团队可以复用同一套指标定义。
05用事实数据和异步通知处理一致性
- 约束
- 外部回调、消息投递和数据同步都可能重复、延迟或中断，单次成功响应不能证明全链路完成。
- 做法
- 业务服务先保存本地事实，再通过事件、任务或同步适配器推进下游；消费记录、状态字段、业务唯一键和补偿任务共同约束重复处理，数据打通问题按增量和存量分开治理。
- 效果
- 能够区分“本地已成功、消息未达、外部未确认、数据待修复”等状态，排障和回放有明确入口。
08
服务化演进
服务化不是一次性重写：先在边界处建立适配层和契约，再把公共能力逐个抽出，业务主线在整个过程中持续运行。
- 1兼容旧身份用户信息适配层承接旧表，用户中心负责标准创建与查询
- 2抽出公共中心事件、支付、配置与文件能力独立成服务
- 3契约化接入Feign 接口模块与 starter 统一依赖方式
- 4异步化副作用通知、统计和外部同步改为订阅事件
- 5数据模型化埋点与业务事实进入 CDP 标签和 DaaS 模型
- 6多环境交付Nacos 配置、容器镜像与 GitLab CI 分环境发布
旧入口不断
兼容
旧表、旧接口和公众号记录经适配层继续工作，迁移按入口逐步推进。
幂等 + 补偿
一致性
业务唯一键、消费记录和补偿任务约束重复投递与中断。
模型配置
报表口径
维度和指标定义集中维护，避免各页面 SQL 口径漂移。
没有采用的做法
- 一次性重写用户体系历史业务依赖旧表和旧接口，直接替换会中断存量入口；改为适配层逐步迁移。
- 各业务各自对接支付渠道报文、回调和退款代码会被复制，每接一个新渠道都要改多个服务。
- 在主请求里同步执行副作用通知、积分和外部同步拖慢核心接口，新增订阅方需要反复修改核心服务。
- 每张报表写一套 SQL 接口SQL 复制、口径漂移，多模型组合困难；改为 DaaS 指标模型。
09
架构总览
10
阶段成果
- 业务主线与领域服务并行运行：旧表和旧接口经适配层继续服务，新入口复用统一用户模型与角色关系。
- 渠道支付收敛到支付中心，业务方订阅支付成功事件处理结果，不再各自对接微信支付。
- 通知、统计和外部同步从主请求移入事件中心，消费状态可查询，失败可以补偿重推。
- 报表开发从逐页写接口转为 DaaS 模型配置，支持多维查询、下钻、导出和定时任务。
继续浏览
别急，先让缓存热一下。