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

InfoQ：观众朋友大家好，我是来自InfoQ中文站的丁雪丰，现在正在QCon北京站的大会现场。在我身边这一位是来自阿里巴巴国际站的潘磊。潘磊能不能向观众朋友们介绍一下您自己，还有阿里巴巴国际站呢？

\

潘：大家好，我叫潘磊，来自于阿里巴巴国际站。我大约是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：非常感谢潘磊今天接受我们的采访，也恭喜您今天给我们带来一个非常漂亮的一个演讲，非常感谢！