今天我们重点说淘宝最重要的一次架构演变，这次演变在整个淘宝发展历程中算是最具决定性的一次，没有之一！

这套架构体系，如果你能用心掌握，足可以帮助你在任何一家互联网大公司站稳脚跟！

淘宝技术发展历史

前一篇文章“一位亲历者眼中的淘宝技术架构发展之路”，已经写过淘宝技术架构前两个阶段的发展历程。

今天我们重点说淘宝最重要的一次架构演变，也就是第三到第四阶段。

淘宝第三阶段面临的挑战

 

1.从人员的角度。

维护一个代名工程Denali的百万级代码怪兽(虽然物理部署是分离的)，从发布到上线，从人员的角度，百号人同时在一个工程上开发，一旦线上出问题，所有代码都需要回滚，从人员的角度，也基本忍受到了极致。

2.从业务的角度

淘宝包含太多业务：用户、商品、交易、支付...等等，代码已经严重影响到业务的效率，每个业务有各自的需求，技术需要快速跟上业务的发展步伐。

3.从架构的角度

从数据库端oracle数据库集中式架构的瓶颈问题，连接池数量限制(oracle数据库大约提供5000个连接)，数据库的CPU已经到达了极限90%。数据库端已经需要考虑垂直拆分了。

从应用横向角度，需要走向一个大型的分布式时代了。

4.从公司的角度

基本处于硬件横向扩展(服务器端按照层次物理部署)，随着淘宝的访问量越来越大，横向部署扩展很快将到头，从架构的前瞻性角度来讲，这次架构调整晚做不如早做，否则越到后面越棘手，长痛不如短痛，是时候做出决断了！

5.从借鉴的角度

以上任何一条，足可以推动整个技术架构往后延伸。这里也不得不提到一点，淘宝的整个技术架构的发展，离不开整个java体系开源的力量，以及当时技术更为先进的前辈。这些包含ebay、google等，淘宝当初从他们身上借鉴和学习到的特别多，从技术架构的角度。淘宝后面的tddl这就是直接从ebay的dal身上借鉴而来，以及tfs(从google的gfs参考而来)。类似的参考案例还有很多很多，今天我们重点还是继续谈这次架构演变。

问题了都暴露出来了，关键是怎样去解决，用怎样的思路开启？

怎样来解决如此棘手的问题

 

当你面临以上严峻问题，这个阶段需要痛下决心，是否需要把这些问题彻底解决？

如果你要彻底解决，你肯定需要付出巨大的代价。这次淘宝架构演变无疑是最具决定性的一次，也是周期最长，挑战最大的一次。系统将按照职责和业务进行垂直拆分，努力去打造一个大型的分布式应用以及廉价的服务器集群时代。

1.首先工程代码垂直拆分

把整个工程代码denali按照业务为单元进行垂直拆分，还需要按照业务为单元进行单独的物理部署。

淘宝就把denali按照业务为单位拆分成了类似这样的系统：UM(UserManger)、SM(ShopManager)..等等几十个工程代码。

2.所有接口访问垂直拆分。

按照业务为单位，把所有调用相关的接口以业务为单元进行拆分(早期可以把接口放在上面的工程里，通过服务暴露接口)，以后再考虑单独部署。

比如，一个店铺系统，需要访问一个用户的头像的接口，用户头像的接口是独立部署在用户中心(UIC)这边的集群服务器上的。随着拆分的进行，淘宝的业务接口中心就变成了：UIC(用户中心服务)、SIC(店铺中心服务)等等以业务为单元部署的集群。

如果涉及到独立部署，这里就涉及到接口底层通信机制。由于淘宝的访问量特别大，从早期就意识到需要定制一个自己定制的通信框架，也就是如今的HSF：一个高性能、稳定的通信框架，并且支持多种不同的通信和远程调用方式。走到这一步涉及的知识体系非常的多，要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。

3.淘宝的中间件开始形成自己的矩阵。

如果仔细查看，你会发现中间件基本都是在解决数据库端的瓶颈为主，比如oracle的连接池限制、以及减少对数据库的访问，需要中间的分布式动态缓存来减少数据库端的访问，以及减少对数据库的访问，把大量的小文件(图片等)存储在廉价的硬件服务器上，以及到了后面为什么淘宝要坚定的去IOE(IBM的小型机，Oracle的数据库，EMC的存储设备),其实基本都是基于数据库

端的压力。

当你走到了去IOE阶段，一定是数据库服务器端节点之间的通信已经成为瓶颈，以及各个节点对数据的访问控制将受制于事务处理的一致性等问题，还有受限于磁盘的机械转速与磁臂的寻道时间，以及受限于磁盘存储性能提升缓慢等问题。随着访问量越来越大，这些瓶颈早晚会碰到，这就是阿里厉害的地方，这是一家强控制的企业。这些必须要自己控制，所以去掉IOE就变得很合理了，没有什么轰轰烈烈的壮举了。一切都是为了赢取业务的需要。当然，这里面也有阿里云的考虑，毕竟这些服务要全面开放出来。关于IOE这个话题，以后再详细说。

大家比较了解的分布式缓存Tair、分布式文件存储TFS、异步通信Notify、淘宝数据库Tddl、淘宝Session框架等等就属于淘宝中间件团队(底层架构组)。

4.数据库端按照业务为单位进行垂直和水平拆分

按照业务为单位进行垂直拆分数据库，拆分完后就是：交易数据库、用户数据库、商品数据库、店铺数据库等。

这里还有涉及到的数据库的选型，垂直拆分的时候，把除核心系统(交易等)之外的数据库，选用免费的mysql为好，毕竟oracle太贵了，非核心系统用oralce完全没有必要。

还有就是水平扩展，分库分表，再结合读写分离一起。当然，分库分表需要涉及到对应的SQL路由规则主库备库等，所以淘宝就设计了一套TDDL来解决这些问题，应用端只需配置对应的规则即可，对应用端的没有任何侵入的设计。

5.需要整理业务和接口等依赖关系

将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理和系统依赖关系等等，比如，常用的访问接口单独提供出来服务，调用这个接口方要考虑依赖关系。

6.淘宝商品搜索引擎ISearch

毕竟海量的商品需要搜索，需要强大的搜索引擎。采用自己开发的ISearch搜索引擎来取代在Oracle数据库中进行搜索，降低数据库服务器的压力。做法比较简单，每天晚上全量将Oracle小型机的数据dump出来，Build成ISearch的索引，当时商品量也不大，一台普通配置的服务器，基本上可以将所有的索引都放进去，没做切分，直接做了一个对等集群。

7.淘宝开始建立自己的独立CDN基站等基础设施

8.需要建立自己的运维体系

用于解决依赖管理、运行状况管理、错误追踪、调优、监控和报警等一个个庞大的分布式应用的情况。淘宝的这个系统叫淘宝的哈勃望远镜。

9.机房容灾等

还要考虑如果线上出问题后，需要有备用机房工作，也就是我们常说的机房异地容灾，保证哪怕断水断电，不能断淘宝。

真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量，因此在真实的发展过程中还会有很多的不同，另外一个大型网站要做到的远远不仅仅上面这些，还有像安全、运维、运营、服务、存储等等。

今天就写到这了，如果你还有更多想了解的内容，还请关注优知学院。也可以访问优知学院官网，免费报名参加线下的活动了解更多内容。

---