微服务
多进程独立部署，各自数据库，RPC/消息通信
深浅模式
为什么不用微服务
很多客户在评估社区平台时都会问：能不能拆成微服务？为什么灵萌是一个程序包，而不是十几个独立服务？
面向 部署负责人、技术决策者与运营方 · 当前方案：模块化单体（Modular Monolith）
先分清两个概念
「30 个业务模块」是代码与职责划分，对外交付仍是 一套服务 + 一个安装包，而不是 30 个容器。
模块化单体
一个 lingmeng 二进制，内部按业务划分子模块，统一装配
功能模块（商业）
圈子、外卖、AI 等按授权在后台开关
为什么不采用微服务
共 5 条 · 点击展开详情
- 发笔记 → 评论/审核 → 通知 → 搜索索引
- 下单 → 统一订单 → 支付 → 账本 → 退款/提现
- 私聊/群聊 → WebSocket → 红包/转账仍走支付链路
- 外卖/跑腿 → 订单、骑手、地图、支付在同一事务链上
单体内部用统一基建解决模块协作：同类能力只实现一次，各业务复用，禁止各搞一套。
灵萌实际采用什么架构
1
30 个业务模块圈子、消息、支付、外卖、AI… 各管一块，统一五层结构
2
pkg/ 横切能力缓存、锁、幂等、状态机、区域配置、通知、账本等只实现一次
3
bootstrap/wiring启动时装配依赖、注册跨模块回调，边界清晰但不跨进程
4
架构守卫（CI）禁止跨模块直连仓储、Handler 写 SQL，防止单体变泥球
轻量拆分：API 与 Worker
同一套代码、同一配置、同一数据库 — 进程级分工，不是按域拆微服务
full默认：HTTP API + WebSocket + 定时任务 + 队列消费worker仅跑后台任务与健康检查（可不对外提供业务 HTTP）http_only只提供 API，暂不跑部分消费者异步与可选组件
- 搜索索引同步 → Outbox + Meilisearch（可选）
- 推荐 → Gorse（可选）
- 通知、模板消息 → 队列与 worker
这种架构带来的好处
对你（部署与运营）
- 部署简单一个安装包、MySQL + Redis，快速部署即可上线
- 排障路径短日志、配置、版本在一处，不用跨十几个服务查链路
- 升级可控替换二进制 + 内嵌 SQL 迁移，更新流程清晰
- 按模块开通未买的功能不占菜单，已买的在同一 App 里连贯使用
对业务正确性
- 交易链路统一所有支付走统一订单、支付与账本
- 身份与权限统一用户、商家、骑手、管理员同一套体系
- 审核/评论/联动统一全站一套评论、审核、内容挂载
- 多区域可配置全站默认 + 区域覆盖，一套系统服务多校区
对长期演进
- 模块边界清晰按域分包，将来若需拆服务有明确切口
- 统一规范与 CI架构守卫、统一 DTO/权限门面，降低协作成本
- 可选 scale-outworker 独立进程、Redis 队列，按量加机器而非一步到位 K8s
Nginx→lingmeng full
worker 可选·MySQL·Redis·Meilisearch / Gorse 按需
什么时候才需要考虑微服务
适合超大流量、超大团队、域之间几乎无强事务、且有专职 SRE 的产品。灵萌目标场景：
演进路径（而非默认上微服务）
- 1先水平加 worker、读写分离、缓存与索引优化
- 2再考虑把个别域（如搜索、推荐）外置为独立组件
- 3只有客户基础设施与团队就绪时，才评估完整微服务化
和「功能模块总览」的关系
后台「我的模块」开通/关闭商业授权 + 菜单可见性，不是多装几个 Docker
功能模块总览里的 30+ 能力产品能力地图 + 配置入口
一个 lingmeng 进程承载已开通的全部能力