来自腾讯云的智能电商系统构建与实战精解

Posted 2021-04-28 InfoQ

很多人认为，企业自建电商平台是一件非常困难的事情，而且成本会很高。实际上，在云时代，构建一个自建的电商平台虽然不能说是一件轻而易举的事情，但难度也绝对没有人们想象中的那样大。但如果说完全从零开始建起，对中小行企业或者 IT 技术能力不是很强的平台来说，也是一个巨大的挑战。

12 月 22 日，腾讯云联合 InfoQ 举办的电商技术沙龙上，来自腾讯云、蘑菇街、小红书的五位资深技术专家，从技术、工具、思路和云平台的选择等角度，分享了如何基于基础云平台解决方案，快速构建一个完全自主可控的电商系统。本文整理了讲师部分精彩内容，感性趣的读者可以点击 “阅读原文” 下载讲师 PPT 查看完整干货内容。

电商行业痛点分析及应对方案

腾讯云高级架构师叶辉的分享，从梳理电商行业痛点展开，在一个真实用户案例中，叶辉展示了某电商平台在原 IDC 环境下的业务架构以及遇到的一些问题。从原有架构来看，遇到的问题包括这样几个：

• 首先，从接入层来说，因为客户业务是分布在全国各地的，甚至还有很多在海外，这些用户并不一定在电信、联通、移动当中，所以非三大运营商用户访问的稳定性会比较差。

• 其次，因为业务放在 IDC 机房，如果 IDC 进行网络切割或者施工造成网络中断，会对业务带来非常大的影响。

• 另外，这个客户有一些推送消息，部分业务模块只在计划任务执行时消耗比较多，但是平时会没有，如果单独去采购服务器，成本压力比较大。

• 最后，伴随客户业务量的爆发，产品要进行快速迭代，技术团队除了应对产品需求，还要不断优化架构提升可用性。

腾讯云的基础核心能力有哪些

针对客户遇到的运营商的问题，腾讯云建立了网络交换平台，对接 38 家中小运营商和三大运营商。那么，当网络交换平台把中小运营商接入、能够覆盖到之前 IDC 机房网络覆盖不到的地方时，还能做什么？叶辉表示：网络是架构的核心基础，网络的能力决定上层业务架构的健壮性和扩展性, 腾讯云所有产品都是腾讯集团自有产品的沉淀。

以腾讯云 CLB 举例，因为做了内存级同步，所以它是不会中断的；另外对于电商来说，秒杀这种场景对连接数有非常高的要求， CLB 在腾讯的 QQ 和微信上也都用到，所以一个单级群可以有 1.2 亿的并发连接数，包转发也能够达到 600 万。

在整个电商购物车环节，消息队列用得比较多。前两年春晚的微信抢红包同样用的是和 CMQ 同样的技术。CMQ 有以下特点，一方面集群是基于算法协议来实现的，数据本身就有三个拷贝；另外提供生产和消费的确认机制以外，CMQ 还有回溯功能，可以对生产数据保留一定的天数，然后在某一天进行回放，同时，CMQ 支持整个全链路的日志轨迹追踪，帮助企业缓解故障排除的压力。

在 DDoS 防御上，腾讯云的产品叫大禹，所有 DDoS 防御的带宽都是采用 BGP。说到主机安全加固，腾讯云也有云镜产品。重点到腾讯云的天御，腾讯云的天御具有庞大用户识别库，能通过大数据技术，快速，准确的识别"羊毛党。

某电商平台架构前后对比

分享最后，叶辉展示了之前那个电商客户选择腾讯云后的架构图，对比来看，从基础的三线 BGP 到了 38 线 +BGP，比之前三线 BGP 覆盖更多的用户，从而提升了用户体验。

这家客户使用腾讯云的 CBQ，包括下端的 CBD，会有专业的团队帮它做维护。

最后一点，因为现在 IDC 网络都是千兆的，万兆成本非常贵，而在腾讯云所有的可用区域是全万兆架构。大数据这块， IDC 的大数据对网络的要求比较高，所以这个客户把自己的套件放到黑石上。

电商直播技术应对之道

