Web应用架构演进及系统性能、稳定性所需要解决的问题

Web应用架构演进

1. 项目起步阶段

   在项目起步阶段，系统访问量不大，业务比较单一，且需求紧，需要快速上线，这个时候一般瀑布式开发，单系统、单库、单缓存集群。

   

2. 业务范围扩大，根据业务边界拆分

   在业务范围扩大过程中，单系统会逐渐变得臃肿庞杂，业务耦合越来越严重，改动小可能影响会很大，有时候可能因为一处细小的错误导致全站宕机。
   当前阶段最直接的办法就是根据业务边界进行拆分，每个业务模块由专门的开发人员进行维护，做到专而精。
   

3. 访问量级增大，系统性能考虑提上日程

   在系统的访问量级变大之后，对于系统性能方面考虑就要提上日程了，以前可能单库就搞定的事情现在需要分库分表了，以前把量全部往数据库打都不要紧的现在需要考虑哪些数据需要做预热了，以前很多的非核心逻辑在主流程同步执行的需要考虑异步去执行了。而且在访问量这么大的条件下，对于系统的稳定性要求会更高，以前挂1分钟可能都没请求进来，现在挂1分钟可能是上百万请求异常。
   该系统中由于存在需要根据多字段去检索信息，所以会有一个索引库的概念，通过在索引库去查询信息所在分库，但是这种模型对于读能力是可以水平扩展的，而写能力则是有单点瓶颈，有待优化。
   

4. 多机房容灾
   上一步完成之后，对于单机房的可用性已经有一定的保障，要做到服务的持续可用，还得继续发展做网络分区，保证一个网络分区下的整个集群全部挂掉，另外的网络分区也可继续提供服务。
   在介绍网络分区之前，先来介绍下CAP定理，在分布式系统中，不可能同时满足三点，C，consistence数据一致性，A，availability高可用性，P，partition tolerance容忍网络分区；如果有了网络分区，要么选择不同分区都可以写数据，丧失部分数据一致性能力，通过最终一致性保证不同分区下数据一致；要么选择只有一个分区在写数据，丧失写的高可用。
   先来看看国内使用较多的模式，两地三中心，同城两个机房可同时提供服务，写数据可一个机房写也可以两个机房都写再同步，异地机房做冷备，一般来说同城机房之间50公里的光纤距离，数据同步延时在1~2ms，是一个可接受的范围，而异地机房同步延时可能超过100ms；选择这种方式整体来说就会简单一些。