一、业务定位
「我的粉丝馆」会员运营与营销中台的后端服务,采用 Go + Gin 框架开发,持久化使用 (GORM 驱动),缓存支持 Redis 与本地内存双模式切换,并内置 pprof 性能分析、HTTPS 开关、IP 限流等运行期能力。系统面向 C 端会员小程序与 B 端运营后台),同时通过对外暴露接口,与 商城、微信公众号、企业微信完成对接。
二、功能模块
1. 系统管理(`internal`):用户、角色、权限、组织、菜单、操作日志、系统配置、数据字典(常量及常量分组)等 RBAC 基础能力,登录支持单点 SSO,Token 校验统一由全局拦截器 `Filter()` 完成,并配置白名单与秒级限流。
2. 会员管理(`membermanagement`):会员档案(含微信登录/注册、手机号解密、等级等级更新)、会员资产看板、等级体系、积分明细、金币明细、余额及余额提现;定时任务负责每日积分/金币结算、企业微信社员同步、客户标签与备注批量刷新。
3. 营销活动(`promotionalactivities`):优惠券管理与发券到会员、抽奖活动(奖品、中奖人、抽奖记录)、活动管理(含与商城的数据同步接口)、秒杀及秒杀商品、员工内购与员工采购。通过 Cron 定时刷新活动状态、重建优惠券有序集合、按订单抽奖。
4. 门店与页面管理(`storemanagement`):门店地址、系统配置、页面与页面组件配置、大屏推送数据,实现运营页面的可视化配置下发。
5. 对外集成接口:微信/企业微信 token 与接口信息维护、物流轨迹同步与传运单、退货申请与售后审核结果通知、金币到期标签时间更新等。
三、技术特征
代码采用 controller → service → logic → dao 分层,实体按业务域命名;通过 `robfig/cron` 编排十余个定时任务,覆盖数据同步、权益结算、token 刷新与消息推送;日志采用分级轮转,敏感字段做加密处理。
1、整体架构和设计思路,不同模块使用的技术栈
架构选型:模块化单体(Modular Monolith)
我的粉丝馆」的后端服务,没有走微服务,而是把 4 个业务域收敛在一个 Go 进程内,靠目录 + 命名前缀做模块隔离。这样既避免了分布式事务和链路追踪的复杂度,又能让 30+ 张业务表共享同一个数据库连接池和事务。
分层设计(严格四层 + 两个公共包)
```
api/v1/controller 对外开放接口(供商城/ 微信回调)
↓
internal/controller 参数解析 + 路由自注册 + defer 统一落日志
↓
internal/service 业务编排、权限校验、事务边界
↓
internal/logic 真正的业务规则与定时任务执行体
↓
internal/dao 数据访问,复用 hack/common 的通用分页/事务
↓
internal/entity GORM 实体(32 个,对应 32 张表)
```
关键设计取舍:
- 路由自注册:每个控制器实现 `RegisterRouters(group)`,`router.SetupRouter` 只做分组组装,新增模块不用改路由文件。
- 响应零重复:RequestData 统一入参(`SID` + `DataRequest`),controller 每个方法固定 5 行模板,响应和操作日志都在 `defer TInternalSystemLogSer.ResponseHandler(...)` 里统一处理,业务代码只管 `err, resp = XxxSer.Xxx()`。
- 存储双模可切换:`InitData.OpenRedis` 为真走 Redis,为假降级到本地 `sync.Map`(`LoginCache`,带过期时间惰性清理),对上层完全透明,方便无 Redis 环境部署。
- 通用组件下沉到 `hack/`:`hack/common` 提供分页(`PageDataGet` / `PageDataGetV2` / `PageDataScan`)、反射通用 where(`dao_gorm_where.go`)、闭包式事务(`Transaction`)、日志轮转、树结构、响应封装;`hack/tool` 提供 AES / DES / MD5 / 随机数,且带单元测试。
各模块技术栈
| 模块 | 技术栈 / 关键依赖 |
|---|---|
| Web 框架 | `gin v1.9.1` + `gin-contrib/cors`,可选 TLS(`RunTLS`) |
| 配置 | `viper v1.18.2` + `fsnotify` 热加载,`manife