本文是之前文章重构总结的后续文章，本文介绍代码重构完成后，重构服务平滑替换旧服务的流程。
代码开发完毕，此时线网上旧的代码依然在正常运行，此时我们不能一下子将新服务替换旧的服务。我们通常要经过以下几个流程：
改造旧服务，使其兼容新服务模型
在重构后的服务中，我们可能会对已有的数据库、交互接口、中间件等进行变更。为了保证后续新老服务的平滑升级，在确认新服务的模型后，还需要对旧服务进行开发，让其兼容新服务的模型，可能包括但不限于数据库迁移、中间件升级新增、接口变化等等。经过测试后，发布线网环境。
新服务测试环境测试
在测试环境里，对所有测试用例进行测试，完成所有基本功能和压力测试。 这里需要同时对新老服务进行单元测试，保证相同的功能接口的输出一致。
新服务使用线网的数据进行测试
在线网独立部署测试环境，测试使用的数据必须是从真实环境复制下来，部署独立的数据库，缓存等服务，避免影响生产环境。
再做一次对所有测试用例进行测试，完成所有基本功能和压力测试
这里开始做集成测试，完全模拟用户的操作行为，对服务进行测试。此时测试人员主要是内部人员
通过tcpcopy引流生产环境请求到测试环境
以上的主要测试的对象是测试人员，可能无法覆盖所有的场景。此时如果有我们真实的客户使用我们的新系统，如果发现问题马上反馈给我们进行修正，那最好。但是这个是理想情况，实际很难做到，而且如果系统有太多BUG，对用户的体验也不好。不过我们使用tcpcopy部分实现以上的场景。tcpcopy的用法可以参考这篇文章：tcpcopy的简单用法：xnow.me/ops/simple-…)
此时，我们可以通过tcpcopy将生产环境里用户的所有请求复制一份转发到我们测试环境，让用户相同的行为同时操作生产环境的服务和我们在测试环境里的服务，然后我们需要监控新服务的日志、中间的数据、最后生成的结果是不是符合预期。如果有问题，则进行修改。这样保证最大可能保证重构后的服务符合预期。
如果系统的流量不大，则可以全部复制到测试环境。如果流量过大，则可以考虑只对一些典型或重要用户的请求复制到测试环境
发布到预发布环境测试
经过以上的步骤后，我们新服务已经比较健壮了，可以让我真正的客户使用了。我们将新服务发布到预发布环境。所谓的预发布指服务使用的数据库、缓存、服务器等资源和生产环境相同，即新服务已经在生产环境中，但是只有我们配置的部分用户的请求才会被发送到这个服务上。 部署完毕后，
- 第一步还是我们的内部客户（如测试人员）进行测试;
- 第二步，通过后，我们可以选择一些关系比较好的客户，事先说明原因，请他们发现问题后，及时反馈;
- 第三步，第二步运行一段时间后，如果没有问题，可以逐步将其它用户引流到新服务器，同时增加新服务的机器。
在这个过程同时修正新发布的bug。
新的服务完全替换旧服务
此时，将旧服务下线，新的服务完全替换旧服务
这里将我们重构后的新服务上线过程和大家分享一下，以上就是重构服务上线的主要流程，实际操作通常比这个更复杂，问题更多。所有在上线之前，需要我们做预案，尽可能对所有的情况都有对应的处理方案，尤其是失败后，如何快速回滚到正常情况。
