有个做机械配件的老板问我，他们官网用了快八年，最近技术团队老念叨重构，问我要不要动。我说你先别急，得看你们卡在哪。
WordPress系统跑久了，技术债这事确实存在。但不是所有技术债都得还，有些拖着拖着也没怎么样，有些才是真的拦路虎。第一步不是评估微服务好不好，是说清楚现在到底卡在哪。
重构前先把问题列清楚
很多企业一谈重构，先想选什么架构、用什么技术栈。这顺序本身就错了。你得先把现有的问题一个一个摆出来，看看哪些是系统造成的，哪些是业务造成的。
我见过有的官网，页面响应慢，不是因为PHP性能不行，是因为图片没压缩、数据库没优化、插件装了一大堆根本用不上的。这种问题你重构解决不了，你得先做个系统体检加个数据库优化。
但如果新功能确实上不动，并发一高就崩，需求响应周期从三天变成三周，这种时候老系统真的就成了业务阻力。怎么判断？业务部门提一个合理需求，技术团队评估完说要一个半月开发加一个月测试，其中两个月是在评估影响范围和写补丁。这种效率差距，是系统在说话，不是在抱怨。
WordPress微服务重构听着美填坑难
决定拆之前，得先看看自己能不能填坑。
微服务架构最难的不是拆，是拆完之后怎么跑。服务之间怎么通信、数据怎么一致性、出了问题怎么排查，这些问题在WordPress单体里根本不存在，拆出来全来了。而且WordPress这套生态，插件体系是灵魂，拆成微服务之后，插件怎么管？主题怎么维护？这些具体问题不问清楚就动手，后面的坑一个比一个深。
有个朋友在电商公司做技术负责人，前年上了微服务重构。两年过去了，bug比以前多三倍，每次发版都如临大敌。他最后悔的就是没在重构前把现有问题列清楚，高估了团队对分布式系统的驾驭能力，又低估了WordPress生态的复杂度。
还有过渡期的问题。新系统没ready，老系统不能停，意味着两套要同时跑。你以为的重构投入，可能只是实际的三分之一。人力成本不是翻一倍，是翻两倍三倍，而且这两套系统你都得养人维护。
什么时候真的该动手
说了这么多，不是说永远别动。有两种情况是真的该动。
一是业务在快速增长，老系统已经开始制约新业务上线速度。怎么判断？需求响应周期连续两个季度都在拉长，业务部门抱怨增多，这就是信号。不是技术团队说系统老了要换，是业务部门自己开始抱怨响应慢了。
二是核心人员要断层。老系统只有一个人懂，他要走的时候就是该变的时候。这不是技术判断，是业务连续性判断。这种时候不动，等这个人走了再动，代价更大。
除了这两种情况，其他的大多可以先凑合着。技术债这东西，只要不爆发，就先让它躺着。老板要管的是业务，技术的事让技术去评估。但你作为管理层，下次会议听到技术团队说架构老化要重构的时候，你第一个问题应该问什么？