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

「高可伸缩的移动电商架构设计」这个话题很大包括了几个部分：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. 二十四小时轮值。一方面是给业务保障，另一方面你人在现场，业务和老板们也会更加放心，同时这也是检验我们劳动成果，激励团队士气非常好的机会。通常你准备的比较充足的话是不会出什么问题的，这会提振团队的士气。