应对电商大促峰值的九个方法

快速建立移动电商系统架构的知识框架

「高可伸缩的移动电商架构设计」这个话题很大包括了几个部分： App客户端架构、服务端的架构，还有怎么使用私有云、公有云来部署我们服务端的应用。我会把这三部分内容做一个比较系统、比较概括性的介绍。这次分享主要的目的就是让大家快速的建立一个知识框架：如何搭建高可伸缩的移动电商系统架构。

首先会介绍App端的混合架构，还有服务端的SOA架构，我们也会介绍弹性云的架构设计，基于容器的虚拟化以及电商SOA如何部署在这些弹性云的环境当中。最后的部分，我们会具体讲一个案例。比如说双十一的时候，该怎么去应对这种大促？

App的混合应用框架

如上图，这是App的混合应用框架。大家都知道，我们做App开发的时候，如果说你用Native进行开发，成本很高，但是用户体验会非常好；但是如果说你用H5的话，开发速度很快，但是用户体验就不那么好。

所以业界主流的做法就是所谓的App混合应用架构。从这个框架当中，可以看到，其实我们是通过用JSBridge去封装一些方法，让H5通过调用JS，可以访问摄像头、重力感应等等功能。

在App的混合架构当中，大家在设计App框架时可以考虑，实现H5本地包缓存的机制。通常每一次App请求都是向服务器端发送请求，然后返回给数据给客户端。我们的做法是H5页面框架包包括CSS、图片放到本地，相当于本地有一个http的代理服务器。当用户访问App的时候，我们调用的是本地的H5页面。当这个页面需要加载一些数据，这个时候JS才会去服务端拉取数据。

当然H5其实现在有很多的特性，如：LocalStorage、SessionStorage这里面都可以存储很多数据，比如说购物车信息、浏览信息都可以缓存在里面，不用去服务器端去取。通过这样的方式可以加速整个的App页面的加载速度。

可能有的朋友会问，安全机制怎么办？如果在App客户端有一个所谓的代理服务器，那相当于是服务器调服务器，在安全机制上可能会存在一些问题。当然你在设计移动端的时候，你要有这种认证机制。这就是大致的一个H5本地包缓存的机制，用户请求本地App的时候，他判断这是不是最新的版本，如果不是就他就去服务器端拉最新的H5包回来。也可以由服务器端进行推送。

SOA服务端的架构

接下来我们跟大家分享SOA服务端的架构，这个部分涵盖了从数据层到访问层，到基础服务、核心服务，最上面的就是面向终端用户的网站和App。基础服务层和核心服务层其实就是有没有封装业务逻辑的区别。一般业务逻辑是封装在核心SOA层，基础SOA只是提供一些数据等操作。

我们在设计SOA架构的时候，我们需要注意一些东西。核心的业务模块其实是要能够隔离保护起来。举个例子，比如说价格服务，其实在团购、购物车、促销这些模块当中都会涉及到价格。但是你在部署的时候你可能要做一个隔离，就是哪些原则上只给团购用，哪些只给购物车用。

这样的好处是在极端情况下，我们做过载保护的时候更容易一些，比如说我们大促的时候压力是来自购物车或者是详情页，如果说不是针对团购的，可以把团购这边的价格服务少放几台机器，把这些应用都调到压力大的业务中去。还有就是对服务的监控、负载均衡、降权等等。这里面实际上有一套的服务治理平台。

这就是整体的从App端到服务端的架构。最底层的服务端就是我们上面所讲到的SOA的架构。在SOA之上，我们会加一层分发层，它有很多的适配器，它是专门用来去适配这些平台的。这些服务可能是公用的，但是它有可能是移动在调，PC站在调或者是B2B业务也在调。这个时候你每一个平台的终端所获取的数据其实是不太一样的。

以购物车为例，你在移动端的购物车和PC端的购物车其实所展现的信息是不一样的。在PC端你可以展示很多的促销商品、活动。但是在移动端可能就没有那么多的空间去给你展示。因此这个时候，我们对购物车所要提供的数据，我们可能会做一个适配。这是这个架构当中所需要注意的一点。

