「优知学院」淘宝架构的前世今生(下)

「优知学院」淘宝架构的前世今生(下)

淘宝技术架构前世今生就是一部架构活教材,今天仍然由陈睿mikechen为大家解读淘宝架构。

我稍微把前面淘宝架构的三个阶段简短总结:

淘宝1.0 采用LAMP mysql读写操作

「优知学院」淘宝架构的前世今生(下)

淘宝2.0 把mysql替换为oracle,为了使用oracle的连接池,php采用代理连接 sqlreplay

「优知学院」淘宝架构的前世今生(下)

淘宝3.0 把php替换为java,业务代码重写,采用多层结构,全部替换为java体系,加入缓存、搜索、分布式存储。

「优知学院」淘宝架构的前世今生(下)

唯一的主线已经非常清晰了,就是来源于数据库端的压力,这就是典型的早期头重脚轻架构,一步步开始往一头一脚均衡发展的架构方案。

到了3.0架构,在淘宝越来越大的数据访问下,新的瓶颈再次出现:

  • 难以支撑高速业务发展

  • 难以支撑系统可伸缩性

  • 数据库连接达到上限 (每个Oracle数据库大约提供5000个链接)

其实在任何时候,开发语言本身都不是系统的瓶颈,业务带来的压力更多的是压到了数据和存储上。

这里我多言一句关于数据和存储,2.0架构阶段,提到MySQL 撑不住了之后换 Oracle,Oracle 的存储一开始在本机上,后来在 NAS 上,NAS 撑不住了用 EMC 的 SAN 存储,再然后 Oracle 的 RAC 撑不住了,数据的存储方面就不得不考虑使用小型机了,然后 Oracle 就跑在了小型机上,存储方面从 EMC 低端 cx 存储到 Sun oem hds 高端存储,再到 EMC dmx 高端存储,一级一级的往上跳。

常见的企业数据库集群如Oracle RAC通常采用Share-Everything(Share-Disk)模式。数据库服务器之间共享资源,例如磁盘、缓存等。当性能不能满足需求时,要依靠升级数据库服务器(一般采用小型机)的CPU、内存和磁盘,来达到提升单节点数据库服务性能的目的。另外,可以增加数据库服务器的节点数,依靠多节点并行和负载均衡来达到提升性能和系统整体可用性的效果。但当数据库服务器节点数量增大时,节点之间的通信将成为瓶颈,而且处理各个节点对数据的访问控制将受制于事务处理的一致性要求。从实际案例来看,4节点以上的RAC非常少见。

「优知学院」淘宝架构的前世今生(下)

IOE的集中存储(Share-Everything)方式存在性能、容量与扩展性的局限,同时成本居高不下。而互联网化带来的高并发,大数据的处理要求,x86和开源数据库技术的飞速发展, NoSQL、Hadoop等分布式系统技术的逐渐成熟,互联网化带来的高并发、大数据的处理要求,使得系统架构开始从集中式的Scale-up架构向分布式的Scale-Out架构发展。

回到淘宝架构主线开始4.0

为了彻底解决数据库端的压力,开始迈入最为关键的一步,彻底解决头重脚轻,真正走向服服务化阶段。

为了解决上文提到的Oracle数据库集中式架构的瓶颈问题(连接数限制、I/O性能),将系统进行了拆分,按照用户域、商品域、交易域、店铺域等业务领域进行拆分,建立了20多个业务中心,如商品中心、用户中心、交易中心等。所有有用户访问需求的系统,必须使用业务中心提供的远程接口来访问,不能够直接访问底层的MySQL数据库,通过HSF这种远程通信方式来调用业务中心的服务接口,业务系统之间则通过Notify消息中间件异步方式完成调用。图4是淘宝的分布式架构图。

最终演变后的架构为:

「优知学院」淘宝架构的前世今生(下)

到这一边的演变过程比较复杂和耗时,淘宝当初这个项目叫五彩石,就是把以前混在一起的denali全部拆解为以业务为单位的单独的jar包和服务层。

系统这么拆分的话,好处显而易见,拆分之后每个系统可以单独部署,业务简单,方便扩容;有大量可重用的模块以便于开发新的业务;能够做到专人专事,让技术人员更加专注于某一个领域。这样要解决的问题也很明显,分拆之后,系统之间还是必须要打交道的,越往底层的系统,调用它的客户方越多,这就要求底层的系统必须具有超大规模的容量和非常高的可用性,这个时候就HSF诞生了。

