首先不是所有的项目都需要重构，就项目本身而言重构并不是一件很好的事情，不但不会带来很明显的效益，相反可能会对当前系统产生一定的风险。然而当你发现的你的系统已经不能支持快速发展的业务需求，QPS越来越高，数据库压力越来越大，很难在现有的系统中展开新的业务时，你就不得不考虑一下重构。

重构就像医生给病人做手术，根据病人病情来决定是否动手术，如果小手术就能解决的问题，就没必要进行大的操刀，系统也一样，越是底层的，框架级的越不要轻易重构；一旦伤筋动骨带来的影响就是毁灭性的。

比如只是某个WEB页面响应时间过长，一般在应用层就可以解决，不涉及到架构或是框架层面，方法一般是先检查页面是渲染时间过长还是服务端响应过慢；如果是前者，可以考虑调整静态资源的加载顺序，减少无关的JS代码，延迟无需同步加载的JS，Img等。如果是后者，可以考虑前端是否可以异步调用后端请求，或者合并API减少调用次数，降低服务端响应时间，这里可以考虑优化API确定时间是消耗在复杂逻辑计算上，或是DB的数据查询上，还是网络间的通信上，对症下药。

优化代码逻辑，减少不必要的冗余计算，或者减少DB查询次数，增加缓存，同步转异步等都是优化方向，根据不同业务需求选择不同的优化方向。

当你发现上述小的改动做完之后，服务器压力依然很大，CPU负载还是很高，DB压力依旧很大，单表数据还是猛增，这时候你该考虑做个大手术了。可以从系统架构入手。

拆分

除了增加服务器外，垂直拆分也是不错的选择，将服务器模块化，根据业务将不同的请求分发在不同的服务器上，不但可以降低单台服务器的访问压力，还可以降低风险等级，即使某个服务器宕了，也不会对其他服务器造成致命的影响

SOA

服务化可以让业务调用更加清晰，不但可以让复杂的业务碎片化，也可以更快的定位解决线上问题

 缓存

因为DB的资源是极其宝贵的，降低DB压力必不可少，对于实时性能不高的响应，

缓存绝对是不二的选择。本地缓存，Memcache，Redis 等都是目前不错的方式。

读写分离，分库分表

当对DB的操作大部分都是read 或者write 操作时，可采用读写分离，这里需要考虑数据同步的问题，是否写操作需要实时显示。当写操作非常频繁或者随着时间的推移单表数据已经过于庞大达到千万级别时，需要考虑分库分表，提高单表的查询效率。

由于篇幅所限，这里只做了概括性的描述，不能一一展开了。提醒一点很重要：一定要在保证系统的稳定性的前提下才能重构，万不能为了重构而重构，本末倒置得不偿失。

本文由点融黑帮 @吴松 原创发布于人人都是产品经理 ，未经许可，禁止转载。