重构中的外部准备工作

技改在任何时候都是个敏感的事情。大量的问题需要摆平，天时地利人和，缺一不可。

天时

即选择合适时机进行技术改造工作。在时机的选择上，我们经历了三个阶段。

空闲时段
在开发企业应用时，技术改进也是常见的工作。企业应用开发的特点是有忙有闲。在版本发布前都紧锣密鼓进行开发工作；在老版本发布之后，新版本刚刚启动开发时，有相对空闲时间，可以进行技术改进。 而当这一套方法搬到互联网应用开发上时，却发现基本行不通。互联网应用开发是两种情况：很忙和非常忙。预留大片的时间进行技术改进，几乎是不现实的。如果有业务可以有空闲时间做技改，那基本上也就没必要改了，因为这也意味着这个业务进入稳定和衰退期。

随需改进
既然找不到空闲时段，另一个选择是随需进行，也就是在项目开发过程中，对涉及到的模块进行改进。而在实践中，我们也发现这种做法难度很大。

1. 遗留系统的模块依赖关系往往令人匪夷所思，改进过程中，经常会发现需要对所依赖的底层模块进行大调整，导致改进工作无法进行。

2. 就算是所依赖的模块没有问题，改进工作也会导致更多的时间开销，2~3倍都是正常的。这个延迟不是所有项目都能够承受的。

优化团队
比较适合互联网应用开发的做法，是组建专门团对进行技术改进。预留大约30%的开发能力来进行技改。这些人可以是专门负责架构改进的，也可以从项目组中抽调轮岗。

1. 改进前，制定改进计划，循序将近进行。涉及到具体模块改进时，抽调负责该模块的技术人员来参与。

2. 如果模块改进和业务开发工作同时开展，则可以考虑将这两个工作合并进行。

技改不能一哄而上，也不能蜻蜓点水的做。他是一个持续的过程，循序将近，不要中断。项目紧的时候挑选风险小的任务来执行，少安排几个重构点。项目松的时候重构下核心接口，多安排些重构。但是不要中断。 一旦中断，往往结果是没有人会愿意继续。重构往往是个前人栽树 后人乘凉的事，风险又大，短期看不到效果，大家做着做着，往往就放弃了。所以持续改进是必须的，避免半途而废。

还有一个大家容易忽略的地方，对于特别看重绩效的团队，按照产出来度量工作成果，那必须果断避开绩效考评的这段敏感时期。

地利

所谓地利，从软件角度，主要是基础设施的建设。在针对现有系统进行改进，推动微服务架构前，需要评估下当前的基础设施建设是否能够满足要求。 服务所需要的基础设施包括:

虚机环境或者docker
不同服务的线上压力和运行环境需求不同，内存，CPU，磁盘需求也不一样。按照服务需要自动弹性创建所需要的环境，是微服务部署的前置条件。

版本控制软件
版本控制不仅仅是协调人和人之间的协作，同时也是保证线上运行的系统必须是最终正式的版本。一旦出现问题，开发人员可以从版本控制服务器上下载到一致的代码。现在一般用git来实现。为什么不用SVN,网上有很多对比文章，不是本文重点。

代码评审软件
每个微服务作为独立的项目来开发，统一编码规范，审核代码逻辑等，在这场景下犹为重要。和git相配合，gitlab是优先考虑的codereview软件。

集成发布 集群对微服务是必不可少的基础环境，将一个服务部署到几十，甚至上千台机器上是必要的。这种情况下，人工部署是不现实的，依赖于集成发布环境，实现获取版本，集成编译，备份老版本，发布新版本，启动服务，暂停服务和重启服务。推荐使用jenkins。

系统监控
监控自动化也是必要的基础设施。对出问题的服务报警，在高峰期对核心服务进行监控，都必须借助监控系统来处理。推荐使用zabbix。

日志分析
排查错误和对系统进行审查，日志处理是不可避免的。想跟踪某个ID用户的行为，在几百台机器上逐个查看日志也是不现实的。使用工具，如ELK，将日志收集到一个存储中，提供检索功能来查看日志，甚至对日志做统计分析，也是必须的设施。

办公环境
不用说，新老系统开发人员得在一起办公，随时交流。如果条件无法满足，那至少必须建立顺畅的沟通方式，比如QQ群，微信群等。邮件并不是一个好的选择，电话会议也是不错的。