淘宝技术架构演进之路--精华版

Posted 2021-05-16 我思知我在

基本概念

IOE

ioe指以ibm小型机、oracle数据库和emc存储设备为代表的it基础体系，这三个海外巨头从软硬件上垄断了商业数据库领域，中国企业尤其是大型企业如金融等命脉企业，大都采用ioe架构的数据库，高度依赖海外三巨头的设备，一方面极大地增加了it成本； 另一方则带来巨大的数据安全隐患。

LAMP架构

LAMP是指一组通常一起使用来运行动态网站或者服务器的自由软件名称首字母缩写：

• Linux，操作系统
• Apache，网页服务器
• MariaDB或mysql，数据库管理系统（或者数据库服务器）
• php、Perl或Python，脚本语言

淘宝演进之路

1. LAMP架构

随着访问量和数据量的飞速上涨，问题很快就出来了，首先遇到的瓶颈是数据库，MySQL当时是第4版的，我们用的是默认的存储引擎MyISAM，问题如下：

1. MyISAM存储引擎在写数据的时候会把表锁住。当Master同步数据到Slave的时候，会引起Slave写，这样在Slave的读操作都要等待。
2. MyISAM存储引擎会发生Slave上的主键冲突，经常会导致同步停止，这样，你发布的一些东西明明已经成功了，但就是查询不到。

2. 数据库从MySQL升级到Oracle

将SQL换为Oracle的原因除了它容量大、稳定、安全、性能高之外，还有人才方面的原因，当时Oracle给全球的技术专家颁发一些头衔，当时全球只有十几名，而阿里巴巴就有4名。

3. 脱胎换骨的升级–更换开发语言

这个阶段做了如下三件事：

1. PHP更换为Java语言，更换语言来进行脱胎换骨的升级
2. 自研的“淘宝MVC”
3. ISearch搜索引擎：对于商品搜索功能，采用自己开发的ISearch搜索引擎来取代在Oracle数据库中进行搜索，降低数据库服务器的压力，做法比较简单，每天晚上全量将Oracle小型机的数据dump出来，Build成ISearch的索引
   
   这时已经到了2004年底，淘宝网已经有4百多万种商品了，日均4千多万个PV，注册会员达400万个，全网成交额达10亿元。
   这时用了IBM的小型机、Oracle的数据库、EMC的存储，这些东西都是很贵的，基本可以说是花钱如流水。
   但在后来，淘宝网发展越来越快，用钱无法解决技术问题了，怎么办？

4. 去IOE化——围绕性能、容量和成本的进化

自研CDN，对数据分库、放弃EJB、引入Spring、加入缓存、加入CDN等工作

其实都是围绕着提高容量、提高性能、节约成本来做的。

5. 淘宝TFS文件系统

存储的成本高到什么程度呢？数据库方面用了IOE，一套下来就是千万级别的，那几套下来就是——好多钱啊，所以有了淘宝TFS文件系统，架构如下

6. 淘宝KV缓存系统–Tair

2007年，淘宝每天有100多万交易被创建，一些系统的流量非常大，如商品详情等，因此遇到了如下问题：

• 如果直接访问数据库，会导致数据库压力非常大；
• 如用户信息，访问一个页面，都需要查询买家信息、卖家信息、显示出买家的信用、卖家的服务星级等。

推出了淘宝自创的Key-Value缓存系统——Tair （TaoBao Pair的意思，Pair即Key-Value数据对）。Tair包括缓存和持久化两种存储功,在创造了TFS和Tair之后，整个系统的架构如下图所示

7. 服务化

即把交易这个核心业务模块拆分出来，单独作为一个服务提供，也就是分布式来提高整体性能

拆分之后面临的问题：

• 拆分之后的系统如何通信？
• 用户在A系统登录后，到B系统的时候，用户的登录信息怎么保存？

8. 中间件

消息中间件Notify

分布式数据访问层TDDL（Taobao Distributed Datalayer）：

下图展示了TDDL所处的位置：

下图展示了一个简单的分库分表数据查询策略：

Session框架 Tbsession

Tbsession框架致力于解决以下几个问题：

• Session的客户端存储，将Session信息存储到客户端浏览器Cookie中。
• 实现服务端存储，减少Cookie使用，增强用户信息的安全性，避免浏览器对Cookie数量和大小的限制。
• Session配置统一管理起来，集中管理服务端Session和客户端Cookie的使用情况，对Cookie的使用做有效的监管。
• 支持动态更新，Session的配置动态更新
  

9. 统一架构体系

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

在从IOE架构最终向云计算平台技术架构转移的过程中，主要面临以下几个技术挑战。

• 可用性：脱离小型机和高端存储的高冗余机制，采用基于PC服务器的分布式架构的云计算平台能否做到高可用。
• 一致性：Oracle基于RAC和共享存储实现的物理级别一致性，基于RDS for MySQL能否达到同样的效果。
• 高性能：高端存储的I/O能力很强，基于PC服务器的RDS能否提供同样甚至更高的I/O处理能力，MySQL和Oracle对SQL的处理性能是否相同。
• 扩展性：业务逻辑如何拆分，如何服务化，数据分多少库分多少表，什么维度分，后期二次拆分如何更方便等。

基于阿里云计算平台，通过采用合适的技术策略和最佳实践，包括：应用无状态，有效使用缓存（浏览器缓存、反向代理缓存、页面缓存、局部页面缓存、对象缓存和读写分离），服务原子化，数据库分割，异步解决性能问题，最小化事物单元，适当放弃一致性。以及自动化监控/运维手段包括监控预警、配置统一管理，基础服务器监控，URL监控，网络监控，模块间调用监控，智能分析监控，综合故障管理平台，容量管理。可以很好地解决以上问题，从而达到整体系统的高可扩展性、更低的成、更高的性能和可用性的实现效果

通用架构设计的原则（重点）

• N+1设计：系统中的每个组件都应做到没有单点故障；
• 回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
• 禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
• 监控设计：在设计阶段就要考虑监控的手段；
• 多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
• 采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
• 资源隔离设计：应避免单一业务占用全部资源；
• 架构应能水平扩展：系统只有做到能水平扩展，才能有效避免瓶颈问题；
• 非核心则购买：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
• 使用商用硬件：商用硬件能有效降低硬件故障的机率；
• 快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
• 无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。

总结

整体看下来，淘宝架构演进基本过程可以描述为：

1. LAMP架构，03年主流架构
2. 换数据库为Oracle，提升数据库性能
3. 更换开发语言Java，主要原因Java被世界上主流的大规模网站普遍采用，此时还是采用IOE
4. 去IOE化，降底成本，主要围绕性能、容量和成本的进化
5. 自研的文件系统TFS，降低存储成本
6. 自研KV缓存Tair，Tair支撑了淘宝几乎所有系统的缓存信息，目前已开源
7. 服务化，将每个业务独立拆分为一个模块来进行提供服务
8. 中间件 Notify、TDDL、Tbsession，主要是为了解决服务化后带来的分布式问题
9. 云计算平台技术架构，达到整体系统的高可扩展性、更低的成本、更高的性能和可用性

所以说还是要自己掌握核心技术，才能够超越别人！！！