首先谈一谈我们做技术架构重构的契机，重构并非难在怎么做，而是难在何时开始做，所以我们做架构重构的契机主要基于以下几点：
1.原有LNMP架构经历了两个团队研发和维护，外包团队和公司PHP研发人员，由于业务变化比较快，原有的数据库设计逐渐暴露出来很多问题，很多表设计不合理， 很多字段定义不清，比较混乱；
2.2015年，由于业务发展，贝聊app需要拆分为两个客户端：贝聊家长端和贝聊老师端，通过不同的客户端来服务不同的用户群体，达到精准运营的目的，如果在原有架构上继续进行开发，则会导致新旧接口逻辑混在一起，并且早期的很多接口定义不是很规范，维护起来越来越麻烦、越来越吃力；
3.原有API接口系统是单体架构，里面包含了各种接口，混合了各组业务逻辑处理，所有功能都集中在API接口系统中，代码非常臃肿，业务非常繁杂，迭代开发的速度也逐渐减慢，各种性能问题经常爆出，BUG也比较多，并且部署困难，任何修改每次都需整体部署。由于业务逻辑混杂在一起，新入职研发人员需要很长时间才能够完全熟悉系统，很难快速通过以点及面的方式切入系统；
4.所有数据存储在一个RDS数据库中，只使用了一个主库，没有从库，同时很多系统共用一个数据库，一方面数据库没有做到物理上的隔离，另一方面很多表都放在了同一个数据库中，经常会碰到一个慢查询或者其他性能问题，导致整个RDS各项指标飙升，造成雪崩效应，所有系统连锁出现故障，最终都不能访问；
5.公共服务耦合比较严重，很多第三方服务都散落在各个系统里面，不便于统一维护，当需要修改公共服务参数或者做其他调整时，需要深入到每个系统里进行修改或者排查，非常麻烦，还非常容易出现遗漏，最终产生BUG，急需独立拆分出公共服务，将公共服务从业务系统中解耦出来，由专人进行独立维护、独立部署；
6.我们新的研发团队都拥有丰富的JAVA分布式架构设计经验，拥有高并发、高可用经验，因此将原有的单体架构重构为JAVA分布式架构也是顺势而为。
由于公司业务高速发展，如果停下来专门做技术架构重构是不可能的，我们选择了在维护现有系统的基础上，同时进行新的技术架构重构工作。