企业级微服务基础平台设计
企业级微服务基础平台设计
当公司同时有几十个系统在跑,每个系统都自己实现一遍登录、权限、菜单、数据同步,这就是巨大的浪费。基础平台的价值,是把这些重复建设收敛成一套统一能力。
为什么要做统一技术底座
接手基础研发后我面对的现实是:公司内部巡检、安全、应急、设备、GIS、气量等业务系统,加上 ERP、客服、营收等外部系统,各自为战。同样的认证逻辑被写了十几遍,安全策略不统一,新项目交付周期长。
统一底座要解决三个核心问题:重复建设、安全不统一、交付慢。
通用能力的抽象
经过梳理,我们把所有系统的共性能力抽象成下面几块:
| 能力 | 解决什么问题 |
|---|---|
| 统一认证 | 一个账号登录所有系统(SSO) |
| RBAC 权限 | 统一的用户-角色-资源授权模型 |
| 多租户 | 不同客户/组织数据隔离 |
| 菜单集成 | 各系统菜单统一编排到门户 |
| 主数据同步 | 用户、组织等基础数据一处维护、多处使用 |
| 文件服务 | 统一的文件上传、存储、访问控制 |
| 消息通信 | 系统间异步消息与轨迹数据通道 |
| 定时任务 | 统一的任务调度与监控 |
这些能力每一个单独看都不难,难的是把它们收敛成一套稳定、可复用、可运维的体系。
关键技术决策
认证:JWT 还是 Session?
内部系统选择 OAuth2 + JWT:无状态、适合微服务横向扩展,配合网关做统一鉴权,业务服务不再各自实现登录。
权限:RBAC + 数据权限
角色-资源-权限是基础,但企业场景还缺一层数据权限——同一个角色在不同租户/组织下,能看的数据范围不同。我们把数据权限做成可插拔的过滤器,在数据访问层统一拦截。
多租户:共享库 + 字段隔离
早期用”每租户一库”成本太高,最终选择共享库 + tenant_id 字段隔离,通过 MyBatis 拦截器自动注入租户条件,业务代码无感知。
落地效果
平台建成后,新项目接入从”从零开发”变成”引依赖 + 配置”,交付周期显著缩短。更重要的是,安全策略和基础能力终于有了统一的治理入口。
小结
基础平台的设计核心是抽象:从几十个系统里识别出真正的共性,把它做厚,让业务系统变薄。这个”厚底座 + 薄业务”的格局,是支撑公司技术体系从单体走向微服务、再到云原生的关键一步。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 高晓庄 札记!
