空智谈淘宝双十一事件中的水平扩容

个人简介 空智，2006年3月加入淘宝网担任系统工程师一职，先后从事系统运维、发布、产品应用运维等工作，目前为淘宝网网站业务线应用运维团队负责人，和团队一起保障网站业务线产品始终稳定运行。

   

1. 我现在在杭州淘宝研发中心采访产品运维团队的技术专家空智。空智你好。请先介绍一下你自己和你所在的团队。

我叫空智，是淘宝这边的流行花名，真名都差点忘记了，叫做曹晔佐，我所在的团队是技术保障部的产品运维团队。

   

2. 今天我们讨论的话题是如何去做水平扩容，能不能简单向我们介绍一下，或者举个例子来介绍一下什么是水平扩容？

是这样的，举个例子，一个网站某个功能可能就一台服务器。但像淘宝支撑这么多会员肯定不可能是一台的，那就是两台、三台、四台这样一直增加，有可能是很大的规模，这就是水平扩容。如果在服务器压力很大的时候，我可以随时把服务器加进去，从十台变到一百台来支撑淘宝的某个业务，就会让我们会员访问的速度更快。

   

3. 那么我们也知道其实这一次淘宝的双十一事件背后，运维团队做出了非常大的贡献，我们想了解一下，产品运维团队是如何来实现水平扩容的？

是这样的，这个其实得益于两点，因为淘宝这边绝大多数都是基于Java这个架构，可能在业界会有人觉得这个比较简单，或者没有技术含量，其实简单也是很好的一件事情，这给我们水平扩容带来了非常大的好处。比如说像我们这次“双十一”活动，当在压力非常非常大的时候，如果这个架构挺复杂的话，可能需要做很多很多事情，才能够把服务器给它加上去来增加系统的负载能力。但是采用了Java这个相对简单的架构后，可以非常快速、简单的把服务器给加上去来支撑这个超大活动的访问流量。

另外就是淘宝这边自己有一套能力模型评测工具。平常对我们的产品其实做了大量的测试来评估它的能力，在平常就可以很清楚这个产品它能力是什么样的，在预估可能会有怎样访问压力的时候，需要提前把服务器，包括一些数据都可以准备好，这样在迎接这个活动高访问量冲击的时候，我们就可以非常从容的来应对了。

   

4. 刚才你提到两个概念，一个是简单的架构；另一个是能力模型，但是我想很多读者对这两个概念还不是非常清楚，你能不能给我们再详细解释一下，你所理解的简单的架构和能力模型含义？

是这样的，其实在业界也跟朋友聊天，他们基于对性能的要求，还有对数据存储容量的要求，可能会把这个系统设计的比较复杂。比如说一个系统需要ABCD…十个系统来支撑起来，但是在对这个系统进行扩容的时候，可能需要对ABCD…这十个系统都要非常非常熟悉并对他们做一系列操作，还要确保每个步骤都不能出错。

比如说在动A这个系统的时候，可能对其他系统有比较大的影响，那这样的话带来的好处就是，我可能对硬件性能做了优化，对数据容量的利用率做了一些优化。但是一些不好地方就是，当出问题的时候、需要扩容的时候，可能需要投入更多的精力、人力还有时间来响应，这就是我理解的淘宝这边用的简单的结构，可以非常快速非常简单有效的来做水平扩容。这是简单架构带来的好处，我是这样理解的。

还有另外一个就是能力模型，我这么想的，如果自己对自己能力越了解，那对未来的挑战就更有信心，比如说当要搞一个活动的时候，对自己的能力已经做了充分的评估，又对未来活动做了一个比较准确的预估的时候，那就可以非常从容的来应对这个活动了。

   

5. 另外一点就是在淘宝“双十一”这几天，整个的产品运帷团队都在做什么事情？

“双十一”活动这几天我们主要就在检查各个核心产品线的当前的能力情况，还有当前一些不太清楚的情况，包括像系统内部网络的流量，还有监控方面，比如说监控是不是有缺失，我们在做这些事情。

   

6. 能不能简单给我们介绍一下，水平扩容它所能够给技术团队，包括整个的网站带来怎样的价值？

是这样的，当业务上需要我们来支撑更大流量，支撑更多会员的时候，我们能够迅速并且非常安全的在不给会员带来影响的情况下，把服务器给扩容上去，提升支撑能力，我觉得这样肯定会给公司业务上，包括给自己、给团队带来很大的信心，这是一方面。还有本次这么重大的活动我们不是顶住了么，这个也是一方面。

   

7. 那我们现在回头来看一下，产品运维团队对“双十一”事件有什么反思或者总结？

肯定有的，因为这次事件让我深有体会一点就是在淘宝这个平台上，没有什么是不可以被打破的，包括交易也好，流量也好，会员也好，通过这次“双十一”全部都打破了，这是我感触最深的一点；第二点就是我们可能对预案的准备还是有些缺失，如果我们能够把预案准备的更充分，对所有的系统都有一套非常准确有效的预案，那我们应该可以做得更好，更从容。

   

8. 我了解到，在十二月底的时候，淘宝网好像还有一次非常大的活动，那么在这期间你们会做什么准备？

是这样的，我们接下来会有两方面的考虑，第一个就是在“双十一”的时候，我们对系统内部的网络流量可能把握的还不是非常准确，当时还出现了个别系统之间的网络流量问题，比如说带宽比较慢了，临时做了一些调整，从A机房调到B机房，像这种操作，其实都是属于我们工作做得不到位的地方。

我们希望通过“双十一”的好好反思，把所有相关的东西都再检查一遍，做到下一次不会有出现过的问题；第二点就是前面提到能力模型这一块，我们也是起步不久，应该是从今年Q3开始做的，做得不是很完善，包括核心系统可能有个别应用还是没有能力模型评估的，我们也希望在非常短的时间能补上，在12月底的时候，体现它的威力，应对下次活动。

   

9. 那我们再畅想一下，在12月底这次事件之后未来的一段时间，产品运维团队有没有什么规划？

接下来可能我们会从前面我提到的简单架构这方面入手。前几天我也跟一些北京的团队同事在交流：我们现在这个架构挺简单，可能会牺牲一些效率，或者说性能优势，但是它有个非常大的好处就是当运维的服务器的规模大到一定数量的时候，标准化就会给我们带来非常大的好处，所以我们在考虑：在我们已有标准化的前提下，是不是可以把自动化结合我们的运维，把它做起来，让我们真正的做到既解放自己，又提高效率、安全和稳定性。接下去我们会花较大的力气来做自动化运维。

   

10. OK，非常感谢空智接受我们的采访，谢谢。

谢谢大家。