内容简介:今天我们重点说淘宝最重要的一次架构演变,这次演变在整个淘宝发展历程中算是最具决定性的一次,没有之一!这套架构体系,如果你能用心掌握,足可以帮助你在任何一家互联网大公司站稳脚跟!
今天我们重点说淘宝最重要的一次架构演变,这次演变在整个淘宝发展历程中算是最具决定性的一次,没有之一!
这套架构体系,如果你能用心掌握,足可以帮助你在任何一家互联网大公司站稳脚跟!
淘宝技术发展历史
前一篇文章“ 一位亲历者眼中的淘宝技术架构发展之路 ”,已经写过淘宝技术架构 前两个阶段 的发展历程。
今天我们重点说淘宝最重要的一次架构演变,也就是 第三到第四阶段 。
淘宝第三阶段面临的挑战
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镜像等来支撑更大的流量,因此在真实的发展过程中还会有很多的不同,另外一个大型网站要做到的远远不仅仅上面这些,还有像安全、运维、运营、服务、存储等等。
今天就写到这了,如果你还有更多想了解的内容,还请关注优知学院。也可以访问优知学院官网,免费报名参加线下的活动了解更多内容。
以上所述就是小编给大家介绍的《淘宝发展历程最具决定性的一次技术架构演变》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
跨平台桌面应用开发:基于Electron与NW.js
【丹】Paul B. Jensen / Goddy Zhao / 2018-3 / 99
《跨平台桌面应用开发:基于Electron与NW.js》是一本同时介绍 Electron和 NW.js的图书,这两者是目前流行的支持使用 HTML、CSS 和 JavaScript 进行桌面应用开发的框架。书中包含大量的编码示例,而且每个示例都是五脏俱全的实用应用,作者对示例中的关键代码都做了非常详细的解释和说明,可让读者通过实际的编码体会使用这两款框架开发桌面应用的切实感受。除此之外,在内容上,......一起来看看 《跨平台桌面应用开发:基于Electron与NW.js》 这本书的介绍吧!