如果说你们公司只有一个App，只有H5站，没有PC站，那问题不大。但多数的公司可能本来主要的业务是在PC端，移动时代来了之后，它才把这些业务迁移到移动APP当中，这种公司就要注意架构上的设计问题。

PC端和App端的开发协作管理

这里面涉及到一个开发团队背后协作的问题，如上图。这个可能在你们公司当中也会存在。如果你们的公司当中，你们的系统有PC的也有App的，你们是App一个团队独立做，PC一个团队独立做，还是按业务来划分？

我的建议是按照业务来分，如果说你是做购物车，购物车从UI到service到业务逻辑都是一个团队做处理、做开发。这样的好处是业务逻辑和技术都可以沉淀和传承，可以快速的迭代，减少依赖。否则你做一个功能要协调前台、后台不同的组，这是分工协作上的一个考虑。

就是尽量要让团队、让开发人员相对独立、快速的去完成他的工作，减少团队与团队之间的协作和依赖。无论是做技术架构还是做团队管理，这都是很重要的一个因素。

基于容器的虚拟化

接下来我们稍微了解一下弹性云架构，是基于容器技术的一个虚拟化。这是容器的一个特点，容器和传统的虚拟机相比，以一台4核16G物理机为例，传统的虚拟机只能「1虚5」，一台物理机可以虚出5台虚拟机；而Docker技术起码是10到15台。这个利用率就提升2-3倍，这是其中的一个好处。另外一个就是磁盘空间和网络传输量，如果是Docker的话，举一个例子，我们用一台物理机虚拟了10个Docker，这个时候，你可以在这一台机器上布不同的服务，这些服务相当于是本机通讯，这样可以减少网络传输。

Docker服务器的特点是启动快，创建项目、启动/停止几秒内就可以完成。如果说是传统的虚机的技术，那你装机、部署一个应用，做配置要多久，即便是自动化，起码也要几分钟，而且几分钟已经也算是快的了。这是一个非常显著的优点。

另外你在做装机模板的时候，你甚至可以把你的应用和你的环境、操作系统做成一个镜像。你在装一个容器的时候，其实你在瞬间几秒就可以把环境和服务、应用快速的建立起来。

这是容器运行的环境的例子。这里面大家稍微看一下就可以了。在操作系统之上会构建Docker的环境，在Docker之上会有API管理平台，会对Docker做一些监控、管理、分配空间等等。这是更细的一个Docker的工作环境，我就不详细阐述了。

这是单台物理机当中的整个结构。从最底端的物理机到操作系统，到上面的Docker平台，到Docker平台上的每一个容器，每一个容器上部署的nginx也好，或者是Java环境，JDK+tomcat这些。

这是对容器的一个监控，其实容器的监控当中有很多第三方插件。我们只要使用它对Docker的状态就可以进行一个管理。

 
其实容器也有它的局限性。能否彻底系统级隔离现在还存在一些争议，因为现在go语言还没有完全成熟，随着我们技术的发展，这些问题会得到解决。我们在部署容器的时候，比较适合部署一些应用级别的东西。如果说你要做静态的图片，或者是静态页这些可能就不太适合用这种容器来做。它最佳的实践是部署应用，其他的我们应该使用一些物理机。

关于电商的私有云建设

刚刚介绍了容器，其实当你的企业机器足够多的时候，几百台上千台时候，你应该构建一个私有云的平台。

这是一个私有云的整体框架，包括IaaS、SaaS和PaaS，我们所谓的私有云其是在PaaS这一层，包括存储、网络、缓存等等。

这是私有云的一个管理平台。如果说你有几百台上千台机器，你需要对这些资产，对每个月产生的这些流量、带宽的费用都非常清楚，你作为一个运维管理人员，当老板问你，我们一个月的带宽、CDN、第三方监控的费用情况，你要能够回答出来。以及当应用出现问题的时候，你的硬件出现一些问题，你有没有对这些事件进行跟踪管理。当我们的系统出问题的时候，我们可以很快从这个问题管理平台当中找原因。

