V1阶段：
这时候主要是原型阶段，最主要的是快速实现产品，能快速的对外服务，验证商业模式的可行性。所以技术上可能选择一些阿里云等共有云，各种功能模块（CRM，搜索等）集合在一个应用里，读写都在一个数据库。
缺点：这时候肯定存在系统不好维护，并发量等低，可用性查，不好满足（例如有效的搜索等）业务需求。
优点：开发快，应用简单，需要开发人员少。
V2阶段:
业务量增加带来的业务需求更高，需要移出搜索、CRM等系统，搜索系统引入ES、solr等中间件实现更有效的搜索。
出现问题：拆出搜索后各个系统之间的数据存在同步问题。
解决方案：引入中间件，实现数据同步（canal* ,mq，定时任务，给接口每次调用）c
V3阶段：
交易量增加。
问题：1、订单管理 2、钱的管理(数据库单点，容易数据丢失) 3、分拆系统）
解决：开始数据库备份（横向扩展）
V4阶段：
团队增加，应用还是单应用。
问题：单应用，系统耦合性高，团队开发中和代码困难，容易出现问题。
解决：拆分应用，各个应用需要关联（各个应用都是接口关联，所以引入mq（隔离各个系统）mq是单机，待解决）），nigix实现负载均衡。mq带来的问题：消息异步，失败了数据不一致。
V5阶段：
数据量变大。
问题：数据量和访问量变大，IO增加，系统变得很慢。
解决：数据分为热点数据和冷数据（销量前百分之多少的top热数据用redis）； 电商也开始拆应用（详情页，商品）分拆原则：1、领域模型 2、重要程度 3、访问频率；Dubbo+zk 管理所用服务（各个应用的解耦）
V6阶段：
继续解决系统的耦合和关联问题。
问题：大量数据怎么处理
解决：数据库分片，分表（横向扩展），分库分后引用数据库中间件Hadoop等聚合，出现groupby，sum（）数据聚合不了等问题。 hadoop（map|reduce）只能做离线，补偿数据库聚合功能 ： 实时数据采用spat stom中间件（只解决流数据）
V7.。。8.。9.。
另一个机房备份dubbo，机房同步问题？应用部署问题等。。 Gfs lucence nutch docker kws
待续。。
总结：
1、开发一个高并发的系统并不是一下子就完成的，需要考虑到业公司务实际场景、开发人员数量和能力、资金公司发展等等问题。
2、从单应用拆分到多应用，再到解决各个应用之间的实时关联问题(dubbo,mq等)，再到dubbbo集群、mq集群；从单点数据库到多点数据，再到数据库分库分表、引入redis,Hadoop等，再到hadoop集群等；实际上不断拆分又聚合等过程。
3、随着各种中间件的引用，其实一些中间件只用到了它的一部分功能，我感觉一个系统越往后发展用到的中间件解决的问题越专一，需要深入理解业务需求和中间件原理才能合理的使用中间件。
4、很多创业的公司起步可以说开始条件不容易好（例如dd），不可能一开始就想到各种高并发问题，说不定明天就死了,最开始一定是满足业务，能跑起来，所以不同的阶段一定要满足最重要的需求，可以牺牲一部分高大上的东西。
5、没有完美的架构、哪家在解决各种高并发问题时，做的最好，用的钱越少、无限贴合自己的业务场景就是最好的架构。
6、从零构建一个高并发系统算法上用到了：分治 分片 横向扩展。套用三国演义上的一句话：“天下大势，分久必合，合久必分”。（突然觉得我写的好装逼啊，哈哈哈哈，现阶段只能写出这些了，待续，错误很多，发现请指点！）