第1章 OA系统现状与改造目标

一、OA系统现状与改造目标

说实话，我接触过的传统OA系统，十有八九都是单体架构。你想想看，一个公司用了五六年的OA，代码堆得跟山一样，每次改个审批流程都要重启整个服务。嗯，这其实就是典型的「单体之痛」。

我在2018年接手过一个老牌OA系统的改造项目。那套系统跑了快八年，代码量超过200万行。每次部署，光打包就要半小时。我来说说最让人头疼的几个地方：

部署慢得像蜗牛：改一行代码，就得重新编译整个WAR包。我记得有一次紧急修复一个流程bug，从改代码到上线，花了整整一个下午。为什么？因为编译、打包、停服、部署、重启，每一步都跑不掉。
耦合高到令人窒息：考勤模块和审批模块居然共用同一个数据库连接池。有一次考勤模块的慢查询，直接把审批服务拖垮了。说白了，这就是「牵一发而动全身」。
扩展难如登天：公司业务扩张，需要增加移动端审批能力。结果发现，现有的接口根本没法复用。因为所有逻辑都写在同一个Service里，拆都拆不开。

核心矛盾：单体架构下，业务增长越快，技术债务积累越重。这不是技术问题，是架构问题。

那我们要把OA改成什么样？我个人习惯，先定目标再动手。改造不是炫技，是解决问题。我总结了三个核心目标：

目标	具体含义	我在项目中的体会
高可用	单个服务挂了，不影响整体	曾经因为一个定时任务OOM，整个OA挂了2小时。微服务下，最多影响一个模块
弹性伸缩	流量大了自动加机器，流量小了自动减	月底考勤高峰期，审批服务可以单独扩容，不用管其他模块
独立部署	每个服务可以独立发版、回滚	改个审批流程，只需要重启审批服务，不用通知所有人「今晚系统停机」

这里我要说一个避坑指南：千万不要一上来就拆服务。我曾经见过一个团队，拍脑袋把OA拆成了30个微服务，结果半年都没上线。为什么？因为拆分粒度太细，服务间通信成本反而更高了。

我的建议：先做业务梳理，再定拆分边界。比如OA系统，可以先拆出「审批服务」「考勤服务」「公文服务」这三个核心域。其他的，等跑通了再说。

嗯，这里还要注意一点：数据拆分要谨慎。单体时代，所有表都在一个库里。微服务化后，每个服务要有自己的数据库。但你不能一下子全拆了。我当时的做法是：先逻辑隔离，再物理拆分。说白了，就是先分库，再分表，最后再考虑分库分表中间件。

你想想看，改造完成后，会是什么样子？

注意：微服务不是银弹。如果你的团队只有三五个人，业务也不复杂，强行上微服务只会增加运维成本。我见过太多「为了微服务而微服务」的失败案例了。

好了，这一章我们理清了「为什么要改」和「改成什么样」。下一章，我会讲讲具体的服务拆分策略——怎么把那个200万行的单体，拆成一个个可以独立运行的小服务。到时候我会拿审批流程的拆分来举例，那是我们踩坑最多的地方。