互联网架构体系讲座随堂笔记

讲座主要内容

淘宝典型的架构应用

顶层load balance，业务分发
二层应用层，各类繁多的应用app
三层服务层SOA，使用多种中间件
四层存储层，MySQL Hbase Oceanbase， TFS
五层分析层，一些日志文件，数据备份，做数据挖掘，分析
侧面对每一层都有安全审计和监控管理。

CAP理论

a) 一致性 C 
b) 可用性 A
c) 分区容忍性 P
最终一致性
举例：大v的微博消息，不需要粉丝在同一时刻都能看到。PUSH和PULL的策略，对活跃粉丝PUSH 对僵尸粉，等待刷时去PULL。
CAP的补充说明：整个机房掉电，这种可能1年只有1，2次，但对于大规模的集群而言，硬盘故障每天都有几十几百例，故障是必然存在的，可用性怎么保证？通过各个备份。

存储

淘宝的存储采用以下几种：
关系型数据库：MySQL，适用一些在线业务
NoSQL数据库：Hbase，Oceanbase，适用一些历史订单数据查询
分布式文件系统：TFS，零碎小文件分布式存储


举例谈及，淘宝的在线业务目前基本都是基于MySQL的，原先在oracle上的业务也都已经同步迁移到mysql数据库上了。以商品库，订单中心为例，迁移时间高达半年。

订单系统的历史数据（如三个月之前的数据），这种不太频繁被查询的数据，将其存放到支持容量更大的Hba<x>se数据库中，三个月之内的数据存放在mysql当中。经过对mysql的优化，可支持单表上亿条记录的查询性能。

MySQL

InnoDB存储引使用SSD擎
支持事务、行级锁、优化支持单表上亿条记录查询。


扩展方法
Scale up : 加内存，提高IOPS（换SSD，或PCIe Flash）

Scale out : 读写分离、sharding分库分表

Hbase

高性能写入、读性能也不错。
动态增加列。支持行级事务。（MangoDB不支持行级事务，库级）
应用案例：
 在线：历史订单
 离线：日志中心，Dump中心，消息

Oceanbase

可扩展的关系数据库，开源
支持跨行跨表事务，支持数千亿记录，数据百TB数量级的SQL查询
应用案例
 宝贝收藏
 直通车卖家报表
 天猫评价

TFS

淘宝的分布式文件系统
案例：
交易快照、商品图片、SNS头像等图片。

缓存层

为缓解数据库存储上的压力，都会使用一层内存做缓存，承担大部分的查询任务。
缓存层淘宝使用的有TAIR，memcache，redis，LevelDB(google)。

中间件

中间件有多种，RPC中间件、数据库是间件、消息中间件。
RPC中间件
服务的远程调用实现像在本地一样执行。几种实现方法：
1. TCP/IP长连接
2. 序列化/反序列化. JAVA Hessian，PB(Google)
3. 同步、异步调用、oneway、callback、可靠异步调用
软负载
 配置中心
 版本控制
可用性保证
故障检测、心跳检测、超时处理、功能降级（实例：广告大图变小图，减少后台压力，但减少了点击量）

举个实例：

淘宝调用支付宝。调用过程如下：
淘宝订单提交通过支付宝接口，发起远程调用，异步调用，淘宝直接返回。支付宝收到调用消息后，执行任务，完成后，通过消息中间件回调通知淘宝端。淘宝收到回调请求后继续处理剩余任务。完成配合。


配置中心功能：
当服务提供者发现故障时，怎么自动实现服务切换，以不影响业务呢？答案是心跳。服务提供者与配置中心有心跳信息，当配置中心认定某服务提供者挂掉时，会向集群广播，然后按照规则，将消息转发到存活的服务提供者去。
比如：刷新一个页面，半天不响应，但如何30s后再刷一次可能就正确加载了。

消息中间件

Notify
metaQ （RabbitQ）
TimeTunnel

数据库中间件

对应用层屏敝分库分表
使用规则引擎动态计算路由，选择正确的表
依赖于配置文件里的规则改变，可以在不重启情况下，改变数据库行为。