文章目录
在淘宝初期，应用数量与用户数都较少，可以把tomcat和数据库部署到一台服务器上。浏览器往淘宝发起请求时，首先经过DNS服务器将域名转换为对应的IP，再通过IP访问tomcat。
缺点很明显，随着用户数的增长，tomcat和数据库之间竞争资源，单机性能不足以支撑业务。下面进行架构优化：
第一阶段 本地缓存和分布式缓存
第二阶段 反向代理实现负载均衡
第一阶段的缓存抗住了大量的请求，但是随着用户的继续增长，并发的压力主要落在单机的tomcat上，响应逐渐变慢，需要反向代理实现负载均衡。
第三阶段 数据库读写分离
第二阶段的方向代理使应用服务器可支持的并发量大大增加，但并发量的增加也意味着更多的请求穿透到数据库，单机的数据库最终成为瓶颈，需要对数据库进行读写分离。
第四阶段 按业务分库
随着业务逐渐变多，不同业务的访问量差距变大，不同业务直接竞争数据库，相互影响性能，需要按业务分数据库。
第五阶段 表格横向/垂直拆分
随着用户的逐渐增长，表格的数据逐渐增多，操作速度越来越慢，需要对表格进行拆分。
第六阶段 LVS/F5 使多个Nginx负载
数据库和tomcat都能水平扩展，可支撑的并发大幅提高，随着用户的增加，单机的Nginx也会成为瓶颈，引入LVS/F5 使多个Nginx负载。
第七阶段 DNS轮询实现机房负载均衡
因为LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终也会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房的距离不同导致了访问延迟会明显不同。所以需要引入DNS轮询，实现机房的负载均衡。
第八阶段 搜索引擎+NoSQL数据库实现丰富的检索需求
随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求。需要引入搜索引擎+NoSQL数据库实现丰富的检索需求。
第九阶段 应用拆分+服用功能抽离微服务
引入更多的组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得更加困难，需要将大应用拆分成小应用。而不同应用之间存在着共用的模块，由应用单独管理会存在相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级。所以抽离微服务（还不是严格意义上的微服务）。
第十阶段 企业服务总线ESB屏蔽服务接口的访问差异
应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱。所以引入企业服务总线ESB屏蔽服务接口的访问差异。
第十一阶段 容器化技术实现运行环境隔离与动态服务管理
应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，所以引入容器化技术实现运行环境隔离与动态服务管理。
第十二阶段 云平台的复杂应用
使用容器化技术，服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理。在非大促的时候，还是需要闲置着大量的及其资源来应对大促，机器自身的成本和运维成本都极高，资源利用率低。所以将系统部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题。在大促的时间段里，在云平台中临时申请更多的资源，结合docker和k8s来快速部署服务。在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时降低了运维成本。