视频直播从娱乐秀场的大爆发逐渐走向垂直领域的纵深，电商、教育、金融等各行各业对视频直播的需求已到了非常迫切的地步，在介绍了腾讯云面对电商行业的全面解决方案之后，腾讯资深产品经理钱栩磊以《电商直播技术应对之道》来详细介绍电商 + 直播场景下，腾讯云的解决方案。

直播烧脑 技术门槛非常高

概括来说，直播可以给消费者带来图文介绍或者是录播视频很难提供的临场感，可以刺激消费者缩短决策路径，通过主播带来的气氛刺激消费者消费。虽然直播对电商的促进作用有这么多，但是现实中如何通过直播带来大流量，并进行转化是个大问题。

对于客户来说，如果自己做一个直播 APP，每个模块下有这么多工作要做。比如说上传 / 汇聚，会涉及到视频的编码、视频推流、实时美颜等等；视频转码方面，会涉及到实时转码、多格式转码、多协议转码、转码模块、录制截图等等。如果还要加上互动功能，实现观众和主播进行视频互动、视频连麦、美颜滤镜、特效等等，不仅复杂烧脑，技术上门槛也非常高。

腾讯云视频直播架构

具体到腾讯的视频云解决方案，基于腾讯多年在 QQ 视频的技术沉淀，再加上服务端技术，以及增值直播服务，打包形成了一个视频直播解决方案，这个解决方案整体来说分为三个大模块：一是直播内容采集，二是直播后台系统，三是直播内容播放。具体应用场景就是主播端、服务端和观众端。

在腾讯云直播特性上，首先可以支持超低的直播延时 400 毫秒；其次是多路的视频上麦，支持多路互动；另外，在保证超低延时和多路视频上麦的同时，腾讯云还提供高画质的视听体验。

多场景下的视频直播方案

在视频直播 + 聊天室的服务中，提供一站式的 IM 通讯系统，完整的场景化构造，包括 APP 帐号关联及登陆系统，可以通过 QQ、微信登陆；另外可以发送自定义消息，发送图片、评论、点赞甚至是礼物，这些消息都支持单独形式弹出；同时，作为电商平台还可以在上面浮出商品信息、购物车信息以及支付消息；另外可以直播互动，主播允许后，可以与粉丝进行视频沟通；值得强调的是，直播聊天室没有人数限制。

在直播 + 短视频服务中，腾讯云提供一整套短视频解决方案，包括短视频的 SDK，以及丰富的编辑、特效等性能；另外直播 + 美颜相信大家都不陌生，关于美颜，腾讯云提供的效果非常多，包括大眼、美妆、瘦脸瘦身等等。

对于当前受到广泛关注的人工智能，腾讯云也提供直播 +AI 解决方案，可以对主播进行人脸处理以及人脸识别、人脸关键点追踪，实现很多动效；此外，还可以实现实时绿幕抠图；另外还有 OCR 识别，在快递面单上自动生成可编辑文字，替代人工输入的方式。

分享最后钱栩磊介绍，自从 2015 年推出视频云服务以来，TOP100 里的直播 APP，80% 用的是腾讯视频云；在电商、金融等垂直领域，90% 用的是腾讯视频云，涵盖主播人数 60% 以上。

蘑菇街技术架构规划与成长

作为美丽联合集团旗下美丽说、蘑菇街、淘世界的一个业务实体，蘑菇街技术专家陈辉分享了电商平台的实践和一些感悟，特别是从自主可控、电商平台两个角度引发大家的思考。

分享一开始，陈辉介绍了蘑菇街业务和技术发展的历程。蘑菇街在 2016 年 5 月和美丽说、淘世界进行融合，这个时候不仅仅是蘑菇街一个平台，里面涉及到多个平台，不仅仅是解决单一平台的问题，要解决的是不同平台之间的业务整合、隔离问题。另外，下一个阶段蘑菇街要考虑怎么把电商能力输出。

业务多平台阶段 技术怎么做平台化？

从技术角度， 陈辉着重分享了在业务多平台阶段，技术怎么做平台化，怎么通过平台化技术让业务活下来。蘑菇街三个比较主流的购物入口包括微信小程序、微信小店微商城、自己的 APP，此外还有 APP、H5、小程序等多端和多场景、多平台，这时候应用该怎么分、代码怎么写至关重要。

