案例介绍

跨境交易网站是一个全球多买卖的交易平台，针对大流量、大数据，网站是如何解决业务增长带来的容高量以及高可用的问题。

同时区别于国内传统的电商交易网站平台，全球跨境交易在业务模式、架构设计、以及部署运维上等都有着很大的不同和挑战，例如为了保障全球用户都有良好的用户体验，应用设计上要做到全球异地的的多机房部署架构，带来的挑战就是要解决异地部署带来数据的一致性、可用性、实时性的问题，这也是分布式部署系统遇到CAP带来的难题，分享会产出一些实践中总结出来的一些架构设计原则，并结合实例来进行

 

一、跨境业务的简单业务场景

 

跨境业务是阿里巴巴的一块新业务。阿里旗下有一个网站—速卖通。速卖通是一个跨境网站，而淘宝则是国内的网站，所以速卖通可简单理解为海外的淘宝网。即卖家分布在世界各地，覆盖人群为海外用户。

 

首先，速卖通是多语言网站，涉及18种语言，诸如：俄语，印度语，西班牙语等。其次，海外网站的支付也是不一样的。速卖通的体系虽然是电商交易网站，但是和国内的电商还是有很大的区别。

 

二、架构变迁——网站一代架构

 

小型网站架构，如图2-1所示

图2-1

公司较小的时候，对于应用架构来说，有一个应用层和数据层两层即可实现公司基本的业务，这种架构也是很适合的。

 

速卖通最早是在09年开始做的，最初人较少，做业务的时候，利用点控技术，它是一个B2B，即商家对商家的模式。当初尝试B2C，即商家对个体的模式，这块业务很小，最初上线的时候，只有两个应用，一台数据库。所以说大公司在早期的时候，架构并不复杂，还是以业务为产出的。

 

当网上的流量、用户量、产品量上来以后，这种架构就会表现出很多的问题。那么简单点，比方说最早的应用就两个应用，可能就是一个购买流程，加上一个简单的后台。但是当业务多了之后，各种业务系统都来了，那么这两个业务里面揉合的业务就非常多。各种应用各种业务都在这两个应用里面。

 

简单一点，把应用做简单拆分，将两个应用变成十个应用，但是后面数据库还是要管。Oracle在用户少的时候，流量还是非常小的。但是当应用量再往上涨的时候，其流量应用是很难管理的。对于交易系统网站来说，最核心的是下单。从用户注册，填加购物车到结账，生成订单。那么这项应用里面，有可能不是很关键的业务，因为业务混合在一起，有可能它产生的小的问题可能会导致整个应用出问题。而且在业务增长期出现的几率也是非常大的。

 

抛除第一个，当应用非常复杂的时候，oracle PA上亿，UV达千万以后，oracle最早load还比较小，可能只有2或者3；当业务量增起来的时候，我们发现最高load达到50,60,70.当然那时oracle选的服务器还可以，但是load高是一方面，当访问量上来以后，连接数可能达到几千。这个时候，只有oracle很难支持网上业务。

 

还有我们碰到一些有趣的是当流量来了以后，增量很难预测你的网站会发生什么问题。有时候很大部分根本不是代码问题，这里面其实还有一个非常有意思的是：淘宝做双十一的时候，交换机被点爆，其实我们网站也出现过类似的问题。

 

我们网站的高峰是在凌晨两点。机房层面的一些设备，大家都知道F5这一层，F5做负载均衡的优点比较多。稳定、高性能，但是非常贵。F5当初容量有10G，到后面发现，他的容量是不够的。所以从应用及后面的系统，从上到下所有层发现一些问题出来，就是说业务一方是往上走，当海量数据，海量流量上来以后，如何解决问题？

 

三、网站二代架构

 

3．1 三个策略：

 

1）高容量—当网站流量、数据量不停增长的时候，系统能跟得上。

• 业务之间垂直拆分+服务中心建设

