诞生
访问量大（高并发）
比如最初的系统使用用户只有100，系统功能太好用了，吸引了大量的新用户，现在用户10W。
响应速度慢（性能）
之前业务简单，一个 select * from xxx, 现在要加上各种where和group by ，order by,查询时间从0.1秒变成了10秒。用户说不好用了。
功能扩展（可扩展性）
之前只卖书，现在人们用到的东西我都想卖！我就是想正确！
数据量大了（高可靠）
时间能带走一切，也会带来一些东西，比如说：麻烦！
服务崩溃了（高可用）
服务器：之前我一个人养10个人，现在让我养10W人，老板还不加工资，累死机器了，干了一年了，放个年假吧。
简单总结下：用户越来越懒了！
改进
不要问我为什么改进，反正所有的优秀都是逼出来的！
背景
1.摩尔理论：价格不变时，每隔18个月，计算机的性能会提升一倍！
2.阿姆达尔定律：S(N)=1/[(1-P)+P/N]
2.MapReduce思想：把大任务分解成一堆小任务，一个人处理一个小任务，最后把各自的结果整合在一起。
中国人古语：分而治之！
高并发问题解决方案
并发编程：一个线程忙不过来就多派几个线程！
一台机器干不了那就派多台机器来同时干！
性能瓶颈问题解决方案
引入缓存，减少DB的压力
扩展问题解决方案
程序员：又加功能，这个项目都是代码了？。
老板：再起一个项目！
客户：新项目？我还要一个注册账号，好烦哦！
架构：这个问题我能解决！
项目之间使用网络通信，同步相关的信息！
高可靠问题解决方案
增加一个备份吧（所有数据的高可靠都是通过冗余保证）
高可用问题解决方案
机器太累了，那就多雇佣几个机器，实行任务划分，减轻压力，同时还符合高内聚。
新问题
高并发新问题
线程执行某个任务的时候发现要使用的资源正在被使用，有时候这个任务已经被其他线程处理过了，现在需要一个管理者，来分配调度和协调
RPC:zookeeper，dubbo等
缓存新问题
需要缓存的数据量太大了，缓存不够用。
NoSQL:Redis等
扩展新问题
项目太多了，如何管理和控制，协调？
微服务理念诞生，服务注册，治理中心诞生！
高可靠新问题
数据如何同步备份？
各种MQ
数据不一致问题如何处理？
CAP理论
高可用新问题
机器总是发生各种各样的故障，如何处理？主备已经不时用了
服务集群，各种各样的，CAP中做取舍，被舍弃的也要尽可能去“亡羊补牢”。
总结
数据备份的可靠性
负载均衡--服务集群
高可用--服务集群
拆分成微服务
NoSQL 提速
没有百分之百完美的解决方案？
只有适合业务场景的解决方案，没有绝地完美的解决方案！