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

嘉宾 黄哲铿 技术管理之巅 作者 海尔电器互联网技术总监 曾服 务于 1 号店 5 年 MySteel 4 年 担任技术总监等职务 有着丰富的理论 和实战经验 擅长大型电商系统 云平台 大数据应用 大型技术团队管 理等领域 个人拥有多项技术发明和专利 在互联网技术圈拥有广泛人脉 和影响力 2015 年出版个人专著 技术管理之巅 如何从零打造高质效互 联网技术团队 责编 钱曙光 关注架构和算法领域 寻求报道或者投稿请发邮件 qianshg 另有 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 通过压测来识别系统瓶颈 这个工作要提前一个月左右去做 否则的话 容易出现测出瓶颈但没有时间修改的窘境 测出来问题我们要有足够的 时间去找出解决方案 比如说有一次我们压测下来 我们发现数据库是 瓶颈 那这个时候没有办法 一个月的时间你不可能去换一种数据库 或者是对底层数据结构做很大的调整 这个时候怎么办呢 只有从硬件 去解决 要么借一台比较 powerful 的小型机 或者是加一些读写卡 增强机器的读写能力 这个时候代码 网络都不需要优化 只要加设备 就可以解决 这是非常幸运的情况 如果说测出要大改的 那就没有办 法了 应该优化的还是要做 4 服务降级策略 刚刚我们已经提到这一点 这个降级我们只要做到应用 级别就够了 不需要做到服务级别 你在应用级别 比如说精准化推荐 图片上传这些都是有开关可以关闭的 5 带宽预估和报备 如果是用的电信或者是网通 只要提前打招呼就可以 了 因为你带宽增加要多付钱给供应商的 所以没有供应商会排斥的 6 第三方接口调用量预估和报备 比如说你这个 App 调用了类似像在线客 服 甚至是支付网关的接口 这个都要向第三方