嘉宾：黄哲铿，技术管理之巅作者，海尔电器互联网技术总监。曾服务于 1 号店 5 年、MySteel 4 年，担任技术总监等职务，有着丰富的理论和实战经验。擅长大型电商系统、云平台、大数据应用、大型技术团队管理等领域。个人拥有多项技术发明和专利，在互联网技术圈拥有广泛人脉和影响力。2015 年出版个人专著技术管理之巅如何从零打造高质效互联网技术团队。责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshgcsdn.net，另有CSDN 高级架构师群，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信 qshuguang2008 申请入群，备注姓名+公司+职位。以下为分享整理正文：快速建立移动电商系统架构的知识框架高可伸缩的移动电商架构设计这个话题很大包括了几个部分：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. 通过压测来识别