比如说10点我们的系统出现问题，报警了。你在处理的时候，你首先关注的是什么？是前5个报警的信息，可能开始报警的是网络不通，接下来负载飙高了，有很多服务不可用了，导致有一些应用开始报警了，这些都是一连串的反应，最重要的就是要先解决前面的几个错误，因为如果拖久了，所有的应用都报错了，你更不知道是哪里出问题了。

除此之外还要有自动发布的平台以及你的应用和配置需要要做一个分离，数据库的链接，环境的配置等等都要一个独立的配置中心去做配置。其他的就不细讲了，这些都是我们做运维时所需要的一些工具。

如何应用弹性云来应对电商大促 

我们要应对电商大促必须要具备这样的能力，包括解耦与隔离能力、横向可扩展能力、流量自动调度能力、服务降级和全方位监控的能力。

流量自动调度能力包括两个方面，其中一个是外网的流量调动，如果说你们的公司的机房是好几个城市的异地机房，是要能够实现流量的切换的。比如说这个时候上海机房的访问压力很大，但是南京那边的机房是空闲的，这个时候你们需要把流量引到那边去。

这里还有另外一层意思，在你的机房里，各服务之间流量调度，比如说你的下单的服务部署了100台机器分了三组，每组30多台。当访问压力来的时候，你的这些分组是要可以做灵活的调度的。哪一组的压力比较大，就把流量分出来。这个关于流量调度的过程应该是自动化的。

全方位的监控包括流量的监控、日志的监控、硬件的监控、网络的监控等等，使它可以第一时间报出来。你的服务、应用要能实现所谓的服务降级。比如说在双十一，有一个很大的抢购，一些比较耗费资源的东西，比如说你网站有一些精准化推荐的内容可能要关闭。甚至比较耗费性能的商品上传、改价等功能给关掉，可以节省很多计算的资源。

我们来看一个例子。比如说你们公司在做一个大促，流量可能是平时的几十倍。首先我们做的第一步就是你要去测算你的这个流量峰值，就是二八原则。20%的时间内产生80%的订单量。这是一种测算方式，你可以根据业务部门的目标说当天他要完成的交易量是多少，比如说是5000万，那么他引了多少流量？假设是1000万UV，你就把1000万的流量做拆分，你就知道你每分钟要扛住的订单量是多少。

应对电商大促峰值的「独孤九剑」

我们通过上面的这些知识可以总结出一个应对大促峰值的「独孤九剑」，就是九个建议，这是我的一些经验总结。你用好这九条，其实一般的大的促销应该都可以扛过去。

1.大促的系统预案。流量来的时候，你的系统顶不住了，那怎么办？当然是加机器。带宽不够的时候怎么办？先和网络服务商打好招呼。这些就是我们的预案，预案不仅是技术、系统的预案，还包括其他业务部门的预案，比如说当天价格标错了，本来是100块钱的东西你标成1块钱，都要有相应的预案。甚至当天晚上办公室停电了怎么办？有一个预案以后你可以告诉你的老板说，我们是有着全方位的准备，是经过周密统筹的。

2.大促开始的前几天，关闭程序发布窗口，这是因团队而异的。如果说你们的应用成熟度比较高，团队艺高人胆大，可能在大促前几天发布程序也没有什么问题。但是我们统计下来，90%的线上问题，都是上线造成的，包括网络设备调试、配置，一旦出问题，你第一个问题肯定是说你昨晚有没有发布应用、有没有修改服务器和网络配置。

3.通过压测来识别系统瓶颈。这个工作要提前一个月左右去做。否则的话，容易出现测出瓶颈但没有时间修改的窘境。测出来问题我们要有足够的时间去找出解决方案。比如说有一次我们压测下来，我们发现数据库是瓶颈。那这个时候没有办法，一个月的时间你不可能去换一种数据库，或者是对底层数据结构做很大的调整。这个时候怎么办呢？只有从硬件去解决。要么借一台比较powerful的小型机，或者是加一些读写卡，增强机器的读写能力。这个时候代码、网络都不需要优化，只要加设备就可以解决，这是非常幸运的情况。如果说测出要大改的，那就没有办法了，应该优化的还是要做。

