是不是因为技术落后，才不做微服务？
不是。微服务适合超大规模、超大团队；灵萌的客户多是校园/区域社区、一台或几台服务器就能跑，用「一个程序 + 数据库」更划算、更稳。大公司也用单体起步，业务大了再拆。
深浅模式
为什么不用微服务
采购或运营社区平台时，常有人问：「别人都说微服务，灵萌为什么是一个安装包？」「Go 项目为什么不拆成很多服务？」
下面不用懂技术也能读明白：这不是「落后」，而是更适合大多数校园/区域社区客户的装法与用法。
一句话说明白
灵萌把圈子、外卖、支付、聊天、AI 等功能做在一个程序里——就像微信在一个 App 里就能聊天、付款、看小程序，而不是每个功能单独装一个 App。这样您上传一次就能上线，功能之间也不会「各说各话」。
面向 站长、运营负责人、采购决策者 · 当前方案：一个程序，内含多个功能模块
常见疑问
一个程序会不会很卡、撑不住人多？
绝大多数站点在优化数据库和缓存后完全够用。人真的多了，可以先加机器、加后台任务进程，搜索/推荐也可以单独装——不必一上来就拆成十几个服务。
后台「我的模块」和微服务是一回事吗？
不是。模块是您买的功能套餐（圈子、外卖、AI 等），在后台开关即可；仍然是一个 lingmeng 程序在跑，不是每开一个功能就多装一个 Docker。
那我需要懂 Go 或微服务吗？
不需要。您只需要会按文档上传程序、配 MySQL/Redis、在后台开功能。本文解释的是「为什么这样设计对您更省事」，不是让您自己改架构。
先分清三个说法
文档里常出现「30 个模块」——指的是程序内部的分工， 不是让您装 30 个 Docker。
微服务（灵萌未采用）
用户、订单、支付、消息各是一个独立程序，各自维护，互相远程调用。
打个比方：像同一商场里，每家店各有一个收银台、各有一个仓库，还要打电话对账。
灵萌的做法
对外只有一个 lingmeng 程序；内部按业务分成 30 个模块，统一账号、支付、通知。
打个比方：像一个商场只有一个总服务台，里面分餐饮、服装、娱乐等专柜，内部直接协作。
后台「功能模块」
您购买并开通的能力：圈子、外卖、AI 等。在管理后台开关，用户在同一 App 里使用。
打个比方：像办会员套餐：开通过的功能才显示，不是每买一个功能就多装一套系统。
为什么这样设计对您更省事
共 5 条 · 点击展开举例
- 发笔记 → 有人评论 → 手机收到通知 → 搜索里能搜到
- 下单 → 付款 → 余额/佣金变动 → 必要时退款
- 私聊里发红包 → 仍然走同一套支付规则
- 外卖/跑腿 → 订单、骑手、地图、支付必须一次办妥
所以灵萌在内部把账号、支付、通知、评论等做成「全站共用的一套」，避免每个业务各搞一套、数据对不齐。
对您有什么好处
对您（装站点、日常运营）
- 安装简单一个安装包 + MySQL + Redis，按快速部署文档就能上线
- 出问题好查日志、配置、版本在一处，不用猜是哪个「服务挂了」
- 升级清楚替换程序包 + 自动数据库迁移，流程固定
- 按模块开通没买的功能不占菜单，已买的在同一 App 里连贯使用
对业务（用户感知）
- 付钱、退款规则一致所有交易走同一套订单和账本
- 一个账号走天下用户、商家、骑手、管理员体系统一
- 评论、审核体验统一全站一套评论和审核，不会「这里能评那里不能」
- 多校区一套系统全站默认 + 各区域配置，不必每个校区装一套
以后人多了怎么办
- 模块边界已划好将来真要大拆，也有清晰切口，不是一团乱麻
- 先加机器、加任务进程不必第一步就上 K8s 微服务
- 搜索/推荐可外置需要时再装 Docker 组件，见可选基础设施文档
网站入口（Nginx）→灵萌主程序
后台任务（可选）·MySQL 数据库·Redis 缓存·搜索/推荐（按需）
什么时候才需要考虑微服务
通常要同时满足：流量特别大、团队特别大、各业务几乎互不牵扯、还有专职运维。 灵萌更适合的场景：
人多了可以先这样做（不必一步到位微服务）
- 1先优化数据库、缓存，必要时加「后台任务进程」或加一台机器
- 2搜索、推荐忙了，再单独装 Meilisearch / Gorse（有内存选型说明）
- 3只有流量、团队、运维都到位时，才值得评估完整微服务
和后台「功能模块」是什么关系
后台「我的模块」开通/关闭您买的功能套餐 + 菜单是否显示，不是多装几个程序
功能模块总览里的 30+ 能力产品能力清单 + 去哪里配置
一个 lingmeng 程序已开通的全部能力都在这一个程序里运行