除了同步调用外,还有大量的异步调用的场景,这个时候Notify异步消息通知件就诞生了。

另外还有一个需要解决的问题是用户在A系统登录了,到B系统的时候,用户的登录信息怎么保存?这又涉及到一个 Session 框架TBSession又诞生了解决单点登录。

为淘宝大量图片的存储问题,TFS也诞生了,以及缓存Tari等。

「优知学院」淘宝架构的前世今生(下)

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

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

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

从2010年开始,淘宝网重点着眼于统一架构体系,从整体系统层面考虑开发效率、运维标准化、高性能、高可扩展性、高可用、低成本方面的要求,底层的基础架构统一采用了阿里云计算平台,使用了SLB、ECS、RDS、OSS、ONS、CDN等阿里云计算服务,并通过阿里云服务提供的高可用特性,实现双机房容灾和异地机房单元化部署,为淘宝业务提供稳定、高效和易于维护的基础架构支撑。

即将开始轰轰烈烈的去IOE阶段淘宝5.0,未完待续。


作者:陈睿mikechen是互联网产品技术总监,拥有10以上的互联网产品&技术经验,曾先后历任淘宝架构师,百度研发经理,携程定制旅游CTO,擅长java,高并发架构,敏捷开发,团队管理,产品策划,产品运营数据以及行业分析。

优知学院(youzhixueyuan.com)是IT人的升职加薪进阶站,BAT产品技术总监经验分享平台,我们免费提供系统的互联网产品技术进阶最牛干货。


money.jpg

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/480699.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

学习排序 Learning to Rank:从 pointwise 和 pairwise 到 listwise,经典模型与优缺点

Ranking 是信息检索领域的基本问题,也是搜索引擎背后的重要组成模块。本文将对结合机器学习的 ranking 技术——learning2rank——做个系统整理,包括 pointwise、pairwise、listwise 三大类型,它们的经典模型,解决了什么问题&…

论文浅尝 | 从 6 篇顶会论文看「知识图谱」领域最新研究进展 | 解读 代码

本文内容源自往期「论文浅尝」,由 PaperWeekly 精选并重新排版整理,感谢 PaperWeekly。ISWC 2018■ 链接 | http://www.paperweekly.site/papers/1912■ 源码 | https://github.com/quyingqi/kbqa-ar-smcnn■ 解读 | 吴桐桐,东南大学博士生&a…

互联网(IT)大厂面试技巧(面经)

目录 前言 面试的正确姿势 实战 最后的总结 前言 虽然资历尚浅,但是也面过不少试,有Google、微软等外企大佬,也有BAT等国内巨头,工作的这几年也有幸当过几次面试官,小鹿这里呢就结合自己的亲身经历,聊…

「优知学院」淘宝技术架构的前世今生(上)

“ 淘宝技术架构经历从最初的LAMP架构,到IOE架构,再到分布式架构,再到去IOE,最后到现在的云计算平台架构这一变化过程在不断解决上面的技术问题,可以说淘宝技术架构的演变就是活生生的一本架构教科书。 这次为大家带…

十大双跨平台整体发展情况盘点

在2019年国家级双跨平台发布一年之际和新一轮遴选开场之前,相关媒体“从战略演进、平台发展、资源汇聚及行业应用四个维度九个细分指标”,对十大双跨平台整体发展情况通过“一张图”的形式做了一次盘点(图略)。 我们通过对图中指…

机器学习中的范数规则化之(一)L0、L1与L2范数

机器学习中的范数规则化之(一)L0、L1与L2范数 zouxy09qq.com http://blog.csdn.net/zouxy09今天我们聊聊机器学习中出现的非常频繁的问题:过拟合与规则化。我们先简单的来理解下常用的L0、L1、L2和核范数规则化。最后聊下规则化项参数的选择问…

模型训练慢和显存不够怎么办?GPU加速混合精度训练

目录 混合精度训练 理论原理 三大深度学习框架的打开方式 Pytorch Tensorflow PaddlePaddle 混合精度训练 一切还要从2018年ICLR的一篇论文说起。。。 《MIXED PRECISION TRAINING》 这篇论文是百度&Nvidia研究院一起发表的,结合N卡底层计算优化&#x…

陈睿:架构设计之数据库拆分六大原则

架构设计之数据库拆分原则 数据拆分前其实是要首先做准备工作的,然后才是开始数据拆分,我先讲拆分前需要做的事情: 第一步:采用分布式缓存redis、memcached等降低对数据库的读操作。 第二步:如果缓存使用过后&#xf…

模式识别之特征提取算法

