转载

视频访谈：阮小明：蘑菇街的系统架构演变之路

2. 目前蘑菇街的研发团队有多少人？大概分工是怎么样？

阮小明： 纯研发的有600多人，下面归属的大团队是这样划分的：首先是我所处的电商基础平台是一个大团队，还有负责运维，中间件，稳定性相关的平台技术团队，负责无线App端的客户端团队，另外还有专门负责质量保障的质控团队，有负责很多业务线的综合技术团队。我们在北京还有一个独立的研发中心，这也是我们整个技术大家庭里的一组。

3. 请您介绍一下蘑菇街的系统架构？这个架构里面使用了哪些开源的技术？

阮小明： 蘑菇街现在的架构整体来说还是比较主流的体系，最上层的负载均衡是基于LVS在做，再往下就是Nginx，因为蘑菇街现在是PHP+Java的混合模式，上层业务会用PHP开发多一点，所以 Nginx这一层下来是PHP Web这一块，再往下是基于RPC的分布式框架做的一个SOA体系，这一块主要是基于Java搭建的。在这一层基础上我们那些核心的系统，比如商品、交易、用户这几块都是搭在SOA体系上。其中也用到很多中间件，大部分核心的应用还是我们自己公司内部研发的比较多。你刚刚说到的开源技术当然也用到很多，比如我们存储这一块就用到HBASE，缓存目前主要是redis在做。中间件这块，像MQ，一些分布式框架、还有一些数据的中间层我们都是自己研发。再上层，刚才说到Nginx、LVS这些还是基于开源体系。

4. 蘑菇街在技术研发过程中，形成了哪些技术产品？刚才您讲到有很多是自己开发的，这些东西会不会开源出来？

阮小明： 蘑菇街在整个开发过程中确实沉淀了很多比较核心的产品，像刚才说到的消息中间件，还有一些配置中心，分布式框架，都已经在我们蘑菇街有很广泛的应用了，而且也经历了很多次双十一的考验，整体表现还是非常平稳的。刚才提到开源，开源也是我们后面要做的这一块。因为蘑菇街前期发展很多工作都是基于开源软件来做的，现阶段我们既然有能力做了更多自己的东西，那么我们也希望能把它更好的贡献出来。但是目前因为整个系统要完全开源的话，内部还要做一些代码上的整理、改进，到时候会抽取成为一个独立的开源产品出来，广大网友如果想知道我们在这一块的进展的话可以关注一下蘑菇街的技术博客，域名也很好记，就叫mogu.io这样一个域名。

5. 蘑菇街从最开始成立到现在这么大的提量，它的架构经历了哪几次里程碑式的变化？是怎么一步一步演化过来的能给我们介绍一下吗？

阮小明： 这也是我明天要分享的主题了，蘑菇街从2011年正式成立，到现在已经经历了4、5年的时间，我把这几年划分成了三个阶段，首先第一个阶段是前面两年，2011年到2013年，把这个称为导购时期，那时候主要还是以导购为主，整个业务形态也比较简单，架构也是 nginx+PHP+MySQL，搭建在 Linux上这样一个体系。用到了redis和lucene这种比较主流的框架。因为业务复杂度相对电商来说还是比较轻的，所以整个体系也是比较轻量级的架构。到后来，2013年9月、10月的时候我们开始转型做电商，做了电商之后业务复杂度就上来了，以前不用关心的交易流程，支付相关的或者一些售后相关的就慢慢都出来了。以前的模式我们更多的是纯展现为主，到电商时期的话更多的要管业务逻辑。这时候的架构除了第一阶段还留着的那些体系之外，我们慢慢的也在中间引入了SOA框架，来把我们底层稳定的核心业务系统给沉淀下来。我们电商基础平台主要做的就是这块，把商品交易、用户这些从原来的PHP体系里面给抽取沉淀出来，落到Java这一块。那两年的架构还是以PHP和Java共存为主。2015年到未来的话我们架构还会有大的调整，因为考虑我们现在前端是多端的结构，我们的体系不但要支持PC还要支持App，还要支持各种App的版本，我们要保证后端的稳定，前端又要保证灵活性，所以我们后面更多的是要做前后端分离的事情。

还有一个架构上的演变，后面我们电商的业务越来越复杂了，以前是以女性的服饰类为主，后面会接入各种各样的商品，比如虚拟类的商品，点卡、券，或者一些有别于传统商品的东西，这时候就会对商品体系和交易体系有很大的影响，我们就会把它做成一个平台化的架构。所谓的平台化就是以后有更多的渠道，各种平台过来我们都能很快的支撑他，不需要对现有的体系做很大的调整。

6. 你们现在移动端的占量是不是很大？这个数据方便透露吗？

阮小明： 有80%多。

7. 也就是说以后架构还是以移动为主了？

阮小明： 对。以移动为主，pc暂时还不能丢。

8. 今年双十一的时候，蘑菇街表现如何？尤其高峰的时候你们系统的高可用性怎么做的？

阮小明： 今年双十一从11月10号到11月12号一共持续了三天，这三天还是很稳定的，没有出现任何影响可用性的问题，整体还是很平稳的状态下度过的。

9. 那你们前期做了哪些应对部署？

阮小明： 前期做了很多工作，8月份就开始准备稳定性相关的工作。最早我们接到这个任务之后就开始全面梳理链路上的依赖情况。把依赖梳理清楚以后就开始着手，把一些无用的依赖去掉，然后再做整个链路上一些代码层面的性能优化，我们会看查询的语句是否有慢查询的存在，这个查询包括DB上的查询或者搜索索引上的查询，这些慢条件都会优化掉。一些不必要的依赖都会把它做成异步的形式或者通过其他形式把它结构掉。做了这两块之后我们就开始每个系统单链路的压测，看每个系统最大能承受的量，能不能达到业务的需求。当然肯定会压出一些问题，这样就反复的压测、优化，压测，优化。经过两到三轮之后，再后来的阶段就是全链路的压测了，因为一个系统可能能满足这个量值，但是全链路过来的话，中间也会有一些瓶颈，包括网络上的开销，或者一些意想不到问题都会在全链路的压测上才能体现出来。全链路压测还有另外一个目的，也是想检验一下我们对整个链路上的调用量的预估是否正确。比如入口一次访问可能落到最后端的就是5次甚至10次访问了。我们在一开始梳理链路的时候，也有可能梳理的有些遗漏，通过系统自己压测得到的数据才是最准确的。

10. 你们今年预测的峰值比平时正常的峰值是多少倍？

阮小明： 我们是留了10到20倍的量，实际压的情况也是按照这个目标走，全链路压完以后我们再梳理一下其中有可能存在风险的地方，加上一些开关，容灾的预案，最后经过二到三轮的全链压测，我们会把这些东西全部沉淀为一个完整的作战手册，包括哪些开关要提权执行，哪些是在紧急情况下执行，紧急情况下需要执行的流程是怎么样的，都会以文档形式沉淀下来。最终这些也没有用到，因为整体系统的表现都是很平稳的。这些紧急预案都没有执行。

InfoQ: 好，我的问题就这些，谢谢您接受我们的采访！

原文 http://www.infoq.com/cn/interviews/interview-with-ruanxiaoming-talk-mushroom-system-architecture

正文到此结束