最开始的架构

技术组成

LAMP（Linux + Apache + MySQL + PHP）架构

原因

原因：要快速开发出来，技术开源、免费

技术改进

对数据库进行了修改，从一个数据库的读写操作，拆分为一个主库，两个从库，读写分离。

读写分离

发送 sql 请求，主库不执行读操作，从库执行读操作。读写分离使得读写效率得以提升（写比读更加消耗资源，分开后互不干扰）

主库写，从库读，需要解决主从直接的数据同步。主从的同步一般由数据库来实现。

网站升级

升级内容

• 数据库从 MySQL -> Oracle
• 支付手段创新 -> 支付宝
• 交流方式创新 -> 淘宝旺旺（抓住了当时用户的需求）

数据库替换原因

MySQL 撑不住当时的业务量了，Oracle 容量大、稳定、安全、性能高，而且阿里巴巴有很强的 DBA 团队。

采用连接池技术，避免申请连接，关闭连接的开销（Oracle 的连接是长连接，进程级别的很消耗资源）。

支付创新的原因

买卖双方存在不诚信的交易，货到了不给钱。逐步想到了“担保交易”这种散发托管资金的方式。便开发出来一个安全交易功能，供卖家选择。

坑：银行虽支持在线支付，但是网关五花八门，杂乱。所以公司人员跑断腿，各种申请在线支付接口，统一化支付方式。

淘宝旺旺

对比 eBay，淘宝允许买卖双方交流。【符合当时人们的兴趣？？】

企业级Java网站

Java 的特点

Java 是当时最成熟的网站开发语言，有良好的企业开发框架，网站开发的主流语言，且具备 Java 开发经验的人才多，后续维护成本低。

• 成熟
• 生态圈好
• 人才多，成本低

更换语言

问题：

• 网站庞大
• 新需求在不断增加
• 更换语言的过程中不能拖慢业务发展

解决：

• 请一流的专家来开发。（Sun 的工程师）
• 给业务分模块，一个模块一个模块地渐进式替换。不再对旧模块进行功能拓展，新功能加在新模块上，与老模块共用一个数据库，开发完毕后放到不同的应用集群上。逐步替换老模块。
• 市面上的框架不够优秀，自己扩展一个

思考：

• 业务带来的压力往往集中在数据和存储方面

• 开发语言的影响并不大（仁者见仁智者见智吧，我觉得开发语言的影响也不小，但是要是愿意为语义写一个高效的解释器/编译器那语言的影响确实不大）

• 市面上有技术可解决对应问题时，用这些技术，无法支撑时，自行开发

性能、容量和成本的进化

Oracle 的处理能力有上限，要想办法减轻它的压力

• 分库分表，有些人只会用到一个库，查一个库就行。有些人会用到两个，要从两个数据库中查询数据并排序，然后再合并，麻烦。
  • 写中间件，让开发人员直接使用中间件去进行查询，统一查询方式。
• 引入搜索引擎（不明白）
  • 书里是说，把数据库的文件 dump 成结构化文本文件后放硬盘上，提供查询方式来查询数据。文件的 dump 也挺耗时吧。如果是每隔一段时间还好，但是 taobao 的数据量这么大，数以亿计的信息，怎么做到快速更新，怎么保证效率？
• 机器撑不住了，换成了小型机，一级一级换设备。
• 后来钱解决不了问题了，只能自己创造技术了。
• 缓存技术：减少数据库压力
  • 把不经常变更的只读内容放入缓存中，一开始只放卖家信息，后面把商品属性放里面了。商品详情由于字段太大显示放入缓存，再后来是放到了文件系统 TFS 中。（字段大，耗存储空间，存的信息就少了）。
  • 但是问题来了：商品详情里有个浏览量，实时更新写入存储的话能用缓存吗?（个人看法：写入缓存，缓存中的数据再定时写入数据库，尽量保证写入时间不集中在一起，避免奔溃，出现数据不一致也无伤大雅。）
• CDN（内容分发网络）
  • 将媒体资源，动静态图片，HTML，CSS，JS 等内容缓存到距离你更近的 IDC（互联网数据中心）

创新技术

为何创新?

市面上的技术无法解决自身的问题时，只能创新技术了。

淘宝文件系统 TFS

淘宝的数据量太大了。尤其是图片，2010 年保存着 286 亿个图片文件。图片的访问流量占到了 90%，且图片的平均大小为 17.45KB，小于 8K 的图片占比为 60%。

大规模小文件的存储和读取需要磁头频繁的寻道和换道（比如要查找 ABC 三张图，找到 A 了，接下来找 B 需要寻道，找到 B 了，要找 C 需要寻道。由于文件本身很小，读取时间短，这就放大了寻道时间在 IO 中占的比例了）

• 现存的问题
  • 第一，商用存储系统没有对小文件存储和读取的环境进行有针对性的优化；
  • 第二，文件数量大，网络存储设备无法支撑；
  • 第三，整个系统所连接的服务器越来越多，网络连接数已经达到网络存储设备的极限；
  • 第四，商用存储系统扩容成本高，10TB 的存储容量需要几百万元，而且存在单点故障，容灾和安全性无法得到很好的保证。
• 商用还是研发？
  • 第一，商用软件很难满足大规模系统的应用需求，无论是存储、CDN 还是负载均衡，在厂商实验室端，都很难实现如此大的数据规模测试。
  • 第二，在研发过程中，将开源和自主开发相结合，会有更好的可控性，若系统出了问题，完全可以从底层解决问题，系统扩展性也更高。【不理解这句话的意思】
  • 第三，在一定规模效应的基础上，研发的投入都是值得的。
  • 第四，自主研发的系统可在软件和硬件的多个层次之间不断优化。

