联犀后端为什么要同时支持微服务与融合式宿主
约 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 篇于