• 业务内部数据水平拆分

 

2）高稳定性—网站可用性指标，有的公司可达9999或者99999。阿里是9999，即一年的不可用时间为53分钟，但并不是网站全部挂了。

• 实时监控

• 机房容灾

• 降级限流

• 容量规划

 

3）低成本

• 去IOE（ IBM ORACLE EMC）、F5

阿里在最早的时候选择IOE，当数据量、商品量、各种图片及用户的访问数据越来越大的时候，这种设备的扩展是比较困难的，价格也非常贵。

• 应用QPS提升、专线优化

应用能撑多大流量，取决于QPS值。即每秒请求数。每秒能支撑1000个QPS，1000个访问请求，单机流量能撑1000.

图3-1

图3-1是改造后的应用结构，比原来多了一层。按业务纬度从上至下进行了拆分。如何让业务之间发生关系，如何调用业务？

 

3.2服务中心治理

服务中心用来解决各个业务之间的调用关系。比如说：业务之间的调用通信是通过服务中心来进行的。形成业务高内聚，低耦合的形式。

 

1）服务治理监控

• 故障排查

 

2）服务分组

• 重要和非重要业务

 

3）服务降级、服务限流

• 紧急预案

 

3.3中间件

1）拆分支撑技术框架

• RPC框架(HSF)：业务系统间同步调用

• MQ框架(NOTIFY/METQ)：系统间异步通信，做到能异步就异步，尽量少同步

• 数据访问层(TDDL)：数据库的的水平拆分

 

2）分布式

• Cache：TAIR

• File：TFS

• Data：MYSQL/HBASE

其实在服务层和数据层还有一个缓冲层。

 

3.4数据层

1）去Oracle，oracle是个单点，我们会选择上mysql。

2）分库分表多分表，单表不要超过1000W

3）隔离，核心和非核心业务独立部署

 

3.5高可用性，如何达到9999

1）工具/平台

• 监控

ü 实时性(秒级)、准确性、自身可用性

• 预案

ü 机房容灾、业务功能降级限流

 

2）机制

• 事前：自动化测试+内网预发+线上灰度

• 事后：人员管理+流程管理

 

四、跨境多机房部署架构

图4-1

 

4.1异地多机房部署问题和挑战

1）业务场景：全球多地写、多地读

2）主要影响因素：异地机房的网络延迟

3）异地部署挑战：CAP

• 跨机房远程读写困难：>150MS延时

• 异地机房数据同步挑战：可用性、实时性

• 多机房的数据一致性

 

4.2异地机房架构设计原则

1）同一数据的变更尽量在同一个机房

• 单一字段有二意性，最好拆成二个字段

2）数据和文件同步分离

3）尽量避免跨机房的同步读写调用，采用异步

4）放弃短暂一致性，强一致性场景采用业务补偿或数据校验

 

4.3异地多机房数据同步

1）主要同步：DB/文件

2）两种方案：强一致性VS最终一致性，如图5-2所示

	描述	优点	缺点
强一致性	DB和文件同时一起同步	无数据文件不一致性问题	性能差，同步慢
最终一致性	DB和文件分开同步	同步快，节约成本。DB同步快，方便预处理；使用不同的网络策略(专线/公网)	DB和图片可能发生不一致性问题(DB先过去，文件没过去，产品破图)

图5-2

 

4.4最终一致性案例：商品破图

1）问题

• DB先过去，文件后过去，前台展示图片不存在

2）解决

• 降低不一致的发生率

ü 产品提交就开始机房同步，利用到前台展示时间差(审核)

• 补偿方案

ü 文件不存在，跨机房远程远程调用补偿(第一次)

 

5.5最终一致性案例：跨机房结算

1）问题

• 多机房的数据统一要在中心机房A做结算，如何保证A机房数据是完整的数据

2）解决

• 针对每个机房数据，增加一张数据完整性校验表

• A机房结算前，统一做数据的检验