从这些云原生企业身上，我看到了数字化创新者该有的样子

简介：未来的数字世界是什么样子？手握云原生地图的企业，又将如何颠覆数字化？带着这些疑问，我们采访了教育、金融、新零售、互娱、传媒等领域的多位大咖，他们是数字创新的引领者，也是用云原生技术创造业务价值的践行者。接下来，就让我们一起听听通过“云原生”，他们发生了哪些改变？

01

2020 年，

中国市场开启了云原生大规模落地的元年。

从那时起，云原生广泛走入非互联网企业视野。

云原生架构在这两年逐渐成为应用部署的主流方式。

企业数字化转型若要深入发展，实现规模数字化，

具备弹性、分布式和持续演进的现代化应用形态，

是企业实现数字创新的重要途径和手段。

未来的数字世界是什么样子？

手握云原生地图的企业，又将如何颠覆数字化？

带着这些疑问，我们采访了

教育、金融、新零售、互娱、传媒等领域的多位大咖，

他们是数字创新的引领者，

也是用云原生技术创造业务价值的践行者。

接下来，就让我们一起听听

通过“云原生”，他们发生了哪些改变？

作业帮

降本增效是公司对基础架构的一大要求。在应用侧要提升单位算力承载量，通俗来讲就是 QPS。但我们面临的一个挑战就是作业帮技术栈太多元了，如何整体提升 QPS？再看资源侧，存储、网络这些资源要么是刚需，要么就是很难控制成本，资源侧降本的重点还是计算资源，而对于计算资源我们需要提升单位成本的算力。

“在我看来，在降本增效的过程当中要格外注意一点，降本不能降质，降低成本时，稳定性、效率、安全不能打折扣。我们选择和阿里云一起，选择开源的力量再结合一定的自研解决相关问题。在应用层面，我们提升了主流技术栈的运行性能，对于使用最多的检索服务进行架构重构，以此来提升性能和运维效率。

在计算和存储分离中，我们引入 Fluid 做一个关键的纽带。Fluid 是一款基于 K8s 的数据编排系统，用于解决云原生过程中遇到的访问数据过程复杂、访问数据慢等一系列问题，JindoRuntime用于实现缓存的加速，当我们使用Fliud和JindoRuntime完成整个检索系统的重构之后，获得的收益也比较明显。作业帮的数据更新周期从之前小时级别缩短到三分钟以内，运维整个机器交付从之前天级别缩短到了小时级别，程序性能提升 30%，带来了万核级别资源的缩减。

未来，作业帮会将更多在线服务迁到 ECI 之上来实现真正的削峰，并且更具性价比的 IaaS 资源，这也是我们一直尝试和探索的方向。”

网易云音乐

网易云音乐最初的音视频技术大多都应用在曲库的数据处理上，云音乐曲库团队与音视频算法团队一起共建了网易云音乐音视频算法处理平台，落地了 60 多种音视频算法，尤其是在近一年来，服务化的算法占到了一半，这些算法向云音乐 100+ 的业务场景提供了服务能力。但更复杂的算法、更多的业务场景，对网易云音乐的服务化效率、运维部署和弹性能力都提出了更高的要求，在我们上云之前，在内部已经用到了 1000 台以上不同规格的云主机及物理机。

"我们在一周内快速试用了函数计算 FC，然而一个完整的、高可靠的架构，需要考虑更多的因素。因此我们的改造重点是把算力任务通过函数计算 FC 弹出去，系统在整体的对外输入输出上仍保持不变。

在引入函数计算的第一阶段，特征提取类的算法得到了10 倍速的提升；稀疏类的算法在成本上得到了极大的节约。除此之外，通过函数计算的镜像缓存加速能力，优化了节点的启动速度，让所有的服务拉起可以在秒级完成。这些工作，降低了算法运维处理中的运维成本，让我们能够更聚焦在算法及业务自身。

未来希望通过 Serverless 技术进一步解放我们在运维上的人力投入，并将从存储上进行尝试，让更多场景的音视频算法可以实现。"

安利

互联网的冲击下，安利除了需要适应互联网场景下的敏捷、快速、低成本试错的核心需求，还需要适应互联网场景下的高并发、秒杀、大促等场景。

“云原生中间件为安利构建基于互联网业务中台架构的新电商平台，充分发挥云原生产品的技术优势，支撑 10000 笔/秒的订单峰值。云原生中间件重构了安利社交商业IT基础，打造了安利全球数字化的标杆。”

分众传媒

传统服务器无法满足分众传媒业务高速增长带来的新需求，耗时太长、资源利用率低、运维复杂，对人员技能要求高。

耗时太长：以前的人工上刊无法及时知道上刊是否正确或者错误，需要花费很多时间去核对和修改；

资源利用率低：上刊集中在周六和周日，因此所有资源基本在周六周日使用，大部分时间段不需要使用服务器资源，这就导致资源利用率低；

运维复杂、人员技能要求高：由于业务的复杂度对相关业务人员的技能要求也高，需要招聘更高级的人员来支持对应的运维工作。

“对于我们来说，上云有两个选择。第一个是用 K8s 自己搭建一套容器集群，第二个是用函数计算 FC。如果用 K8s 请求云主机，我们需要自己搭建 K8s，通过对外的 API 来提供请求；而使用 Serverless 计算平台，我们不需要关心用了多少服务器或者多少人力，只需要关心每一次 API 请求是否正确到达，就可以确认每次是否有确切识别到图片，并把识别错误的东西发出来，通知到上刊人员。

阿里云函数计算 FC 支持一分钟内扩充到 7000+ 的实例。如果我们自己部署 K8s 会牵扯到很多人力和物力，因此我们最终选择了 FC。

自动弹性收缩：只需要设置每周六周日有两百万处理量，要在两天完成，其中高峰是早上 9 点-10 点或者下午 3 点-4 点，就可以实现资源的自动弹性收缩；

资源免运维：不需要请专业运维人员；

可提供大规模的识别能力：当我们请求每天上刊人员在早上六点、七点、八点上刊时，可以实时提供算力。

未来我们还会考虑将 Serverless 和 Kafka 结合，用在大数据的处理上，这样的效率会更高；在视频直播流实时推送到视频终端的部分，我们也在尝试使用 Serverless 来解决。”

南瓜电影

一场热映电影加速了南瓜电影对于技术升级的思考。某电影上映后新注册用户爆发，自然爆点，日新增注册用户极速突破 80 万。流量总入口，API，网关，撑不住，紧接着后端服务、数据库，全链路紧急扩容：业务快速恢复，但整个运维过程耗时 4 小时。

"当时有两个方案摆在我们面前，一是自建 K8s，虽然能很好解决高密部署的问题，但是 K8s 学习成本实在是太高了，搭个环境跑跑容易，但正儿八经上生产的话还是要组建好专业团队，短期内显然无法完成。二是Serverless应用引擎 SAE，当时觉得 SAE 不用改造，WAR/JAR包部署，自动弹性，不用买机器，不用运维机器且监控安全。

我们从知道 SAE，到跟阿里云的沟通，以及整个上线，一共是三天时间。到第五天，顺利完成部署上线。到第七天，把剩下30多个系统以同样的方式快速迁移到 SAE 上。

7 天完成了南瓜电影 Serverless 改造：在弹性上，会按照用户的最优化进行自动调整。其次是免运维，SAE 的运维速度比人工更加快捷。最后是发布更快，监控做得也更完善。使用 SAE 后，运维效率提升 70%，成本下降超过 40%，扩容效率提升 10 倍以上，这是给我们带来的直观改变”