联犀后端为什么要同时支持微服务与融合式宿主
约 2227 字大约 7 分钟
2026-05-16
很多团队在后端架构上都会遇到同一个矛盾。
业务早期希望部署简单、成本低、调试方便，最好一套服务就能把系统跑起来；但业务一旦增长，又希望服务可以独立扩缩、独立演进、按模块拆分，不要所有能力都绑死在一个进程里。
问题从来不在于“单体好还是微服务好”，而在于系统一开始怎样设计，才能不把自己锁死在某一种部署形态里。
联犀当前的答案不是在两者之间摇摆，而是把“业务边界”“调用方式”和“部署方式”拆开看。业务边界应该稳定，调用接口应该稳定，但部署形态可以随阶段变化。这种思路最终收敛成了现在的后端结构：既支持典型微服务模式，也支持融合式宿主和 AllInOne 运行方式。
单体和微服务真正的问题分别是什么
很多人对单体架构的误解，是把它等同于“简单”。实际上，单体最大的风险不是服务少，而是边界模糊。只要业务逻辑、数据访问、上下文传递和公共能力全都搅在一起，后期想拆分时，代价往往比重写还高。
而纯微服务路线的问题也不是“太先进”，而是它把很多成本前置了。服务数量、网关数量、配置数量、部署复杂度、跨服务调试成本，都会在业务还没长起来之前先压到团队头上。对于 SaaS + IoT 这类既有中台能力又有设备链路能力的系统，这种过早拆分尤其容易把本来应该靠近的数据和逻辑人为拉远。
所以真正该避免的，不是某一种架构名词，而是把业务边界直接绑到某一种固定部署模型上。
联犀当前是怎么拆这个问题的
联犀后端现在采用 Go Workspace 组织多个模块。core 负责 SaaS 中台与 AI 中台能力，things 负责物联网平台能力，share 负责公共基础库，mall 负责商城相关能力。
这层分法的重点不在“模块数量”，而在职责边界：share 作为底层公共层，不依赖 core 或 things；core 和 things 则在上层按业务域组织能力。
这样做的直接价值，是先把代码世界里的边界稳定下来。等边界清楚之后，服务可以独立部署，也可以在某些场景下被组合进同一个宿主，而不需要重写业务逻辑。
在 AI 深度参与编码之后，这种分层还有了一个新的现实价值：它让 AI 可以先锁定模块，再锁定服务，再锁定当前真正相关的代码片段。
对模型来说，最贵的往往不是代码量，而是无效上下文。边界清晰的模块化 monorepo，可以让 AI 少看很多不相关代码，把推理能力留给具体问题本身。
融合式宿主不是退回单体
很多人第一次看到“融合式宿主”会误以为这只是换个说法回到单体。其实不是。
融合式宿主的前提是：服务边界、协议边界和接口边界仍然存在，只是在运行时让高耦合、高吞吐、同链路的能力靠得更近，以减少无意义的跨进程跳转。
物联网侧的 dmsvr 就是一个很典型的例子。它不再只是狭义上的“设备管理服务”，而是承载了设备管理、网关主链路、MQTT 宿主、协议脚本运行时和时序仓储等能力。
这类能力之所以适合统一宿主，不是因为“偷懒不拆”，而是因为它们本身就共享上下文、共享设备链路、共享高频数据流。如果为了追求形式上的微服务纯度把它们机械拆开，最终只会把延迟、复杂度和调试成本全部抬上去。
为什么这种方式对联犀更合适
联犀既不是单纯的企业管理后台，也不是只有设备接入的窄场景网关，它同时要处理：
- SaaS 中台的用户、权限、租户、应用、通知、定时任务
- 物联网侧的设备管理、项目区域、协议脚本、MQTT、时序数据
- AI 侧的 Agent、记忆、MCP、设备交互
这些能力之间不是完全松散的。很多跨域调用其实是高频、短路径、强上下文耦合的。如果全部强制走远程服务调用，代价很高；但如果全部塞回一个完全无边界的大进程里，后期又无法演进。
联犀选择的路线，本质上是在这两种坏结果之间取一个工程上更稳的中间态：边界明确，但运行方式灵活。
柔性部署的前提不是“服务少”，而是“接口稳”
这也是联犀后端设计里最关键的一点。真正让系统既能微服务、又能融合部署的，不是目录怎么摆，而是接口是否稳定。
联犀当前大量能力对上层暴露的是稳定接口，而具体实现既可以是 grpc 客户端，也可以是进程内 direct 调用。这样一来，业务层关心的是“调用哪个能力”，而不是“这个能力现在到底运行在本进程还是另一个进程里”。
只要这一层稳定，部署模式就不再决定业务代码长什么样。
这也是为什么联犀能把微服务模式、AllInOne 模式和融合式宿主模式放在同一套代码体系里，而不是做三套实现。
配套基础设施为什么同样重要
如果只是把服务边界和部署模式分开，系统仍然不够稳。
要让这种架构真正可长期演进，还必须把横切能力下沉到基础设施层。
例如 WebSocket，联犀不是把长连接能力分散到各个业务服务，而是统一收敛到 Hub、频道模型、自动订阅和鉴权分发这套体系里；Hook 扩展则把很多原本容易硬编码在主流程里的扩展点，沉成了可声明、可治理、可重试的正式机制；时序数据和设备链路也通过宿主收敛和统一查询思路被稳定下来。
这些基础设施的存在，使“融合式宿主”和“微服务模式”不只是部署策略，而是可被公共层支撑的工程能力。
而当这些公共能力被稳定沉淀之后，AI 写代码时也更不容易在相似问题上反复发明新模式。
因为模型看到的不是一堆散乱实现，而是一套已经成型的骨架和公共能力面。它更容易学到“这个系统真正推荐的做法是什么”，而不是在每个子目录里看到不同风格后自行拼凑答案。
这种设计的边界是什么
当然，这并不意味着任何系统都应该照抄这种路线。
如果团队规模很大、服务边界已经高度稳定、每个子系统的扩缩容模式完全不同，那么更纯的微服务拆分可能更合适。反过来，如果业务极小且长期不会扩张，保持简单单体反而更经济。
联犀这套模式真正适合的是：既需要平台级抽象，又不希望过早承担纯微服务全部成本的系统；尤其是中台能力和设备链路能力同时存在、并且会持续演进的场景。
总结
联犀后端同时支持微服务和融合式宿主，不是为了追求概念上的“既要又要”，而是为了让系统在不同阶段都能保持合理成本和合理演进路径。
它依赖的不是某个神奇框架特性，而是一组配合起来的工程选择：
- 先稳住模块边界，而不是先锁死部署形态
- 让接口稳定，让调用实现可切换
- 让高耦合、高吞吐链路能力在宿主层合理收敛
- 把 WebSocket、Hook、时序数据等横切能力下沉成基础设施
当这些前提成立以后，所谓“既能低成本部署，也能服务化演进”，就不再是口号，而是可以长期维持的工程现实。
更新日志
2026/5/18 10:48
查看所有更新日志
43ef3-docs(blog): 新增后端与架构系列技术博客 18 篇，更新原有 7 篇于
