分布式，微服务这些架构都是随着用户群体日益增多，数据量非常庞大，慢慢演变过来的
第一个阶段
比如 淘宝的例子 第一版出来 可能只有一个服务器 所有东西都是放在这上面的
第二个阶段
一个服务器带不动了 把这个服务器分为了 应用服务器，数据库服务器，文件服务器
第三个阶段
慢慢的 数据量越来越多 数据库服务器访问速度跟不上了 这时候可以采用Redis跟Memcache 缓存服务器来缓解数据库服务器的压力
第四个阶段
数据库的瓶颈解决后 随着并发量越来越高 应用服务器开始撑不住了 这时候可以使用集群部署多个应用服务器+负载均衡来降低单台应用服务器的压力 通过负载均衡服务器来分发用户请求
负载均衡可以分为软件跟硬件 10W并发以内可以考虑Nginx 超过的可以使用LVS 在超过可以考虑使用硬件F5
第五个阶段
这时候 应用服务器的压力没了 数据库单靠缓存已经撑不住了 可以考虑使用读写分离 主表写 从表读 可以有多个从表 利用数据库热备功能实现读写分离 这时候 应用程序读和写要操作不同的数据库 为了不改变应用层的代码 使用一个数据访问模块的中间件来实现
数据库还是撑不住 可以考虑使用搜索引擎缓存 数据库分库分表
这时候 数据库服务器 引用服务器 都已经采用的集群的方式 可以一直水平扩展
但是一些偏远乡村 或者网络不好的地方 进入网站 可能获取某些静态资源 图片 需要3s时间 可以考虑CDN加速跟反向代理 把静态资源缓存到电信数据中心 这样用户拿取这些静态图片就不需要到我们的服务器上了
第六个阶段
随着业务的发展，业务量越来越大，代码变得不可维护。这时候可以考虑将应用拆分成不同的模块，都进行独立部署 这样就会形成分布式架构
比如用户模块等等 每个独立的系统都会有用户查询访问的相关操作 这时候就可以把用户模块做成一个服务 服务之间通过消息队列进行调用 降低系统耦合 这样就会演变为微服务
第七个阶段
这时候系统已经能够承载任意的并发量了 但是万一某一个环节出了问题 我知道是某个环节的问题 但是那个环节部署了200台服务器 没办法知道是某一台具体的服务器 找不到报错日志等信息记录 ，这时候就需要全局日志系统，全局监控系统来收集所有服务器的日志跟报错 好排查问题