平台化主要做的事情就是能够支持多平台业务的快速构建、部署，并通过技术手段解决隔离、选择、稳定性等问题。在这其中可以分解为扩展性、隔离性、基础能力、合作与效率等多个方面，根据蘑菇街的经验，归总为一些原则：

• 首先，代码只能有一份。蘑菇街在做 detail 的代码，去提供详情页服务的时候，因为资源、成本的问题，也考虑到重复建设性的问题，所以代码只有一份，本身就是做类似于框架上的拆分。

• 第二不同业务做到隔离，互不影响。比如说改了蘑菇街的代码，美丽说的平台不能受影响。

• 第三要支持业务的快速扩展。如果要花一个月的时间才能把平台组建起来，这个能力不是我们想要的，如果通过某个原数据切分，就可以把这套体系搭建起来，甚至花不了一天时间，这才是我们想要的快速扩展。

• 第四，必要时需要支持共建。有些代码是需要合作的，合作的基础是本身这个代码层次以及框架的本身设计是否合理，如果不合理很有可能造成两边会相互冲突。

• 第五，支持日常分开部署，但是大促时需要合并到一起，统一去做一些容量规划相关的事情。现在经常说混布的概念，比如说把大数据的离线任务和在线任务进行混布，提高机器的资源利用率，像类似这样的问题蘑菇街都会在这个阶段考虑。

上图是蘑菇街架构整体解决方案，用模块化框架以及一系列的核心插件去解决一些依赖、管理、隔离相关的问题，上层会有不同的业务模块去拆分，然后切入到本身的业务管理里。

平台化解决不了的问题 该怎么办？

对此陈辉认为，平台化能够解决的问题包括稳定性、快速扩展、标准化场景，但是不能解决的包括：业务上多平台之间要穿插，应该怎么做？从技术上来讲，电商不只有后端服务，其实电商还有包括安全、风控、运维以及其他任何基础的一些支持。还有前端，如果我们仅仅考虑后端相关的东西是不够的，比如还要考虑 DevOps 的落地、还有效率相关的问题，这是蘑菇街在后面阶段看重的点。

基于以上问题，蘑菇街会去考虑 serverless、service mesh、SOA、微服务…把这些叫做 Buzzword，这两年最热的就是这些概念；另外，还会考虑钱和业务的问题，是不是要投入全部精力去做技术上的创新？因此会考虑 business ecosystem，标准化以后向外提供标准化服务。此外还可以看类似 Lambda 这样的模式是不是也是我们想要的，可以不用关注弹性、扩容，不去关注网络成本、质量，类似这样的方式是否可以更好地提高效率。

据陈辉介绍，如果非要问蘑菇街为什么要自建平台、自建平台的好处是什么、为什么要自己搞 PaaS？只能说时机到了。在合作伙伴的选择上，蘑菇街选择了腾讯云，在蘑菇街上云这件事情上，腾讯云给予了很多支持，从服务的专业程度和细致程度，也给陈辉留下了深刻印象。

小红书大规模容器化应用实践

小红书是一家发展非常快速的公司，在技术层面来看也是如此，近段时间小红书的开发团队在对业务系统进行微服务化改造，同时也进行容器化的推广， 以期提高线上部署的效率，控制发布风险。那么，关于容器化小红书有什么样的心得呢小红书运维总监孙国清现场分享了小红书大规模容器化应用实践。

为什么要容器化

大家都知道容器有很多优点，对于小红书最看中容器的三个方面：部署效率、弹性容量和善用资源。

• 首先是部署效率，从部署效率上来说，在不同环境，从开发到测试到生产环境，容器可以做到一致性的部署，这样可以大大提高部署效率。另外开发者在自己的笔记本上、工作站上去开发的时候，他的代码和部署在线上的环境是保证一致的，这样从开发到线上的过程中有很多问题就规避掉了，不会因为个人的开发工作站和线上环境不一致而导致的一些问题。

• 二是弹性容量。小红书是一个电商，每年会有好多次大促，如果还是基于传统的部署，实际上不管是开发还是运维方面都有很大的压力，10 倍的容量要部署很多的服务器，这还是有非常大的挑战的，因此，小红书希望通过容器来做到弹性管理容量。

