潘磊谈阿里巴巴国际站发展历程

潘磊谈阿里巴巴国际站发展历程

 

InfoQ

：观众朋友大家好，我是来自

InfoQ

中文站的丁雪丰，现在正在

QCon

北

京站的大会现场。在我身边这一位是来自阿里巴巴国际站的潘磊。潘磊能不能

向观众朋友们介绍一下您自己，还有阿里巴巴国际站呢？

 

相关厂商内容

 

Adobe Flash Builder 4

简体中文正式版高速下载

 

 

视频下载：

Sybase ASE 15.5

内存数据库介绍

 

 

Sybase

在线课堂报名：深度剖析——

Sybase 

ASE 

15.5

的实时数据处理

(11

月

17

日

 

周三

) 

 

InfoQ

急聘：高级市场

/

活动经理、高级销售经理

 

 

潘

：大家好，我叫潘磊，来自于阿里巴巴国际站。我大约是

04

年加入阿里巴巴

的，

阿里巴巴国际站是一个

B2B

的电子商务网站，

主要服务于全球用户，

大概的

情况就是这样。

 

InfoQ

：我们知道阿里巴巴旗下的网站有淘宝、

B2B

国际站，还有支付宝等等。

这些网站都有巨大的用户访问量，相信阿里巴巴能成长为现在这个规模，不是

一日而成的，能否给大家介绍一下国际站的发展历程？

 

潘

：

阿里巴巴国际站可能是阿里系里面存在最久的一个站点，

它建立于

1999

年，

当时只有很少的几台服务器。

发展至今已经整整十年了，

这当中也经历好几次比

较大的重构以及一些架构的变迁，

才有了今天的访问量。

当然在阿里系里面阿里

巴巴国际站的访问量还是比较低的。

 

InfoQ

：在整个发展过程当中，有没有让您觉得如履薄冰的时候？

 

潘

：

这个肯定有，

印象最深的一件事情发生在早期，

那时经常需要半夜起来做一

些维护。阿里对外承诺

7×24

小时提供服务，维护过网站的

 

朋友都知道，这就

意味着我们要在很短的时间内，

及时解决线上问题，

而线上问题往往是稀奇古怪

的，往往晚上一接到电话，大家神经就高度紧张，紧急成立一些团

 

队，然后投

入到紧张的处理故障过程当中。

我觉得应该有无数个不眠之夜，

让我印象非常深。

 

但这是很久以前的事了，

最近还有一件事情，

就是最近的那次重构。

我们那次重

构前后历时有六个月，

把阿里积累了五六年的代码和数据都重新梳理了一遍，

 

因

为时间比较紧，过程当中出了很多的问题，也有很大的困难。当时的项目组，几

乎就是整个国际站技术部，

整整做了大半年。

每个人都加班加点，

基本没有休息

 

日，

一直到发布完成之后，

我们还紧张了好几个礼拜，

我觉得那件事情对我来说

是印象最深得一件事情。

 

InfoQ

：您刚才说国际站经过了一次大的重构，刚刚上线，那能不能从技术的角

度，给大家讲一讲国际站现在的架构？

 

潘

：我觉得阿里系的这些网站的架构，基本都还是比较类似的，除了支付宝，它

的后台是一个支付平台，可能会有点差异。其他网站的架构基

 

本上都会是基于

数据库

+

搜索引擎

+

存储，

当然也会有一些

Cache

，

一些集中式或者分布式的

Cache

系统，这样的一个解决方案。我们基本的做法是实现系

 

统的小型化，以及系统

的分离，经常让读系统依附于一些可线性扩展的

Cache

系统，或者

KV Store

这

样的系统，而把写系统集中在

Oracle

或者

MySQL

这样的数据库上。

 

InfoQ

：讲到数据库，在国际站现在的规模下，数据量应该是不断成指数级地往

上增长，在这方面，国际站会对数据库的容量有一定的规划，您在这方面是怎

么做的呢？

 

潘

：

其实就数据库来说，

我觉得业界的发展方向是比较明确的，

首先是拆分的问

题，拆分其实分成水平和垂直拆分。其实在这之前，我们做的

 

最重要的一件事

情是提供更多、

更丰富的持久化解决方案。

除了数据库，

我们会把一些并不是非

常关系型的数据，都迁移到一些

KV Store

，或者说迁移到一些其他的持久化解

决方案上。

 

在这之外，对于数据库这块，阿里过去一直比较依赖于

Oracle

，甚至比较依赖

Oracle

的

Rack

解决方案，我们将来的目标是，首先让数据库变

 

得更简单，因

为我们会有自己的数据库分布式解决方案，

以及

Cluster

解决方案。

首先要做到，

让数据库，让我们的应用对数据库的类型不再敏感，也就意味

 

着我们可能并不