4.服务降级策略。刚刚我们已经提到这一点。这个降级我们只要做到应用级别就够了，不需要做到服务级别。你在应用级别，比如说精准化推荐、图片上传这些都是有开关可以关闭的。

5.带宽预估和报备。如果是用的电信或者是网通，只要提前打招呼就可以了，因为你带宽增加要多付钱给供应商的，所以没有供应商会排斥的。

6.第三方接口调用量预估和报备。比如说你这个App调用了类似像在线客服，甚至是支付网关的接口，这个都要向第三方做一个报备。告诉他今天有一个大促，流量是平时的十倍，这是正常的，不是系统攻击。否则对方以为你受到了系统攻击，把你的调用给关掉。

7.提前几天开启混合云资源。如果说你们的应用不仅是用自己的服务器，还用了公有云的机器。你除了自己加机器之外，你还要给公有云的供应商打好招呼，提前拿一批机器过来，这些机器要预装好，也要有一些备用的机器放在旁边。

8.备用几十台机器，应对突发情况。

9.二十四小时轮值。一方面是给业务保障，另一方面你人在现场，业务和老板们也会更加放心，同时这也是检验我们劳动成果，激励团队士气非常好的机会。通常你准备的比较充足的话是不会出什么问题的，这会提振团队的士气。

QA环节

我的问题是，做移动电商经常会遇到信息安全问题。我们下单的时候，我们的信息可能被别人看到了。 我想知道一下，你在这方面有什么经验，怎么防止安全的问题？  

这也是一个比较大的问题。其实信息泄露的途径非常多。像你提的这一点，如果我们是通过网络传输泄露的，像淘宝做成全站的HTTPS的可以避免类似的情况，我相信以后大部分电商网站，包括1号店也在慢慢的做。因为什么呢？就像刚刚这位朋友讲的，我们国内网络的这种状况是非常差的。不只是说你在咖啡厅用了一个免费的wifi泄露了信息，最主要的问题还是在于这些运营商，各地的运营商是非常混乱的，比如说你在家里，你打开了1号店的网站，然后会弹出一个京东的广告。这是谁干的呢？这个不是1号店干的，而是运营商干的。他会做劫持，然后做比较灰色的一些广告。这是一种流量劫持的手法。网络上的问题，国家越来越重视。这几年HTTPS的费率也降下来了，像淘宝、1号店、京东都会实现所谓的全站的HTTPS来做。除此之外，就是个人的安全意识。可能很多人都是所有的账户只用一套账号密码，这是很危险的。这也涉及到个人防范意识的提升。

您出了一本书叫做《技术管理之巅》，您做技术管理也做了很长时间，你觉得最难最困惑的问题是什么？你当时遇到了什么样的事情觉得很麻烦，然后怎么解决的？

今天提的问题都是非常大的问题，大家的视野都是比较宽阔的。就个人的经验而言，我觉得在职业生涯当中，对我最关键的就是从纯技术转成技术加管理这个关键点。

我大概工作了三年左右的时间时，就面临这样的一个转折。当时我在MySteel，我有一个机会带一个项目。以前我都是主力开发的身份，后来有一个项目要我来带，那个项目有五六个人，我的角色就变成了技术管理者，而且还兼顾写核心代码的角色。这个时候我就犯了一个错误，只顾完成自己的模块，团队忙得忙死了，闲得闲死了。我也缺乏耐心，通常有人来问我问题，我就说算了你不要做了。我觉得如果教你要两个小时，我自己做只要30分钟，那还不如我自己来做。

这就是向技术管理转的时候一个很重要的转变，你要容忍不完美，你不要指望所有人都和你一样在短时间内来解决所有问题，因为也需要成长。在这个过程当中，其实还有很多的经验，其实我在书当中也详细的提到了这些。

本文根据TOP100Summit旗下技术沙龙品牌into100沙龙第17期录音整理原创首发，转载或节选内容前需获授权。同时，也欢迎更多企业、社区与TOP100公众账号展开内容合作，更欢迎您成为原创作者。更多内容合作请发邮件至wow@top100summit.com，我们期待认识你：）