在研发 TFS 的时候，Google 公布了 GFS 的设计论文，为 TFS 带来了很多借鉴的思路【CS、SE 是理论与实践相结合的，不仅需要实践，也需要理论作为支撑】

• TFS 对图片存储的需求
  • 文件小，并发量高
  • 读操作远大于写操作；访问随机
  • 无文件修改的操作
  • 要求存储成本低
  • 能容灾、备份

由于文件大小比较统一，可以采用专有文件系统；由于并发量高，读写随机性强，需要更少的 I/O 操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。

• 启示：技术和业务就是这么互相借力推动着的，业务满足不了的时候，技术必须创新，技术创新之后，业务有了更大的发展空间。

• 其他特点【这块我基本就是抄书上的内容】

  • 淘宝的略缩图是实时生成的，这样可减少很多存储空间的需求
  • 图片文件服务器的前端采用了一级、二级缓存，还有全局负载均衡的设置，用于解决图片访问热点问题。【这些技术一点都不新，出来十几年了，近些年终于变成面试高频问点了，或许是互联网数据的爆炸式增长推动的吧】
  • 缓存机制的存在使得最后反馈到 TFS 集群文件存储系统上的流量已经被大大优化了。
  • 在文件定位上，内存用 Hash 算法做索引，最多一次读盘。另外会有很多相同的图片重复上传上来，去除重复文件也是采用Hash算法来做的。写盘方式则采用 Append 方式写，并采用了淘汰策略 FIFO，主要考虑降低硬盘的写操作，没有必要进一步提高 Cache 命中率，因为 ImageServer 和 TFS 位于同一个数据中心，读盘效率还是非常高的

淘宝缓存系统Tair

在使用新技术/改变使用方式时要考虑好用户习惯，否在会适得其反。

• 缓存公告的静态页面
• 缓存大卖家/热门卖家的信息

分布式电子商务操作系统

架构师要考虑系统的扩展性、重用性。

服务化

最开始商品的分类是按树状一级一级来分的，商品数量不断增加，节点越来越深，越来越复杂。用属性替换商品的分类，品牌、样式、材质、男装女装都是属性。建立属性这样的数据结构，把其独立为一个服务。【那一个商品岂不是有很多的属性字段?这种表如何设计？】

个人感觉：当一类操作十分复杂时，可以对其进行优化拆分，拆分为一个服务，供其他系统调用。不仅解耦，也更容易拓展。

中间件

• 高性能服务框架 HSF

服务拆分后如何获得需要的服务？

在显示屏上把能提供的服务显示出来，有需要时先看显示屏，寻找服务所在的区域，然后去这个区域。

• 消息中间件 Notify

分布式的消息中间件系统，支持消息的订阅、发送和消费。

注册消息服务，消息的客户端订阅消息服务。某个客户端发送一条消息， NotifyServer 把消息发送到所有订阅这个消息的客户端。

为了保证消息一定能发出，且对方也一定能收到，消息数据本身就需要记录下来，这些信息存放在数据库中（可以是各种数据库）。由于消息具有中间状态（已发送、未发送等），应用系统通过 Notify 可以实现分布式事务—— BASE（基本可用（Basically Available）、软状态（SoftState）、最终一致（Eventually Consistent））。NotifyServer 可以水平扩展，NotifyClient 也可以水平扩展，数据库也可以水平扩展，从理论上讲，这个消息系统的吞吐量是没有上限的，现在 Notify 系统每天承载了淘宝 10 亿次以上的消息通知。

• 分布式数据访问层 TDDL

数据库也得拆分！

淘宝很早就对数据进行过分库的处理，上层系统连接多个数据库，中间有一个叫做 DBRoute 的路由来对数据进行统一访问。DBRoute 对数据进行多库的操作、数据的整合，让上层系统像操作一个数据库一样操作多个库。但是随着数据量的增长，对于库表的分法有了更高的要求，例如，你的商品数据到了百亿级别的时候，任何一个库都无法存放了，于是分成 2 个、4 个、8 个、16 个、32 个……直到 1024 个、2048 个。好，分成这么多，数据能够存放了，那怎么查询它？这时候，数据查询的中间件就要能够承担这个重任了，它对上层来说，必须像查询一个数据库一样来查询数据，还要像查询一个数据库一样快（每条查询在几毫秒内完成），TDDL 就承担了这样一个工作。

• Session 框架

一台服务器时，用 Session 解决用户识别很简单。集群的时候，用户的请求可能会被分配到不同的服务器上，如何保证这些请求中存取的 Session 值一致？

用户过多时，用户信息都存在 Session 中，检索效率就低了。

session 共享的解决：【成本高，性能差】

硬件负载，将用户请求分发到特定的服务器。【成本高】

Session 复制，就是将用户的 Session 复制到集群内所有的服务器。【性能差，浪费内存】

• Tbsession

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

  前期采用的 Cookie，后来用户量太大了，网络流量大，成本高，又改为了集中式的缓存区 session。

结尾

• 发现问题，解决问题，不要绕开问题的本身；
• 要快速开发出一个网站如何选取技术【成本+时间】。
• 系统无法支撑了，如何抉择【成本+事件】。
• 系统需要考虑用户的接受度【软件是给人用的】。
• 市面上的技术无法支撑系统了怎么办【自研】。
• 系统中涌现出的问题如何思考的，如何解决的【发现问题–>解决问题】。
• etc..
• 电商业务部分的分离，优化措施我个人感觉有很大的借鉴意义。
• 技术需要理论的支撑。

和做科研很像。先调研下大家怎么做的，然后判断下是不是适合用在自己的任务上，再根据实验结果针对性优化。