• 三是善用资源。主要说的是线上服务器的使用率，或者说服务器的部署密度，就是在一个服务器到底可以部署多少个应用，可以最大限度地把 CPU 的资源用起来。在传统环境，可能我们在混布的时候还要采用一些复杂的方案来解决隔离的需求，在容器的话，基本上把关键的资源，像 CPU、内存、网络带宽的隔离都做到了。

基于以上考虑，小红书开始实施容器的部署实践。    左边是我们的 CI 过程，右边是监控和日志相关的内容；prometheus 作为监控的平台，ELK 是日志系统，这里面，prometheus 和容器的搭配是比较好的，对于容器监控内容的配置上，可以实现完全的自发现，免配置；最下层是一些基础的组件，traefik 可以帮助规避 kubernetes 里的所谓 iptables 陷阱。最下面是 docker，小红书的整个环境都是建在腾讯云上，利用了腾讯云上的容器服务来搭配。

孙国清表示，在所有组件里面，有一个是最重要的，Spinnaker。Spinnaker 是 Netflix 的一个开源项目，拥有开放性和集成能力，以及较强的 Pipeline 表达能力，同时，Spinnaker 支持多种云平台，是一个非常完善的发布系统。

上图是 Spinnaker 系统的界面，里面有一些术语和 K8s 需要对应，并不是完全照搬的概念，因为它是支持多平台的系统。在 KBS 环境里，每个绿色块代表的是容器实力，聚在一起的绿色块可以理解为 KBS 里的 RS。那么为什么会有几个块聚在一起呢？它叫做 cluster，一个应用的不同版本在一个 cluster 里可以同时存在，你可以对 cluster 做管理，也可以用 Pipeline 做发布的触发。

Pipeline 的表达能力是非常强的，可以并发去执行一些工作，等所有工作结束了再继续下一个工作，所有开发者对于发布系统的 Pipeline 的期望，它都可以做到。在这里面每一个绿色圆点代表的是每一个步骤，叫做 stage，所有 Pipeline 的执行能力都是用 stage 来做的。

小红书容器化的部署过程

以上是小红书的容器部署工具，那么，如何有什么样的流程可以把这些工具串起来呢？经典的流程有三个：一是在开发的时候，二是做集成测试的时候，三是上线。

开发的时候，代码切出了一个 feature 分支，每次开发都将代码提交到分支，一旦提交以后，它会专门为你构建。

集成测试，就是当开发者提交到 release 分支，然后触发 Jenkins Job，Jenkins Job 会专门为分支做一个构建，构建之后做触发部署的 Pipeline，在整个部署内，需周而复始很多次，需要多次修改上线调试。但也可通过自动化工具，比如黑盒子工具测试 API。

在上线环节，小红书会遵循 Canary 发布过程。即先把用户进行分类，有些用户能够接受不稳定，小红书把它引入到新版本，过段时间之后再听听用户的反馈，如果可以就扩大容量，这样的过程是持续的且达到 100%。该过程是通过 Spinnaker 来控制的，即整个的流量控制。

上图为 Canary 的底层架构。Canary service 是用来做流量分发的组件，对金丝雀用户的分组有感知，流量进来之后，经过测试做完、路由完后，会分发到某一个 service 的特定的 Proxy，会有策略判断将其分发到新版本还是旧版本，Proxy service 有一个 API，然后通过调用 API 调配它的策略。

Canary 策略，可以基于用户的设备类型（ios 或者安卓）、来源 IP 或者是这些东西的组合，或者是完全随机。我们经常使用的策略是公司内部办公室的所有 IOS 用户或者公司办公室的所有安卓用户先来试验新版本。

以上是小红书在容器部署过程中的一些技术实现的细节。至今，小红书有 80 多的应用已经跑在容器环境中了，所占全站流量大概是 1/3 左右的比例，预计在明年 Q1 的时候，小红书 100% 的流量会跑在容器里。现场，孙国清还透露，如果顺利的话，明年大促的时候，小红书所有的流量将全由容器承担。

云上迁移方案设计思路与工具

迁移的场景丰富多样，业务系统各有不同，好的迁移方案的设计不仅能够节省迁移成本，还能帮助用户拥有更加完备的异地部署和灾备能力。依托腾讯多年的大规模数据运维经验，腾讯云提供了安全可靠的数据传输工具，帮助用户更好的完成迁移。本次沙龙最后一次分享嘉宾，来自腾讯云技术专家姚俊军，将为大家分享完整的云上迁移方案设计思路与工具。

