统一业务后台架构的一些思考

前段时间在知乎看到一个问题，问得特别扎心：
> 公司各条业务线每上线一个产品都单独开发一个后台管理系统(基础框架技术栈架构也存在不一致现象)，重复工作很多。如果做集中式，数据源独立、权限隔离难做；如果做分布式，公共部分怎么抽成服务、接入方式怎么设计、细粒度权限怎么控制，都没想清楚。有没有好的设计思路？

看完这个问题，我脑子里只有一个念头：但凡业务线超过三条、团队规模过百的公司，几乎都会撞上这堵墙。更讽刺的是，这堵墙往往不是技术问题，而是组织问题在技术层面的投影。

### 一、这不是技术选型，是治理问题
很多人一看到这个场景，第一反应是："用微服务啊！"或者"上中台啊！"但知乎那个高赞回答里有一句话特别清醒：
> **"务实及折中的做法是：集中式为主 + 分布式为辅。"**

这句话背后藏着一个很多人不愿承认的事实：**业务线之所以各自为政，不只是因为"重复造轮子"的技术惰性，更是因为每个业务线都希望自己能对业务有绝对的主控权**。

你让A业务线把自己的商户管理、用户数据全部交到一个"统一后台"里？A业务线的负责人第一反应一定是："那我的迭代速度怎么办？我的个性化需求谁来满足？"这不是技术问题，这是权力边界问题。

所以回答里提出的第一条原则就特别重要：**在产品立项评审流程里，必须加入一个评审点——这个后台是基于统一运营平台，还是单独开发？ **这不是技术评审，这是治理评审。没有这个闸口，统一架构就是一句空话。

### 二、哪些必须集中，哪些可以放手？
回答里列了四条"必须集中统一管理"的清单，我觉得可以浓缩成一个判断标准：

> **凡是跨业务线共享的、与公司经营分析相关的、涉及核心资源（商户/用户/合作伙伴）的，必须收回来。凡是业务线内部闭环的、创新试错性质的、需要快速迭代的，可以放手。**

举个例子：第三方支付公司里，用户管理、商户入网、对账、清结算——这些如果每个业务线自己做，财务对不上、风控有漏洞、合规过不了，必须集中。但某个新业务线要做一个"营销活动配置后台"，为了赶上线自己搭一个，可以理解，但得有个前提：**基础框架必须统一**。

这就是回答里说的"blank项目"概念——公司层面提供一个带基础功能的脚手架，包含组织架构、人员权限（功能权限+数据权限）、菜单管理、单点登录、工作流、操作日志。新业务线不是从零开始，而是从这个脚手架 fork 出去，既保证了风格统一，又保留了业务自主权。

### 三、Portal：被低估的"门面工程"
回答里花了不少篇幅讲"业务后台Portal"，这一点我特别认同。很多公司做统一后台，一上来就想搞个大一统的"超级Admin"，结果需求越堆越多，变成一个谁也改不动的庞然大物。
但Portal的思路很巧妙——**它不做业务，只做入口和映射。**
- 员工登录后，能看到自己有权限访问哪些业务系统的入口；
- 提供员工与各业务后台用户、角色的映射（不用到系统权限级别，只需要到"能不能进"）；
- 提供单点登录，解决"记一堆密码"的问题；
- 对接公司级公共服务（客服、财务、短信网关）。

这个设计妙在**解耦**。Portal不侵入各业务系统的权限模型，只解决"谁能不能进"的问题。各业务系统内部的"谁能做什么"，还是由各业务系统自己控制。这样既降低了集成的复杂度，又避免了"一刀切"的僵化。

更实际的价值是**降低隐性成本**。回答里提到一个特别真实的场景：员工离职了，HR流程走完了，但他在七八个业务后台里的账号可能还挂着。Portal作为统一入口，至少能把"账号生命周期管理"这件事收回来，堵住安全风险的温床。

### 四、SOA 不是银弹，但公共服务必须服务化
回答里提到做 SOA 框架。放在今天的技术语境下，可能更多人会选 Spring Cloud、Dubbo、或者 Service Mesh，但核心思路不变：
> **把跨业务线调用的公共服务抽出来，做成服务，而不是让每个业务线自己复制一份代码**。

比如商户信息查询、用户身份校验、订单状态同步——这些如果每个业务后台都自己直连数据库，数据源隔离就成了一纸空文，权限控制更是无从谈起。抽成服务后，至少能做到：
- 数据访问收口，权限控制可以在服务层统一做；
- 业务线之间通过接口协作，而不是直接扒对方的数据库；
- 公共逻辑变更时，只需要改一处。

当然，服务化也有代价——接口设计、版本管理、故障隔离、性能瓶颈，都是坑。但两害相权，**"各自直连数据库"的坑更大，而且更隐蔽**。

### 五、写在最后：架构是妥协的艺术
回看这个问题和回答，我觉得最有价值的地方在于：**它没有给出一个"标准答案"，而是给了一个务实的框架**。
统一后台架构设计，本质上是在几组矛盾之间找平衡：
- **公司统一管理 vs 业务线自主创新**
- **研发效率 vs 系统复杂度**
- **短期交付 vs 长期治理**

没有完美的架构，只有适合当前阶段的架构的取舍，本质上是在公司管理效率与业务线创新灵活性之间找平衡。业务扩张期，也许允许一定程度的"重复造轮子"，但必须画一条红线——基础框架统一、核心资源集中、公共服务服务化。等业务线从三条变到十三条，你会发现，当初那一点点"统一"的克制，省下了后面十倍的运行维护和重构成本。

就像那个回答里说的："**基本上所有的业务线都会希望自己能够对业务有绝对的主控权，也会低估自己开发的难度，因此都会选择自己做**。"

做架构的人，有时候得有点"反人性"的觉悟——**不是帮业务线把轮子造得更快，而是让他们意识到，有些轮子根本不该自己造**。

毕竟，**承认问题存在，才是解决问题的第一步**。

本文最后更新于 2026-08-08 17:19:24 并被添加「系统架构基础架构」标签，已有 68223 位童鞋阅读过。

本文作者：未来往事

本文链接：https://felixway.cn/post/724.html

本站使用「署名 4.0 国际」创作共享协议，可自由转载、引用，但需署名作者且注明文章出处

安居客网站系统架构案例分享简报

统一业务后台架构的一些思考

相关文章