「优知学院」淘宝架构的前世今生（下）
Posted liuyongzhi
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了「优知学院」淘宝架构的前世今生（下）相关的知识，希望对你有一定的参考价值。
“
淘宝技术架构前世今生就是一部架构活教材，今天仍然由陈睿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产品技术总监经验分享平台，我们免费提供系统的互联网产品技术进阶最牛干货。
没钱没人脉也能轻松入门，让你每年多赚10万！
以上是关于「优知学院」淘宝架构的前世今生（下）的主要内容，如果未能解决你的问题，请参考以下文章