淘宝进化史

在淘宝最初时，应用数量与用户数都较少，可以把Tomcat和数据库 部署在同一台服务器上。浏览器往www.taobao.com发起请求时，首先经过 DNS 服务器（域名系统）把域名转换为实际 IP 地址 xx.xx.xx.xx，浏览器转而访问该 IP 对应的 Tomcat。

 

 它的缺点很明显,随着用户数的增长,Tomcat和数据库之间竞争资源，单机性能不足以支撑业务，现在要求你对早 起淘宝进行架构优化，实现其千万级并发架构. 

 

第一阶段本地缓存和分布式缓存

 

 

第二阶段反向代理实现负载均衡 第一阶段的缓存抗住了大部分的访问请求，但是随着用户数的增长，并发压力主要落在单机的Tomcat上，响应 逐渐变慢，需要使用反向代理实现负载均衡。

 

 

第三阶段数据库读写分离 第二阶段反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机 的数据库最终成为瓶颈，需要对数据库进行读写分离。

 

 

第四阶段按业务分库 随着业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能。需要按业务分数 据库。

 

 第五阶段表格横向/垂直拆分 随着用户数的增长，表格数据越来越多，操作速度越来越慢，需要对表格进行拆分。

 

 

第六阶段LVS/F5使多个Nginx负载 数据库和Tomcat都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终单机的Nginx会成为瓶 颈。需要引入LVS/F5使多个Nginx负载

 

 

第七阶段DNS轮询实现机房负载均衡 由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿 级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同。所以需要引入DNS轮训，实现机 房的负载均衡

 

 第八阶段搜索引擎+NoSQL数据库实现丰富的检索需求 随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求，需 要引入搜索引擎+NoSQL数据库实现丰富的检索需求。

 

 

第九阶段应用拆分+复用功能抽离微服务 引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务 的升级迭代变得困难，需要将大应用进行拆分，拆分为小应用。而不同应用之间存在共用的模块，由应用单独管理会导致相 同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级。所以抽离微服务。

 

 第十阶段企业服务总线ESB屏蔽服务接口的访问差异 应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱。所以引入企业服务总线 ESB屏蔽服务接口的访问差异。

 

 

第十一阶段容器化技术实现运行环境隔离与动态服务管理
x
应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类 需要动态扩缩容的场景，需要水平扩展服务的性能。所以引入容器化技术实现运行环境隔离与动态服务管理

 

 第十二阶段云平台的复杂应用 使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，在非大促的时候，还是需要 闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低。所以将系统部署到公有云上，利用公 有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合Docker和 K8S来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本