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