一定继续依附于

Oracle

。对我们来说，只要是一个标准的关系型数据库我们都

可以使用，

MySQL

、

Oracle

都没有问题，甚至是其他

 

的一些开源的数据库。

 

在这个基础上，

我们还要解决一个数据容量的问题，

数据拆分是一个必然的解决

方案，

我们的方案通常是水平和垂直拆分结合使用。

目前，

所谓水平就是把数

 

据

按照用户的围度进行一个水平的拆分。

所谓垂直是把数据按照一些业务进行独立

的部署。

通过这种方式，

我们基本可以把数据的规模控制在一个比较稳定的范围

 

内，甚至可以实现线性扩展。

 

InfoQ

：我们都知道在数据库性能达不到我们要求的时候，通常会考虑使用

Cache

。前面您的演讲中讲到了阿里巴巴国际站的一个

Cache

策略，能不能在这

里更详细地给我们讲一下阿里巴巴国际站是怎么使用

Cache

的？

 

潘

：其实阿里巴巴国际站在使用

Cache

跟使用其他技术时都遵循了同样的原则，

即使用合适的技术去解决合适的问题，所以我们首先会对

 

应用做一个划分，把

我们的

Cache

定位到不同类型的应用场景。

我们目前既有分布式的

Cache

解决方

案，也有集中式的

Cache

解决方案，甚至还有内存

 Cache

解决方案。我们会根

据不同的应用场景分别应用这些方案，

当然我们的

Cache

种类也比较多。

当然我

们还有一些阿里系特有的解决方案，把一些对性

 

能要求比较高的数据载入到内

存当中，形成内存

Cache

，同时这些数据有集中管理的要求，其实是一种可以集

中管理的分布式内存

Cache

。大概是这样几

 

种。

 

InfoQ

：当网站发展到了一定规模的时候，肯定会涉及到负载均衡，还有多

IDC

部署，甚至是跨洲际的

IDC

部署。在跨

IDC

部署的时候，肯定会遇到数据同步

的问题。在国际站，跨洲际

IDC

部署的数据同步是怎么做的呢？

 

潘

：

首先，

跨洲际的

IDC

负载均衡还是一件相对比较简单的事情，

其实就是通过

DNS

轮寻的方式，我们的轮寻方案也还是比较简单，根据用户所在的地区，加上

一定的策略，去选择对他来说相对访问时间比较好的网站。

 

至于数据同步，

现在多

IDC

之间，

我们都有一个双向同步的通道，

同时会针对不

同的数据同步类型，设定不同类型的策略。国际站的数据同步总体而言，多

 

个

IDC

之间所有的状态同步都是通过一套数据同步系统来实现的，无论是数据库，

还是文件，还是一些

Cache

，它的实现原理基本上类似于一个完全消息驱动

 

的

系统，

当然它比消息驱动要复杂的是在于我们需要在数据同步系统里面去处理一

些异常检测，

或者说业务数据的冲突检测等一些逻辑，

所以这是一套比较庞大的

系

 

统。因为还涉及到一些比较具体的技术点，比如说一些

Oracle

的内置分析，

或者说一些高可用的队列，

所以总体而言，

我们其实是用一套统一的数据同步的

解

 

决方案来解决多个

IDC

之间所有的数据同步，不仅仅是数据库的，也有文件

的，也包含所有其他的状态数据。

 

InfoQ

：

现在很多网站都在追求高可用、

高性能，

对于一些刚刚起步的网站来说，

您对他们有什么建议吗？

 

潘

：我觉得，首先所有的网站设计都应该是从业务的角度出发，这是第一点，不

能纯粹为了技术而去追求一个比较完美的一个目标；

其次，

很多问题在业界都有

比较成熟的方案，

作为一个刚起步的网站，

应该尽量选择一些业界比较成熟的技

术，去作为自己的基础架构。

 

当然，在此之外，我觉得作为架构师，还有一个很重要的素质，要解决所有碰到

的问题，

甚至直接去深入到一些细节，

这样才能保证整个网站架构的可用性，

或

者说稳定性。

这点我很想强调一下，

不要放过任何一个碰到的疑难问题，

往往一

些小问题会对架构产生很大的影响。

 

InfoQ

：

您刚才提到了业务，

其实在一个公司里，

业务与技术应该是相辅相成的，

作为一个架构师，不仅仅要着力于技术，更多的时候应该去做技术与业务的权

衡，您作为国际站的架构师，有没有这方面的经验跟大家分享一下？

 

潘

：首先，我觉得架构的事情，不能纯粹看成是一个技术的事情，因为一个好的

系统，如果没有业务系统去配合，那它是很难长成或者说演化

 

成一个相对完善

的系统的，

所以我觉得架构师首先要熟悉业务，

甚至要擅长做一些系统业务的建

