今天我们重点说淘宝最重要的一次架构演变,这次演变在整个淘宝发展历程中算是最具决定性的一次,没有之一!这套架构体系,如果你能用心掌握,足可以帮助你在任何一家互联网大公司站稳脚跟!


淘宝发展历程最具决定性的一次技术架构演变


淘宝技术发展历史


淘宝发展历程最具决定性的一次技术架构演变


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


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



淘宝第三阶段面临的挑战


淘宝发展历程最具决定性的一次技术架构演变


1
从人员的角度。

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


2从业务的角度

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


3从架构的角度

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


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


5、从公司的角度

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


6从借鉴的角度

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



怎样来解决这些问题



http://ovjdlkcgs.bkt.clouddn.com/%E6%B7%98%E5%AE%9D%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88.jpg

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


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


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镜像等来支撑更大的流量,因此在真实的发展过程中还会有很多的不同,另外一个大型网站要做到的远远不仅仅上面这些,还有像安全、运维、运营、服务、存储等等。