在之前的架构重构内功心法“有的放矢”和“合纵连横”中，我提到架构师需要从众多问题中识别出关键的复杂度问题，并且有针对性地通过架构重构来解决这些问题。然而，通常情况下，需要进行架构重构的系统往往因为种种历史原因和历史问题未能及时处理，逐渐积累，最终到达一个临界点，各种问题开始相互作用并集中爆发。当真正开始进行重构时，架构师在识别出系统的关键复杂度问题后，如果仅针对这个复杂度问题进行重构，可能会发现仍然无法落实，因为许多必要的条件不具备或其他问题尚未解决。在这种情况下，架构师不仅需要识别系统的关键复杂度问题，还需要识别为了能够解决这个问题，需要做哪些准备工作，或者需要先解决哪些其他问题。这就需要我今天要分享的架构重构内功心法第三式：运筹帷幄。

经过分析和思考，我们可能从最初的100个问题列表中挑选出50个需要在架构重构中解决的。这些问题中有一些是基础能力建设或准备工作，而另一些则是架构重构的核心工作。有了这样一个问题列表后，我们该如何最终解决这50个问题呢？

最简单的做法是每次从中挑一个问题来解决，最终总会把所有问题都解决。这种方法虽然操作简单，但效果却很差，为什么呢？

首先，没有区分问题的优先级，所有问题一视同仁，导致有限资源没有集中去解决最重要或最关键的问题，结果是做了很久，回头一看，虽然完成了很多任务，但没有取得实质性的阶段性成果。

其次，没有将问题分类，导致相似问题没有统筹考虑，解决方案可能会重复，效率不高。

第三，面对业务版本的压力，容易挑选简单的任务来做，遇到稍微复杂的问题时，由于复杂度和投入等原因会被搁置，达不到重构的真正目的。

以X系统为例，在我加入前，系统存在的问题已经被整理出来，包括可用性、性能、安全性和用户体验等，每个大项又包括十几二十个子项。但在实施时，基本上都是挑容易完成的任务来做，结果是做了半年，虽然完成了很多功能，但整体进展却不大。

后来我们成立了一个“X项目”，在原有问题整理的基础上，识别出架构的核心复杂度主要体现在庞大的系统集成了太多功能，导致可扩展性不足；而且目前系统的可用性也不高，经常出现线上问题，耗费大量人力去处理。因此，我们进一步识别出，要进行架构重构，首先需要系统处于一个相对稳定的状态，不再频繁出现线上问题。而目前系统可用性低的原因有硬件资源不足或某些系统组件使用不合理，也有架构上的问题。

基于这些分析，我们制定了总体的策略，如下图所示。

可以看出，真正的架构重构是在第三阶段进行，而第一阶段和第二阶段实际上是为第三阶段做准备。如果没有这前两个阶段的铺垫，直接开始第三阶段的架构重构工作，方案就需要包含第一阶段和第二阶段的一些事项（例如业务降级、接入服务中心等），这会导致架构重构方案不够聚焦，且异常复杂。

为什么最终采用这种策略呢？主要还是为了集中有限的资源，在某个阶段集中解决某一类问题。这样做首先是效率高，因为阶段目标明确，做决策和制定方案时不需要做太多选择；其次是每个阶段都能看到明显的成果，给团队带来极大的信心。比如说，第一阶段的“救火”完成后，系统很少因为机器过载、缓存响应慢、虚拟机崩溃等问题而发生故障；完成第二阶段后，由于组件或外部系统故障导致系统故障的问题也减少了。前两个阶段完成后，我们就可以安心地进行第三阶段的“服务化”工作了。

S系统的重构方法也是类似，但S系统当时面临的主要问题是可用性不高，并没有系统耦合的问题。因此，我们当时的策略是“先救火、后优化、再重构”。“救火”阶段进行了扩容（防止资源不足导致系统崩溃）和Nginx一键切换功能（在故障时快速切换）；优化阶段解决了一些明显的可用性问题（包括性能问题等）；重构阶段将原来的单点数据库改为多中心。

总结一下重构的方法，其实就是“分段实施”，根据优先级、重要性和实施难度等将要解决的问题划分为不同的阶段，每个阶段聚焦一个整体目标，集中精力和资源解决一类问题。这样做有几个好处：

1. 每个阶段都有明确目标，完成后效果明显，团队信心足，后续推进更加顺利。

2. 每个阶段的工作量不会太大，可以与业务并行进行。

3. 每个阶段的改动不会太大，降低了总体风险。

   
   

具体如何制定“分段实施”的策略呢？分享一下我的经验。

1.优先级排序

将明显且紧急的事项优先解决，处理当前遇到的主要问题。例如，扩容在S系统和X系统中都是最优先实施的，因为如果不扩容，系统会频繁出现响应超时报警、过载报警和大面积不可用等问题。这些问题耗费大量的人力和精力，导致无法专注于其他任务。

2.问题分类

根据问题的性质进行分类，每个阶段集中解决一类问题。例如，X系统的第二阶段，我们将多个底层系统切换到公司的统一公共组件，以提升整体可用性。

3.先易后难

这一点可能与很多人的直觉相反，有些人认为应该先攻克最难的问题，所谓“擒贼先擒王”，解决了最难的问题，其他问题就不在话下。虽然这个思路看起来很好，但实际上不可行。

首先，一开始就解决最难的部分，会发现要解决这个最难的问题，必须先解决其他相对容易的问题。

其次，最难的问题通常解决起来耗时长，占用资源多，如果一开始就做最难的，可能一两个月过去了还没有什么进展和成果，这会影响相关人员对项目的评价和看法，也可能影响团队士气。

第三，刚开始的分析不一定全面，因此一开始对最难或最关键事项的判断可能会出错。

采取“先易后难”的策略，可以在很大程度上避免“先难后易”策略的问题。

首先，随着项目推进，逐步解决一些相对简单的问题，会发现原来认为很难的问题已经不那么难了，甚至有些问题可能已经消失。

其次，先易后难能够比较快地看到成果，虽然这些成果可能不大，但至少能看到一些成效，有助于后续的项目推进和提升团队士气。

第三，随着项目的进行，原来遗漏的点或分析和判断错误的点会逐渐显现，及时根据实际情况进行调整，能够有效保证整个重构的效果。

4. 循序渐进

按照前3个步骤划分架构重构的实施阶段后，需要评估每个阶段所需的时间。尽管某些阶段可能只需1个月，而有些阶段可能需要6个月，这确实是客观事实，但通常情况下，按照固定步骤和节奏推进项目更为有利。我的经验是，每个阶段最短不少于1个月，最长不要超过3个月。如果评估超过3个月，就需要再拆分为更多阶段。例如，在X项目中，我们先划分了阶段，每个阶段再细分为任务子集。当任务子集较小时，多个任务子集可以并行进行；当任务子集较大时，则作为一个独立的里程碑来推进。