模；其次，我觉得业务和技术的关系就是一个成本和收益的问题，业

 

务就是我

们的收益，

技术就是我们的成本，

所以不能完全从业务的角度，

也不能完全从技

术的角度出发去解决问题，应该充分评估我们的收益和成本，决定用什么样

 

的

技术去解决问题。我比较赞同一个观点，技术或者说架构其实是业务驱动的。

 

InfoQ

：

这次我们的

QCon

有幸邀请到了

FaceBook

和

Twitter

的成员，

前段时间，

Twitter

开始由

MySQL

向

NoSQL

迁移，

业界对

NoSQL

的讨论也非常热烈，

我想请

问一下您对

NoSQL

有什么看法？

 

潘

：

NoSQL

最近讨论得很多，但是有一个观点是非常鲜明的，

NoSQL

并不意味着

不要关心数据库，应该是

Not Only SQL

，或者是我们不仅仅需要关心数据库。

对于阿里这样的一个网站而言，

跟

Twitter

还有一定的区别，

我们的业务类型更

复杂，一些复杂的业务更适合用

 

关系型的数据库去解决；但另一些业务则更适

合用

NoSQL

的方案去解决，

所以我觉得架构的问题，

归结到底都是要选择合适的

技术去解决合适的问题。

 

就目前的技术发展来说，

我并不认为有任何一种技术可以解决所有的问题，

我们

可以看到很多业务，

甚至占了我们很大比率访问量的业务都有希望迁移到

 NoSQL

的架构上，

因为

NoSQL

的架构相对来说扩展性和分布式会做得更好。

我觉得

NoSQL

是对关系型数据库的一个非常好的补充，但它不会成为其替代

 

品，仅仅是个补

充而已。

 

InfoQ

：现在有一些

NoSQL

的产品，比较成熟的有

MongoDB

及

Cassandra

等等，

作为一个架构师，肯定会涉及到技术的选型，如果让您选择技术框架的话，您

会怎么样选择呢？

 

潘

：我觉得要做选型，第一件事是要明确目标，要知道我要什么，这个目标会包

含一些业务上的要求，

也会包含从业务当中抽取出来的非功能

 

性的要求。

当然，

非功能性的要求会有很多，

通常我们会提到一些像可扩展性，

或者说可用性。

如

果这时评估，从网站的角度来说，可用性和可扩展性，其实也很难

 

说哪一点是

最重要的，

可能还是需要根据具体的场景去做一定的分析。

甚至会出现这样的情

况，我一直不排除阿里巴巴国际站会使用多个

KV Store

的解决方案。

 

仍然是那句话，

合适的才是最好的。

我可能会根据不同的业务目标，

或者说根据

不同的非功能性需求，

去制订不同的技术的目标，

然后去选择一个合适的一个产

品。

 

InfoQ

：现在您是一位架构师，没有人天生就能做架构师的，一定是一步一步成

长上来的，我想很多朋友肯定都很想知道您是怎么成长起来的，对于那些希望

能成长为架构师的朋友，您对他们有什么建议吗？

 

潘

：我觉得要做架构师，首先要对技术有很强烈的意愿，你想做这件事，因为技

术这件事，如果你不喜欢，它会变成一件很枯燥的事；其次，

 

要善于学习，学

习有两种，

一种是从书本上，

另一种是从和别人的交流里，

你要去善于学习你自

己不知道的东西，或者说你善于发现自己的短板，有针对性地做一些

 

系统的学

习。

 

要成为一个架构师，

更重要的学习是来自于实践，

曾经有人说过一句话，

我觉得

非常好，

所谓一个行业的专家指的是什么？其实指的并不是他能力有多强，

是

 

指

他碰到过了这个行业里面所有的问题，

同时他解决了，

他就能成为专家。

同样道

理，

做架构师你就不要放过你碰到的任何技术问题，

一定要钻研下去，

知道里面

究

 

竟是什么，

然后解决它。

你就能在每一次解决问题的过程中得到足够的成长，

所谓的架构师我觉得是一个水到渠成的事情。

 

这只是第一步，

技术上我们要这样做，

业务分析同样是架构师很重要的一个方面，

要规划一个更好的系统，你必须要全面地看待这个系统。除了业务，在技术

 

方

面通常也可能会有一些误区，

认为应用架构师只需要关心代码的实现。

我觉得这

是不够的，作为一个架构师，他必须要关心技术的所有外延，比如说操作系统、

网

 

络、存储，甚至数据库，所有关联到的东西。作为一个架构师，应该去全面

的掌握问题，

当然深度你可以根据应用的场景，

可能会因场景而异，

或者因人而

异。

 

InfoQ

：非常感谢潘磊今天接受我们的采访，也恭喜您今天给我们带来一个非常

漂亮的一个演讲，非常感谢！