项目中的思考

一次活动引发的血案

从2.0上线，一夜之间涌入20w+用户，对于我们这种经常看不到并发的应用，压力随之而来，在紧急情况下，使用了最为暴力的扩容方案，堆机器，当机器堆到近20台时，用户反馈卡顿降低了。但是随之而来的另一个问题又出现了，因为某一个模块对数据操作的频繁程度太高，大约每一个用户每秒插入5条记录（本身这一模块的设计并不合理），不一会，数据库CPU又增加到了99%。同样是紧急情况下，在一个紧急会议的召开下，决定先把该模块停掉，就这样，在苦逼的人肉运维和连续三天的活动得以进行了下去。

反思以及下一步计划

经过这次活动，我们一致认为要对整个项目进行一次彻底的重构，原因有以下：

1. 单纯的增加机器扩容，无法应对未来的流量高峰，而且成本相对较高。
2. 单数据库在流量高峰并不是十分可靠，一旦数据库挂了，相当于整个系统挂了。
3. 还清之前的技术债，应用从1.0~2.0迭代的过程中，由于规范制定的不严谨，以及对设计模式理解的不深入,导致原来系统的业务耦合性很差，迭代新的业务基本上是牵一发动全身。

思考分布式系统能解决哪些问题

1. 基于领域驱动对服务进行拆分，每个服务各司其职，即使其中一个服务挂了，其他服务也能支撑整个系统运行，况且对每个服务进行配置集群，还可以达到高可用。
2. 流量高峰到来时，能有效的进行分流，并且能针对并发量大的服务进行进一步的扩容。
3. 数据库进行拆库，既不会因为某一项业务拖垮整个数据库，相当于对数据库流量进行了分流，不会说因为某一项业务而拖垮整个数据库，造成更大损失。

分布式系统又有哪些缺点呢？

1. 服务拆分成多个，原来要部署一个，现在部署多个，运维成本增加
2. 服务之间相互调用，通信势必会有网络通信的开销。
3. 数据库被拆分为多个，事务无法保证。

解决办法

1. 服务被拆分成多个，如果减少运维成本，首先需要有一套CI/CD方案，现阶段只是jenkins持续集成、持续发布，微服务如果搭配docker+k8s应该更合适。
2. 现阶段的RPC框架，对dubbo有过深入研究，底层是netty，是IO多路复用模型，后续再展开探讨一下。总之能满足现在服务之间的调用问题。
3. 对于事务问题，就是现在的分布式事务解决方案了，由于业务的原因，我们采用了基于BASE理论的最终一致性解决方案。当然还有很多强一致性的，后续再展开讨论