鲜花与荆棘同在。云原生在外界看来，是高端大气上档次的时髦热词。弹性、可观测、韧性、可持续等一系列优美的词汇都会出现在它的上下文。但回归到落地层面，却并非一朝一夕之功。
云原生改造是事关企业长远发展的一项重要举措。作业帮的基础技术架构经历了成功的转型，转型过程中面临的挑战也是困难重重，有哪些转型经验值得借鉴？
我们请到了作业帮基础架构负责人董晓聪，分享作业帮在多云之路上的思考与探索。希望本文能给即将或正在数字化转型的开发者、管理者以帮助。
Q：是什么原因让作业帮选择了云原生？
A：本人在 2019 年加入作业帮，发现当时基础技术架构的有两个特点：
一、规模化：作业帮线上有数千个应用服务，这么多应用服务对应数万个服务实例，这么多的服务实例跑在数十万的计算核心之上；二、复杂化：作业帮整体的技术栈是比较多元的。其中占比最高的技术栈是 Golang 和 PHP，还有大量模块是 C++、Python、Java 等进行编写的。
此外，不同的业务特点和团队特点差异很大，比如流量产品，技术栈偏向于保守，而产业互联网的业务架构则由领域驱动，微服务架构比较彻底。
作业帮在稳定性、效率、成本等方面也面临着诸多挑战。
稳定性方面。之前在传统的互联网公司，大家很少接触到用户，对用户的感知更多的是一个个 UV、PV 数字，但在线教育不一样，我们通过直播等形式面对的是一个个学生，每一次稳定性的事故都可能会影响他们的学业，造成不可挽回的损失。所以作业帮对稳定性的要求只能更高。首先，考虑当出现单机、单机群、单云故障的时候，我们的架构能否很好的应对这些冲击？当代码变更导致业务中断的时候，我们能不能快速止损？
再比如效率问题。由于线下、线上的交付物不同（如：线下是容器，线上却是虚拟机），两侧的环境也是异构的，这就导致研发、运维、测试的周期和成本会成倍的增加。
一旦出现网络的抖动、服务的故障，总需要各方不断协调，等着研发等运维，运维等云厂商来恢复，给用户造成非常不好的体验。
另一个很大一部分也是出于 IT 支出的考虑，是结合业务考虑，与多家厂商谈判得到的结果。
综上，基于稳定性和成本、效率等问题的考虑，作业帮选择了云原生以及多云。
改造后的整体收益，还是比较明显的。首先是稳定性，整体机器故障的影响也从分钟级别缩短到了秒级，交付部署的质量得到了大幅度提升。成本这块也有明显的收益。
Q：作业帮在云原生改造的过程中积累了不少专利，能简要介绍下吗？
A：近些年作业帮，在云原生方面积累了一些成果，非常乐于与业界展开分享交流。下面列举一些。
比如在资源层，作业帮打通了各家云的网络，在连通性、高可靠、感控能力等方面处理和制定了一套计算生命周期的平台；在容器层面，开发了一套多云分发的平台；在服务治理层，自研了一套分布式的日志查询引擎方案，这套方案的成本仅为 ES 的 1/10，同时整体的查询效率也比较高查询 1TB 日志的话，耗时是在 5 秒以内，大幅度提高了研发的效率 ；流量管控方面，作业帮的方案已经将 P90 的损耗将至了 0.8ms，而开源方案一般在 3 ms；应用层面，作业帮也自建了可自由切换的多云体系，其中比较经典的是将外呼系统建成了一套多活的架构。
Q: 如何看待云原生的发展
A：云原生提供了以下三种关键能力：容器化、服务网格、多活，三种能力的最终的目的，是把之前云被禁锢的能力释放出来。展开来讲，首先，容器是一个基座的能力，只有容器实现了 100%，上层的能力才能释放出来。
其次，服务网格。目前看，业内已经存在主流的方案 Istio，也有 BAT 自研方案，对于中长尾企业来内的接受度也不错，但也存在部分机制、性能上的问题。Mesh 方面，目前业界没有达成一套统一的标准。随着容器 K8S 标准的形成，关于 Mesh 的标准也需要业内人士的碰撞、交流与探索。
个人比较看好的是，微软之前提出的 Dapr 的 Multi-Runtime 思路。它把更多运行时卸载到 Sidecar ，本质上是将中间件和业务代码进一步解耦。
第三，上层的多云多活，之前阿里云原生实战峰会上公开了应用多活的白皮书。可以看出，企业对于云原生的性能要求越来越高，云原生的规范和标准正在清晰化和明确化。
Q：能介绍下关于 GPU 容器化、多云迁移方面的情况吗？
A：关于 GPU 调度的优化，起源于作业帮使用 AI 推理、图像识别占用的资源比较多。GPU 是一个相对比较贵的资源，通过调研一些方案并和云厂商进行沟通，了解到目前主要推荐的方案是 GPU 容器化，但是这会至少带来 15% 的性能损耗，这个是没法接受的。但我们发现大多数的 GPU 服务使用的各种资源相对比较固定。于是作业帮基于算力和显存去进行了一些策略的调度，根据这些服务与资源进行匹配的方式，也就是比较经典的背包问题，同时夜间也会进行一下预测再重新调度，如果中间出现一些故障，也会执行转移相关的策略。GPU 服务目前已经实现 100% 容器化。
多云迁移，当时对于作业帮来说比较难。因为同时还在做容器化改造，叠加实施的难度很大。我们的做法是将服务注册统一起来，本质上打通容器与虚拟机的鸿沟。多云之间的迁移是分步骤的，将需要迁移的业务在服务发现的过程中解耦掉，就可以分批进行了。
Q：作业帮的云原生的转型，会对技术管理上带来哪些变化呢？
A：比较明显的是，会对运维的方式产生一定的影响。对于运维的岗位而言，中等规模的公司是很难接受的。人肉的工作少了，基础架构的能力更得到重视，不再局限于一些重复的、机械式的工作。
技术的变革，就好比马车与火车的变革。如果能及时迁移到新的技术上来，相信能够带来新的成长。
对于技术管理者而言，这里呼吁大家积极加入这场变革中来，这里是一片广阔的海洋。云原生本身代表着开放，不是开源与厂商之间的争夺。希望大家都能参与进来，一起把这个领域做的更加完善。今天大家把云原生向前推动一步，明天就能从云原生的升级中得到巨大的回馈。
同时，企业在进行云原生改造过程中，不应盲目追求主流的技术方案，一定要从实际的业务情况出发来做选择，这样才能获得实用的收益。团队管理上，应积极引导团队在云原生改造的过程中，保持拥抱变化的积极心态。另外还会出现设施不完备等一系列客观问题，都需要给与一定时间的宽容度。
Q：开源方面，作业帮有哪些进展？
A：作业帮在开源社区一直是有有回馈的，像之前有开源日志方面的方案，至于下一步，整体项目的开源，我们希望把项目做的完善一点，更有普适性之后再进行开源。期待开源后与业内朋友一起沟通交流。
写在最后
容器化、服务网格、多活架构，可以说是云原生发展到目前为止最为重要的三个特点。这些特点是无数云开发者一起努力得到的结果。
正如董老师所言，云原生是一片广阔的海洋。只有更多的开发者和企业一道参与进来，才能助力云原生结出累累硕果，改变与我们息息相关的数智化世界。
专家介绍
董晓聪，2019 年加入作业帮，作业帮基础架构的负责人，负责架构研发、运维、DBA、安全相关的工作，阿里云 MVP、腾讯云 TVP。曾在百度、滴滴等公司负责架构和技术管理工作，擅长业务中台、技术中台、研发中台的搭建和迭代。
作业帮成立于 2015 年，是一家以科技手段助力普惠教育的公司，公司主要的业务分为两大板块。第一，作业帮 App 是一款典型的流量互联网产品，二是作业帮直播课，是一款典型的产业互联网产品，涵盖教育主播链条，如教研、教学、教务、辅导等。