说明:此处暂时简单介绍下各种特征提取算法,后续完善。 前言:模式识别中进行匹配识别或者分类器分类识别时,判断的依据就是图像特征。用提取的特征表示整幅图像内容,根据特征匹配或者分类图像目标。常见的特征提取算法…

ACL2020 | 对话数据集Mutual:论对话逻辑,BERT还差的很远

一只小狐狸带你解锁 炼丹术&NLP 秘籍本文为MuTual论文作者的特别约稿编辑:rumor酱、夕小瑶前言自然语言处理是人工智能领域的掌上明珠,而人机对话则是自然语言处理领域的最终极一环。以BERT为代表的预训练模型为自然语言处理领域带来了新的春天&…

大型网站系统的特点和架构设计

分布式架构 阿里P8架构师谈:淘宝技术架构从1.0到4.0的架构变迁 优知学院」淘宝技术架构的前世今生(上) 优知学院」淘宝架构的前世今生(下) 揭秘:一位亲历者眼中的淘宝技术架构发展之路 淘宝发展历程最具…

IDC 和浪潮联合发布了《2020-2021 中国人工智能计算力发展评估报告 》

近日,IDC 和浪潮联合发布了《2020-2021 中国人工智能计算力发展评估报告 》(以下简称《报告》)。《报告》指出,中国 AI 基础设施市场规模在 2020 年达到了 39.3 亿美元,到 2024 年预计达到 172. 2 亿美元。 《报告中》…

Linux系统中Oracle数据库使用SELECT语句检索数据(1)实例应用

Linux系统中Oracle数据库使用SELECT语句检索数据(1)实例应用 1,首先切换到Oracle用户,并进入数据库#sql / as sysdba2,启动数据库,并连接样例及表格,启动命令#startup,连接样例#conn scott/tiger3&#xff…

知乎搜索框背后的Query理解和语义召回技术

一只小狐狸带你解锁 炼丹术&NLP 秘籍前言随着用户规模和产品的发展, 知乎搜索面临着越来越大的 query 长尾化挑战,query 理解是提升搜索召回质量的关键。本次分享将介绍知乎搜索在 query term weighting,同义词扩展,query 改写…

阿里P8架构师谈:分布式架构设计12精讲

分布式架构设计包含: 分布式缓存 分布式消息中间件 分库分表、读写分离 单点登录等 想成为阿里160万年薪的P8架构师?你必须掌握如下6大技能体系! 阿里P8架构师谈:分布式架构系统拆分原则、需求、微服务拆分步骤 阿里P8架构师谈…

【干货】推荐系统中的机器学习算法与评估实战

【导读】推荐系统是机器学习技术在企业中最成功和最广泛的应用之一。本文作者结合MLMU演讲【1】的Slides,对推荐系统的算法、评估和冷启动解决方案做了详细的介绍。 作者 | Pavel Kordk 编译 | 专知 翻译 | XiaowenMachine Learning for Recommender systems — P…

Google | 突破瓶颈,打造更强大的Transformer

一只小狐狸带你解锁炼丹术&NLP秘籍作者:苏剑林 (来自追一科技,人称“苏神”)前言《Attention is All You Need》一文发布后,基于Multi-Head Attention的Transformer模型开始流行起来,而去年发布的BERT模型更是将Transformer模…

阿里P8架构师谈:高并发网站的监控系统选型、比较、核心监控指标

在高并发分布式环境下,对于访问量大的业务、接口等,需要及时的监控网站的健康程度,防止网站出现访问缓慢,甚至在特殊情况出现应用服务器雪崩等场景,在高并发场景下网站无法正常访问的情况,这些就会涉及到分…

斯坦福CS224n追剧计划【大结局】:NLP和深度学习的未来

一只小狐狸带你解锁炼丹术&NLP秘籍简介Stanford CS224n追剧计划是由夕小瑶的卖萌屋发起的开源开放NLP入门项目,借助github和微信群为大家提供同期小伙伴打卡讨论、内容沉淀、作业笔记和FAQ共享、连线斯坦福等服务。关于该计划的详请见这里 。1. Github项目地址h…

KubeVela 高可扩展的云原生应用平台与核心引擎

https://www.oschina.net/news/121015/kubevela-open-source 目录什么是 KubeVela ?KubeVela 解决了什么问题?1. 应用开发者眼中的 KubeVela一个 Appfile 示例2. 平台工程师眼中的 KubeVela3. KubeVela vs 经典 PaaS快速入门安装KubeVela1. 安装Kubernet…