什么是云上迁移？

姚俊军首先以搬家类比迁移，深入浅出地阐述了云迁移及其方案的本质 。姚俊军表示，把东西从源端搬到目的端的过程就是搬家，搬家的时候，大家可以选择搬家公司帮忙完成搬家，开发者也可以选择迁移合作伙伴来帮助完成这件事；大家会选择一些有利的工具，比如大车、面包车。而迁移工具也非常多，比如数据库迁移工具、对象重组迁移工具。而剩下的就是物品，比方说搬家时的家电、家具，迁移时的数据、文件、代码、逻辑、甚至是与大数据相关的东西。那么，具体说到迁移场景，根据客户的实际情况可能会有这么几种：

• 第一种，普通的上云迁移。这是从本地的 IDC 或者说从一个友商云的服务环境迁移到腾讯云，这种场景比较常见，也可能适用于在座的各位。

• 第二种迁移环境，数据灾备迁移。随着业务的发展，我们要尽可能去保证业务的高可用，即便我们不会做两地三中心的高可用架构，但也可能会做异地的灾备或者容灾，所以说腾讯云可以在这样的场景下做灾备的节点做迁移。

• 第三种，跨地域部署迁移。这种迁移方式较为常见，因为我们客户分布的地域比较广泛，我们需要就近让客户接入服务体验，这也相当于我们的节点。

• 第四种，混合云的方案来满足业务快速扩张，这种更适合传统企业，而电商行业可以考虑，需视情况出发。

腾讯云从众多的迁移案例里提炼出了一个通用的迁移流程，大概是分了四个阶段七个步骤。四个阶段分为前期评估阶段、准备阶段、迁移实施阶段、优化阶段。而七个步骤分别是业务架构评估、方案设计阶段、测试验证阶段、环境部署阶段、正式迁移执行阶段、上线切割阶段以及最终云上优化，这大概就是一个相对而言迁移流程。

迁移在实施过程中，其实会有几种选择，因此，也会有不一样的迁移路径。如下图所示，如果适合重新托管，那么便可以做迁移工作。其中一种方式是完全用自己的方式、自己的能力，手动安装、手动配置、手动部署，然后完成迁移。另外一种方式是可以使用一些工具，这个工具可以是自己的工具，也可以是腾讯云提供的工具。

通过迁移上云，用户会获得一个成本节省的能力以及云上服务的能力。比如，迁移上云，我们的资源利用率会得到提高，运维成本会得到降低，云上的弹性扩容、安全稳定、高可用也成为我们即将具备的能力。除此以外，就单单迁移这件事，如果通过去设计一个较完整的迁移服务方案来完成这样一个迁移任务，这会使我们的技术团队快速获得一个跨 IDC 的业务能力。

如何设计云上迁移方案？

设计云上迁移方案，一般先从了解自身架构开始，然后去确定采用哪种迁移方式。姚俊军现场推荐了两种迁移方案，一种是全量停服迁移，另一种是平滑不停服迁移，可以根据自己的业务情况去选择。

• 全量停服迁移：全量迁移很直观，即将数据从 A 机房迁到 B 机房，而业务逻辑视情况调整做一个 1：1 或者其他比例的部署。当增量数据、存量数据、网络配置都调整完，B 机房是 A 机房拷贝的时候，再将流量从 A 机房迁到 B 机房。这种方法的优点是通用性强，过程简单，流程清晰，对业务系统要求低，不要求系统逻辑分层清晰，耦合依赖大也没关系。缺点是因为全量迁移，停服时长不好把控，将所有功能业务验证完才敢切流量，回滚问题多。这种情况比较适用于目前系统规模不太大、业务相对简单，流量相对小一点，最重要的是我们的业务要允许做停服。

  
  

演讲最后，姚俊军简单介绍了环境配置、应用内容、文件、大数据、数据库等一般的云上迁移内容和方案。并现场向参会者推荐了一些常用的迁移工具，包括 DTS、COS 本地上传、COS 在线迁移、CDN 等。姚俊军表示，除了拥有比较完整的迁移方案和云端基础设施，腾讯云也有一些较好的合作伙伴，这里面有做实施的、有自己核心技术的，能够为开发者提供了一个比较全面的迁移技术和迁移生态。