控制成本是企业迁移上云的主要目标之一，而企业上云后主要成本就变成了运营上的支出，所以技术人员就需要不断进行优化，提高资源利用率，从而进一步达到降本的目的。作为国内 AI 龙头企业，科大讯飞在云原生应用架构转型的实践中，实现了高达 50%的降本成果。InfoQ 采访了科大讯飞资深架构师吴义平，他讲述了一些技术演进中的心得体会。
吴义平，科大讯飞资深架构师。2014 年加入科大讯飞，任职云计算资深架构师，目前负责讯飞 AI Cloud 基础架构演进工作，主导设计了 AI Cloud 2.0 通用计算平台、弹性计算平台等重点项目，个人擅长通用网关、服务治理、弹性计算等方向。他将在QCon全球软件开发大会（深圳站）上进行演讲，主题为《降本 50%——科大讯飞云原生应用架构转型实践》。
InfoQ：有一千个读者心中有一千个哈姆雷特，对于云原生定义也有人用这个话来打比喻。那么在你看来，云原生该如何定义？
吴义平：在我看来，云原生是一种架构设计范式，是一套面向云计算领域的技术体系和方法论，拥有开放、可伸缩、低成本等特性。全面应用云原生架构后，可以实现更少的人力投入、更高的资源利用率，它为研发人员和企业带来的直接受益是降本增效。相较于传统 IT 架构，云原生应用支持快速迭代、轻松复制、灵活部署，真正实现“Build once, deploy any time and any cloud”。
InfoQ：科大讯飞是什么时候开始采用云原生架构的？当时主要想解决的痛点是什么？（演进过程是什么样的？）
吴义平：科大讯飞大约在 2015 年时开始接触云原生架构，曾经与 Pivotal 公司有过深入的技术交流，那时候云原生技术体系还没有今天这么开放。
2010 年，科大讯飞正式对外发布了语音云，随着 AI 技术和行业的发展，能力上云需求和开发者、终端用户均出现爆发式增长。为了满足快速发展的节奏，我们不断在云端架构中添加新的内容，在经过 6 年的发展与沉淀后，架构变得非常臃肿。由于缺乏全链路的问题分析工具链，监控告警延迟高，有时候一个环节出现问题后，会因为问题解决时间太长而演变成故障。2016 年，我们花了大量的时间去处理现网故障和查缺补漏。同时，随着大量的需求输入，我们投入到业务开发的人力和服务器数量都出现了较大增长，成本随之上升，业务方纷纷提出了稳定性和降本诉求。
2017 年应该算是讯飞 AI 云服务的新元年，也是我们全面拥抱云原生技术的时刻，在研究院副院长龙明康的带领下，我们完成了基于云原生技术体系的 AICloud2.0 架构的设计、研发和上线，在稳定性和降本增效方面均取得了关键性成果。
相较于架构演进，我们最开始的变化是将技术栈从 C++切换到 Golang，因为 Go 语言在开发效率和服务性能方面的表现更加均衡。
提升集群的稳定性是当时最急迫需要解决的问题，我们选择基于 gRPC 开发了一套 Go 语言版本的高性能微服务框架，从基础 IO 框架的性能优化做起，先后开发了配置中心 &服务发现、负载均衡、熔断 &降级、流控、全链路日志追踪技术、运行时指标收集等服务治理特性，基于这套服务框架开发的应用可以获得一致的性能和服务治理体验。同时，为了避免在业务定制需求上投入越来越多的人力，我们设计了一套面向 AI 领域的通用业务模型，上线新的 AI 能力通过少量的配置工作即可完成。
为了更快的发现生产环境的问题，我们通过 prometheus + zabbix 构建了新的监控告警系统，并结合通过自研微服务框架构建的应用实时产生的运行时、请求数据，实现了立体化监控，大幅提升了我们的问题排查和定位效率。但保障现网稳定只靠架构演进是远远不够的，我们借鉴了 Google SRE 的经验，分别从 SRE 团队、制定 SLA&SLO 标准、应急预案、应急平台、故障演练等方面构建了满足讯飞现网保障需求的 SRE 体系，已成为保障生产环境 MTTR 的不可或缺的一部分。
全面落地容器化技术在 AICloud2.0 架构演进中发挥了至关重要的作用，它解决了我们在异构环境中的环境、资源隔离问题，为盘活计算资源、弹性调度打下了基础。同时，容器技术也加速我们 CI/CD 的效率，从开发到上线，人的参与度越来越低。
在完成新架构导流和持续演进后，我们已经实现全年无故障，部分 AI 业务的成本相比老架构最高降幅达到 50%。
InfoQ：应用云原生架构时，很多企业都面临的问题就是“越来越大，越来越慢”，那么科大讯飞的架构是否也曾有过类似的问题？你们如何在复杂性和稳定性之间做到平衡？
吴义平：在做大的技术变革时大家应该都有遇到过“越来越大，越来越慢”的问题，讯飞也不例外，它可能是一个过渡状态，但也有可能演变成现状。
在我们这边，“越来越大”主要表现在团队的规模和系统的架构上，架构演进是个持续的过程，同时兼顾新老架构势必会带来人力投入的增长，在这个过程中，我们投入了一小部分人专职做新架构演进，大部分人继续维持老架构的正常运转和需求迭代，团队人员数量在短期内出现了较小规模增长。而在应用架构上，由于当时的讯飞 AICloud1.0 架构已经迭代了 7 年，业务逻辑非常臃肿，组件繁多，为了避免新架构集群变得更加复杂庞大，我们通过抽象 AI 领域模型设计出了一套面向 AI 领域的标准化协议，实现了流量的高度内聚，集群的复杂度和组件数量得到收敛。
作为国内第一家提供 AI 云服务的企业，科大讯飞公有云服务的每日 PV 高达千亿，讯飞开放平台拥有 110w 开发者，应用数量数百万，存量业务成为了架构演进时“越来越慢”的诱因，同时，业务需求并没有因为架构演进而减少。那么问题就成了是继续在老架构增量支持，还是待新架构全部上线再响应？
因为稳定性是平台的立足之本，所以导流比研发新架构更具挑战。为了避免或降低迁移对用户造成的影响，我们采取头部用户单独制定导流方案、长尾用户分批导流的策略循序渐进导流，精准的流量调度和果断的决策是决定大规模流量迁移成败的重要因素。而在架构演进过程中出现的增量需求，我们会按照全新业务基于新架构支撑、存量业务先分级再选型的逻辑去响应，在保证对业务发展不造成明显影响的前提下逐渐下新架构迁移需求。
InfoQ：有没有一些判断标准，来评断一个企业到底该不该使用云原生架构？
吴义平：我认为评价一个企业是否满足使用云原生架构的条件应该满足以下三点：
你的系统刚起步，没有历史包袱，且团队有较强的技术能力；
你的系统趋于稳定，但是还需要迎接未来更大的流量挑战，或者更快的迭代速度；
你的系统当前已经不堪重负，转型云原生架构已经迫在眉睫；
企业能够接受的投入产出比。
如果满足以上条件并且准备实践云原生架构时，建议尽量使用公有云、专有云等现成平台，或者使用社区里的开源项目构建，一来可以节约成本，二来可以获得外部技术支持。
InfoQ：应用云原生架构时，主要成本耗费主要哪些方面导致的？
吴义平：应用云原生架构时的主要成本包括人力和计算成本两部分，人力成本包括框架研发、应用改造以及流量迁移；而计算成本除了新架构所需基本计算资源外，还包括流量迁移时新老架构共存期间过渡集群的计算资源。
相较于传统服务架构，应用云原生架构可以提供更加敏捷的迭代流程、更加灵活的部署方案和更高的资源利用率，这些特性相互叠加后，可以为企业带来明显的降本增效作用。当然，降本增效的前提是企业的 IT 服务需求和服务量均达到一定规模，足以产生经济效益。
InfoQ：云厂商是定价方，可以提供竞价实例的方式降低使用方成本，但作为使用方，你们主要有哪些手段可以用来降低成本？
吴义平：讯飞通过技术降本的手段与业内大的云厂商的方法是基本一致的，其中最直接有效的方法是通过提升软件的性能来达到节省资源的目的，在业务规模足够大时，优化性能的收益非常明显。
在讯飞 AI 业务场景下，我们主要从以下几个方面进行了实践：
1、高性能计算，我们基于 gRPC 构建的 Go 语言版本服务框架中，通过优化 PB 协议、链接池、buffer 等细节，性能相对原生 gRPC 的提升了 30%。而在 APM 日志采集组件上，我们也进行了深度优化，业内开源 APM 方案的日志可用采集性能大概在单机 1000QPS 左右，我们目前已经做到 20w QPS；
2、负载均衡调度，面向 AI 领域的很多计算引擎都需要支持流式处理特性，单次会话持续时间长，这些引擎基本都是部署在 GPU 服务器之上，负载均衡的调度效率直接决定了这些 GPU 服务器的有效算力，我们自研的负载均衡调度算法调度效率做到了 99.9%，GPU 高峰时刻利用率达到 90%；
3、AI 引擎算法优化，持续演进神经网络模型和并行 AI 计算框架，部分 AI 引擎性能获得数倍提升；
4、弹性计算，我们除了有大量的实时计算外，还会存在不小规模的准实时、非实时、离线等对实效性要求低一些的计算需求。在传统架构下，我们规划集群计算资源时需要按照业务的峰值评估配额，造成全局计算水位偏低。为了突破这种局限，我们结合公司内外计算需求，研发出了基于云原生基础设施的弹性计算平台，通过配额管理、全局负载管理、弹性调度管理实现了可控的自动化资源调度，大幅提升了全局资源计算水位。
InfoQ：你怎么看待云原生基础设施的未来发展趋势？
吴义平：云原生基础设施的发展离不开需求的驱动和新基建的持续推进，越来越多的开发者在今后将只关注应用层的开发，云厂商或企业势必会紧贴市场需求，将企业上云所依赖的基础设施做深做厚。
一些企业可能会因为面临合规性、延迟等方面的需要，又或者是因为数据安全方面的考虑，业务常常会部署在不同的公有云之上，甚至一部分部署在公有云，一部分部署在私有云，企业混合云将成为常态，但从目前的实际需求和现状来看，混合云的实施过程并没有想象中那么顺利，企业和云厂商在基础设施的兼容性方面还存在较多问题待解决，这也将倒逼云厂商或企业提供更加标准化基础设施服务，帮助更多企业通过应用云原生技术实现多云无缝切换。
伴随着 5G 技术的逐渐落地，企业对低延迟、低带宽的诉求将得以释放，在未来将会有越来越多的业务场景可以在不通过云端即可完成计算，在提升用户体验的同时也会帮助企业降低运营成本，边缘计算逐渐会演变成企业混合云的重要组成部分，企业或云厂商需要具备将云上基础设施延伸到边缘机房甚至智能设备上的能力，助力业务实现云边端一体化方案。
InfoQ：你认为云原生架构师需要什么样的能力？在云原生实践中有哪些重要的原则？
吴义平：云原生架构师除了要具备传统应用架构师的素养外，还应该掌握虚拟化、网络、存储以及网络安全方面等相关技术，当然，拥抱开源也是必备的素养之一。
云原生应用的 12 要素已经比较全面的总结了云原生实践中应当遵循的重要原则，我从中总结几条最常用的内容：
坚持不可变基础设施，保证环境统一，无论是应用的版本，还是应用版本所匹配的配置，都应遵循一次构建，多地部署的原则。我们在实践过程中要求配置与镜像版本的一致性，而这种约束被固化到了我们的配置中心版本管理中，有效避免了后期因为转移部署或回滚时因人为选择版本而可能导致的失误发生。
应用需要去操作系统环境依赖并尽量做到无状态设计，在拓展了可移植性的同时保证了自由伸缩和调度；
应用之间的通信建议使用标准化 I/O 接口和协议，例如 Http、RPC 等，私有化通信协议将会制约应用的兼容性；
支持优雅启停特性，云计算场景下，服务的可用性不强依赖于单个应用实例的绝对稳定性，扩缩容、滚动升级、异常宕机等可能是家常便饭，应用在设计时应当考虑支持优雅上、下线，确保变更时不会带来可用性抖动，而针对异常宕机场景，则需要在各类负载均衡方案中标配心跳检查、熔断等机制。当这些可能会影响到服务稳定性的细枝末节被一一清除，服务的全局稳定性方能获得保障。
2020 年 12 月 6-7 日，在 QCon 全球软件开发大会（深圳站）“云原生下的应用架构“专题上，吴老师将从讯飞依托云原生技术构建的全新 AI 2.0 公有云架构切入，向大家讲解我们通过技术演进实现降本 50% 的技术路径和经验，包括应用 Serverless、弹性计算和运维架构演进的落地案例。此外还有 PingCAP、阿里云、虎牙直播的专家们带来各自团队的技术实践分享。
大会日程已上线！感兴趣的朋友圈可点击链接查看。
会议咨询：17310043226（同微信）
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论