第一阶段
首先在系统层面进行拆分，将原有的大系统拆分出多个业务逻辑独立的子系统，而DB暂时不进行拆分，多套系统还继续共用一个DB，只是根据业务逻辑划分各个系统所依赖的表，不同业务逻辑系统之间不能互相访问表，这样新系统只访问自己所归属的表，通过此种方案，可以保证原有系统业务不受影响，同时新拆分的业务系统研发工作也可以顺利进行，此阶段大概花费了我们几个月的时间，最终顺利完成系统层面的拆分。
第二阶段
在完成系统层面拆分之后，我们紧接着实施DB层面的拆分，将各个子系统所依赖的表独立拆分出来，分别放置到不同的RDS数据库，实现物理的隔离，同时实现了数据库主从分离。
初步服务化
本阶段，我们采用了比较简单易用的Hessian实现初期的RPC服务化。针对第三方公共服务，从原有系统中解耦出来，独立拆分出服务化组件，并做独立部署，供其余业务系统统一调用。而系统间调用也通过Hessian来实现RPC远程调用。
SLB负载均衡
在V1.0架构期间，我们的Nginx都是单点部署，一旦一台Nginx服务器出现故障，则会波及到大量业务系统，风险非常大
在V2.0架构期间，我们引入了SLB实现负载均衡，SLB配置了多台Nginx，同时在业务系统层面也实现了负载均衡，避免了单点故障，达到高可用的目的。
爆发期—微服务架构V3.0
进入2016年以来，贝聊业务高速发展，用户规模在短时间内增长数百万，同时各个业务线逐渐铺开，业务场景更加复杂，代码规模膨胀得也非常快，研发团队迅速达到了几十人规模，一个系统多人开发，研发人员层次不一，规范难以统一，同时业务逻辑耦合严重，每次上线都需要将整个大系统整体打包上线，风险非常大，并且新人入职之后学习成本非常高。因此我们引入了微服务架构，将业务逻辑拆分为独立的微服务组件，每个微服务都围绕着具体业务进行构建，由专人研发和维护，并由专人做性能优化和架构优化，各个微服务组件的研发与上线互不影响。
结合V2.0架构，在实施微服务架构时，基于多方面考虑，我们选择了Dubbo作为分布式微服务框架。