联犀是如何架构好一个既要又要的系统
约 1968 字大约 7 分钟
2025-03-03
很多团队在后端架构上都会遇到同一个矛盾：
- 业务早期希望部署简单、成本低、调试方便。
- 业务增长后又希望服务能独立扩缩、独立演进、按模块拆分。
问题不在于“单体好还是微服务好”，而在于系统一开始怎样设计，才能不把自己锁死在某一种部署形态里。
联犀当前的答案不是在单体和微服务之间二选一，而是把两者真正统一到一套代码组织和调用模型中。
为什么传统二选一容易走偏
如果一开始只按单体来写，最常见的问题不是部署简单，而是边界不清。
当业务量上来以后，原本写在一起的逻辑、数据访问和依赖关系会让拆分代价极高。
如果一开始就按纯微服务来拆，另一个问题又会出现：
- 服务数量暴涨
- API 网关跟着膨胀
- 小团队在早期要承担过高的部署与运维成本
- 很多本该靠近的数据和逻辑被人为拆远
真正麻烦的点，不是“服务数量多”，而是业务边界、调用方式和部署方式被强绑定了。
联犀当前的设计思路
联犀现在的后端结构，核心是三件事：
- 模块边界按业务能力划分，而不是按部署数量划分。
- 对外接口尽量稳定，内部同时支持 RPC 调用和进程内直连调用。
- 让一个宿主既能承载多个相关领域，又保留未来独立拆分的能力。
这使得系统既可以按微服务运行，也可以在低成本场景下以融合式宿主运行。
当前的整体模块
后端采用 Go Workspace 组织，主要分成四个模块：
core：SaaS 中台与 AI 中台能力things：物联网平台能力share：公共基础库mall：商城相关能力
这里最关键的是 share。
它不是随手放工具函数的目录，而是承载上下文、缓存、事件、存储、基础客户端等公共能力的底层模块。core 和 things 在上层组合这些能力，而不是互相形成混乱依赖。
服务拆分不是越细越好
联犀现在并不追求“一个领域一个独立宿主”。
更重要的原则是：高耦合、共享上下文重、经常一起演进的能力，应该放在同一个物理宿主里。
例如物联网侧当前的 dmsvr，就不是狭义上的“设备管理服务”了。
它已经演进成一个融合式宿主，统一承载：
- 设备管理
- 设备网关主链路
- MQTT 宿主能力
- 协议脚本运行时
- 时序数据仓储
这类设计的价值很直接：
对外仍然是清晰的 API / RPC 能力边界，对内则避免为了“拆而拆”引入大量无效网络跳转。
API、RPC 和直连为什么能同时成立
很多系统在设计之初就把“调用方式”和“部署方式”绑死了。
一旦某个服务通过 RPC 暴露出去，业务代码就只能接受远程调用模式，后续再想融合部署往往要重写一套逻辑。
联犀做法不同。
当前大量客户端代码在生成后会同时保留两类实现：
- grpc 客户端实现
- direct 直连实现
两者对上层暴露的是同一套接口。
也就是说，业务逻辑关注的是“我要调用哪个能力”，而不是“这个能力当前是远程服务还是进程内对象”。
这样带来的好处有三个：
1. 微服务模式可保留
当某个模块需要独立部署、独立扩容时，直接走 grpc 即可。
2. AllInOne 或开发环境可降成本
在一体化部署、开发环境、低成本环境中，可以直接切到直连实现，减少网络跳转和部署复杂度。
3. 架构演进不必重写业务逻辑
服务是独立运行还是融合运行，更多变成初始化和装配层的选择，而不是业务层的大重构。
为什么 API 网关也不能乱拆
纯微服务体系里，经常会演变成“一个 RPC 服务一个 API 网关”或者“一个业务一个 BFF”。
这在复杂前端场景下有时合理，但在很多 SaaS 和 IoT 场景里会迅速变成负担。
联犀更倾向于按大业务域聚合 API 网关：
core侧聚合中台能力things侧聚合物联网能力
这样做不是偷懒，而是承认一个事实：
很多接口虽然来自不同内部能力，但在前端和外部使用视角上属于同一类业务域。
如果网关也跟着过度拆分，最终只会带来：
- 认证与中间件重复
- 路由与文档分散
- 部署面增大
- 业务方理解成本提高
当前架构里另外两块关键基础设施
只把服务拆分和调用方式统一还不够。
一个既要快速开发、又要可扩展的系统，还必须把横切能力做好。
WebSocket
联犀当前的 WebSocket 已经不是简单的“连接后维护一个订阅表”。
它采用了 Hub、Trie、频道模型、自动订阅和命名空间鉴权这套新结构，让实时推送可以在多业务场景里复用，而不是每个模块都自行维护长连接体系。
Hook 扩展机制
旧时代很多系统用“插槽”或者模板回调来扩展业务。
联犀当前已经把这部分升级成 Hook 体系，通过 HookServer、HookCapability、标准协议、失败策略和重试策略，把扩展点变成正式架构能力。
这样一来，像订阅鉴权、数据过滤、设备下发前处理这类能力，就不用硬编码在主流程中。
这种“既要又要”的前提是什么
想让系统既能微服务、又能融合部署，不是靠口号，而是必须满足几个前提：
1. 边界先清楚，部署后灵活
先把业务边界和接口边界设计清楚，再去决定最终怎样部署。
不要反过来用部署方式倒逼业务结构。
2. 公共基础库要稳
上下文、事件、存储、缓存、日志、错误模型如果不稳定，就很难支撑“同一业务在不同宿主形态下复用”。
3. 不要为了通用而过度抽象
联犀的目标不是做一个能适配所有场景的空壳框架，而是围绕当前 SaaS + IoT 场景，把真正高频的调用方式和部署模式统一起来。
总结
联犀当前的后端架构，本质上是在解决一个很实际的问题：
系统如何同时拥有以下能力，而不把自己写崩：
- 既能低成本部署，也能按需拆成微服务。
- 既能快速开发，也能保持清晰边界。
- 既能让相关能力在一个宿主里高效协作，也能在需要时独立扩缩。
它依赖的不是某一个“神奇框架特性”，而是一整套配合：
- 模块边界合理划分
- API / RPC / 直连三种调用方式统一
- 融合式宿主承载高耦合领域
- WebSocket、Hook、事件总线等基础设施下沉
当这些基础打稳以后，所谓“既要又要”就不再是空话，而是可以长期演进的工程现实。
更新日志
2026/5/18 10:48
查看所有更新日志
43ef3-docs(blog): 新增后端与架构系列技术博客 18 篇，更新原有 7 篇于d4fa0-doc: 更换皮肤到最新版于50fd1-doc: 完善文档于
