经验说丨华为云视频Cloud Native架构下实践

摘要：来自华为云直播的段亮详细介绍华为云视频在Cloud Native的转型实践中遇到的问题、挑战以及解决之道。

随着云基础设施服务以及边缘计算技术的发展，Cloud Native，即云原生，架构理念和研发也愈来愈普及。从传统软件架构，到云原生软件架构的转变，还须要经历一段时间才能逐渐走向成熟。今天华为云直播的段亮老师从经验和教训的角度，详细介绍华为云视频在Cloud Native的转型实践中遇到的问题、挑战以及解决之道。

主题主要分为三个部分：前两个部分回顾关于Cloud Native自己具备哪些的特征以及架构；第三部分是重点想分享的，即华为云视频业务在探索和实践Cloud Native的过程中具体是怎么作的，以及遇到了哪些问题，但愿本次分享可以对想要或者正在使用云原生的小伙伴带来帮助。

1、Cloud Native的前世此生

1. 业界对Cloud Native的描述

先来回顾一下，在2010年，Paul（Paul Fremantle）提出了云原生的概念，起初只提出了关于弹性、分布式、多租户等基本特征；随着实践和发展，Adrian（Adrian Cockcroft，2013）和Matt（Matt Stine，2015）相继对关键特征进行完善，逐渐提出了反脆弱性、DevOps、持续交付等更新的认识。这就是Cloud Native最初的发展。

从团队来看，CNCF提出了Cloud Native的特征和目标，Gartner也一样作出了重要的规范。

2. 对云原生的定义和要求

华为公司早在201六、17年，就开始经过内部发文的方式，统一云原生定义并规范语言，便于各部分和业务之间对齐语言，包括（微）服务化、弹性伸缩、分布式等，同时对这些关键特征的定义和范围，也都作了很是详细的规范。

3. Cloud Native定义及关键特征

整个云原生，咱们认为应该分红三大部分。基于康威定律，组织决定其所成就的业务。对实践云原生而言，组织的变化最能使咱们感同身受，尤为是对每个人的能力要求发生了很是明显的变化。例如，对研发人员再也不像之前传统模式下的要求，即实现需求就能够；如今，从前端需求讨论，到需求分析，再到开发、参与测试、参与灰度的过程，最后到上线以及线上运行的状况，包括监控、告警等，都须要端到端的关注。因此，对研发团队人员技能的要求提升了。

今天，重点和你们分享的是关于云原生的架构和工程方面。各个公司根据不一样的业务，都会涉及到这两个方面，因此更有参考价值。架构方面的核心是微服务架构，其后还有弹性伸缩和分布式等特征；工程能力有DevOps、持续交付、灰度上线等。最终的目标是让云应用可以快速高效地部署和规模化，以及实现整个服务的高可用性。这是云原生的总体概略，下面我将围绕架构和工程两个方面和你们展开分享。

2、Cloud Native的基本特征和架构

1. 微服务架构的定义及优点

云原生的架构，最核心的部分是微服务的架构。微服务的首要特征是高内聚、功能单一，最好的状态是一个微服务只作一件事情，而且各微服务之间经过进程隔离、独立代码库等，使得每一个微服务均可以单独测试、部署和升级。这样，单个微服务规模较小，能够作到灵活使用且易于管理。实现微服务化后，整个云原生的交付和小团队沟通都能快速进行，由于微服务之间使用API（应用程序编程接口）通讯，没有了开发语言的限制，小团队沟通会更简单、顺畅。任何一个功能点或微服务出现问题，其故障影响范围只存在于本服务器内部，这样能够提高微服务总体的高可用性，且每一个微服务都能单独演化。

2. 传统软件架构与微服务架构对比

既然微服务如此重要，接下来就进一步对比微服务架构和传统架构。传统单体架构的软件是按模块划分的，一个复杂的系统可能会划分几十个甚至更多的模块，每一个模块完成必定的功能，模块之间多是内部代码级的接口调用或本地API调用。能够看出，在架构简单或系统功能单一的状况下，单体软件在初始阶段效率可能更高，由于整个系统使用一套代码，在部署和静态检查时更容易管理，且内存是共享的，能够调用，时延更低，这是它的好处。若是云原生下的全部功能点所有经过微服务化的API调用，调用之间就会形成时延。

那么微服务架构有什么好处呢？进程隔离，代码之间完全解耦，即各微服务能够单独演化和发展。对比传统的单体架构，其在设计上确定想要解耦使模块功能独立，但在架构演进的过程当中，开发人员不免把控不力，致使耦合愈来愈不清晰，同时每一个模块的变更都会涉及到其余模块的升级变动，甚至影响到技术栈发展。一个模块的重构会对另外一个模块产生影响，致使整个系统的演进变得异常困难。可是，在服务化架构下，以上问题都能迎刃而解。每一个服务之间经过API协做完成，更加灵活高效。随着系统规模的扩大，效率也不会下降，可用性和开发效率等方面也能获得保证。

3. 充分利用云基础设施及平台服务

在充分使用云基础设施及平台服务方面，咱们的架构师和设计人员的思路也发生了较大变化。云原生软件构建在整个云的基础上，云包括计算资源、网络资源、存储资源、消息队列等，优先使用云服务上已有的资源，而这些资源经过编排的方式调用，便于实现整个系统的可用性。也就是说，每一个服务、每一个应用，仅需关注本身须要实现的部分，而不是实现每个功能。在单体架构下，较常规的状况是：须要某一特性，就找到一个开源的代码、软件或模块拿来使用，这种方式是不可取的。在云原生下，经过调用其余服务来实现会更聚焦和高效。

4. 弹性伸缩

弹性伸缩也是云原生的精髓，主要须要解决两个问题：一是“伸”，二是“缩”。对于视频业务而言，其规模每每是不可控制的。若主播在直播时产生一个爆点，大量用户涌入，致使业务量陡增。这时，咱们的服务须要可以自动拓展资源，若是等到业务人员接收到高负荷提醒后，再主动升级变动扩展资源，可能会来不及。以上是弹性伸缩中“伸”的部分，而“缩”的必要性主要基于成本。咱们知道，视频天天都会有一个高峰期，好比，教育类的视频服务会在早上上课的时间达到高峰期，而游戏类的直播视频在晚上8点到10点是高峰期。高峰期相对于低峰期，其业务规模相差十倍甚至百倍以上，若资源不会自动开放，在空闲期间就会形成资源浪费。“缩”就可把资源释放出来，提供给其余服务使用。

5. 分布式

分布式是云原生的一个核心理念，主要用于提升可用性。分布式分为三个部分：其一，应用分布式，分布在多AZ（可用区）和多Region（区域）上。若是出现一个故障，不至于影响到其余方面。例如，一个城市的电力系统故障，或者某条光纤被挖断了，也不至于影响到总体服务的可用性。其二，数据分布式。各城市之间，重要的数据须要作到跨Region和跨AZ的同步部署和存储。其三，跨可用区的部署以及总体的调度。用咱们今天的分享举例，整个媒体处理分布在各个不一样的Region上，假设某个城市的光纤出了问题，也不会影响整个直播的过程和质量。这就是分布式带来的好处。

6. 高可用

在云原生下，可用性和传统模式有着本质的区别，在设计思路上就全然不一样，云原生是基于不可靠、可抛弃的资源设计反脆弱性的系统。举例说明：在沙漠上建一座牢固的大楼，应该怎么建？咱们不能由于沙地不稳固，在其上建造出的楼也不稳定。云原生的系统设计，并无假设系统下的资源是稳定的，实际上全部资源均可能出故障。那么，系统的反脆弱性具体应该怎么设计？这才是咱们云原生设计的精髓之一。

7. 承认失败的设计

在传统方式上，咱们老是在安全、可用等方面下大功夫，但愿把系统中的bug和故障所有清除掉，不留任何隐患，这种思路是没有错的。可是，随着云上系统规模愈来愈大，云服务愈来愈多，想要清除全部的bug几乎是不可能完成的任务。在设计上，咱们应该认可失效是时常发生的。同时，须要考虑的是，如何在系统或者某个功能失效的前提下，业务还能正常运行。如，在某一微服务出现故障以后，如何快速发现并自我隔离，从而消除其对整个系统的影响；甚至，在整个可用区和核心服务出现故障时，怎样对服务进行降级，而不是任由整个服务瘫痪。好比，系统中有10个业务，如今出现一个故障，致使3个业务不可用，那么另外7个业务是否能继续服务？这是在云原生下设计系统的一个核心理念。

8. 自动化运维——基于数据分析的全方位故障监控

目前，云原生下的微服务数量较多，大部分状况下，若是系统规模中等，微服务数量是几十上百甚至更多，若采用人工运维的方式几乎是不可能的。由于每一个微服务的运行状态都是很是复杂的，且各服务之间也会产生各类复杂的关系。若仅从最上层的客户黄金指标来判断系统的运行情况，那最终出现问题时，事态可能已经很严重了。因此从开发、部署、升级、问题定位等各方面来看，自动化运维都是云原生下很是重要的一环。

9. 灰度发布

灰度发布也是整个云原生核心的一部分。咱们的系统一直处于开发当中，若是没有灰度发布，如何变动一直在开发中的系统？打个比方，一架飞机在高空飞行，不能等飞机落地以后再更换发动机。同理，若是我是一名客户，想让系统停下再去变动，也是不可能执行的。那么，如何在变动的同时保证全部的业务可用，而且保证系统可以稳步向前发展，这其中有着很是大的挑战。灰度发布是目前应用较普遍的方式，其余还有滚动发布、蓝绿发布等方式，其中蓝绿发布会形成资源浪费。灰度发布是目前经常使用的一种方式，经过灰度升级，逐渐扩大灰度范围，从而保证整个服务的可用性，中途若出现问题则快速回滚。

3、华为云视频Cloud Native实践

下面和你们分享咱们的云视频业务在实践云原生的过程当中的一些经验和教训。

1. Cloud Native架构能力

华为云不但统一了云原生的定义和语言，同时还对多个云原生项目进行了总结，包括内部的架构设计指南，即云原生的架构具体应该如何设计，其中还包括一些优秀案例。对于不一样的场景和模式，咱们构建了架构模式库，在设计过程当中，能够直接参考模式库，方便高效、高质地完成架构设计。对整个云原生，咱们也进行了全面、规范的体系建设，各服务间的Console、风格，包括如何鉴权、AKI网关如何对接、接口风格等，都有统一的规范。最后一点很关键，针对各业务的云原生研发成熟度，在工具中设立云原生架构评价标准，提供数值打分。这样，包括云视频在内的每个业务，均可以衡量其当前状态与理想状态之间的差距，而且知晓待改进的方面在哪里。

云原生是一系列云上经验的总结，在实施过程当中，没有把全部经验全都实践一遍的必要，只需引用业务所需的实践便可。重要的是经验的价值。

2. 架构-微服务架构

咱们对微服务架构也作了总结，从服务发现、服务注册、到服务划分和部署等，各模式都有统一的要求。包括可用性、自动化运维等等，在这里就不详细展开了。

咱们对比一下左右两张图。左图是业务刚刚构建之初的微服务架构，当时对云原生的了解并未深刻，业务逻辑相对比较简单。大概一年以后，咱们发现之前的业务架构出现了问题。第一，开发效率愈来愈低，因为一个服务的开发常常会涉及到其余服务，而且须要频繁变动，致使一个需求须要很长时间的开发才能上线，客户响应时间明显变低；第二，测试愈来愈困难，架构出现腐化，代码出现坏味道。基于多种方式判断，咱们认为须要重构架构。如今看向右图，将以前的VodManager微服务拆分为四、5个服务，每个服务的功能逻辑都是相对独立的，一个需求的开发只会落到1、两个服务里，测试变得简单，开发也更加高效。我认为，微服务划分是动态的，没有一个理想的架构和划分方法，只有一些指导的原则，这些原则就是咱们以前所讲到的，这里就不赘述了。须要根据任务场景、以及系统业务复杂度、用户数量和具体要求等方面统一看待，有问题就进行重构，没有问题就尽量简单化。这是咱们在微服务架构重构方面的一些实践。

再强调一点，这里的微服务架构并不能一次性变动到位，而是一个逐渐演进的过程。可能本周拆分出一个微服务，下周又拆分出一个微服务；并不能提早限定时间进行拆分，而后一次性上线。我认为缘由主要是基于质量上的考虑，若是忽然重构所有架构，可能会涉及几十甚至更多代码同时上线，质量是很难保证的。每次变动一个微服务，就会有一个灰度过程，从而保护客户服务的可用性。目前，整个云视频业务，咱们的服务个数大概有2百个，人均一个或一个多一点的规模，都有对外API接口，接口数量约2千个。并非说越多越好，以上内容仅给你们作一个参考。

3. RTC用户接入微服务容器化实践

咱们认为在云服务上必需要作容器化，由于各微服务之间是相互独立的，并且应该设计为无状态，随时能够被销毁。上图是咱们实时性视频的一个微服务，目前已经商用了，其中一个案例能够和你们分享一下。全部微服务所有容器化，由于任何一个实例均可以被销毁，若是出现变动或是业务量上升，随意拉起一个微服务，其余微服务仍能正常工做。在这里重述一点，进行对外服务的微服务，咱们建议首先经过域名调度，不要经过IP，由于可能会有多Region的状况。你们都明白，若是一个Region出了问题，域名还能解析到另外一个Region上去。对于对外呈现解析的IP，首先它应该是一个EIP，且须要有主备，不能是单一的IP。由于EIP能够对应后面多个IP地址，能够保证任何一个IP或者主机出了问题，都不会都总体服务产生影响。这是对对外服务微服务的一个考虑。

另外，全部微服务之间都不能直接调用，都应该经过服务网格的方式调用。目前华为云上比较成熟的是CSE，该方式通过了大规模的考验。比较新的方式有Istio，这两年逐渐开始使用，服务线数量增长较快。咱们的整个云视频板块Docker（容器）的数量最高峰的时候达到了好几千个。

4. 使用容器化的收益

这里经过咱们本身遇到的一些状况，特别讲解一下容器化的好处。最开始咱们并无采用容器化的方式，后来发现经过容器化，资源利用率明显降低，由于弹性伸缩作的比较容易；另外一点是快速启停，咱们如今用容器基本能够达到秒级重启，若是须要就能够秒级弹出、秒级部署，并且各个服务之间的迁移、依赖关系、解耦、服务打包等各方面操做都很迅速。咱们如今代码的升级、变动、流水线等等都是和容器化绑定的。以上是咱们关于容器化的实践。

5. 实时转码服务的弹性伸缩实践

刚刚也提到，弹性伸缩在云原生里是很重要的一部分，由于它切实影响到可用性和成本。视频中的弹性伸缩主要考虑什么问题呢？首先，"弹"，我认为是没有问题的，上面的配置图隐去了数据。使用起来很简单，根据事件驱动，如内存、网络、业务量等，当达到某一特定值时，相应地弹出多少个实例，弹出速度很是快，基本可达到秒级弹出。因此，“弹”的方面是没有问题的。可是，对于视频业务而言，“缩”也很是重要。

那么，“缩”具体会遇到什么问题呢？视频包括直播、会议、RTC等业务，对实时性的要求很是高。好比，在某一个实例上，有1000个用户同时在观看，其中有800个已经下线，只有200个占用了一个实例，此时应该怎么办呢？咱们的作法有两种，一种方式是，在新业务的调度上，基于部分指定的容器优先预调这些业务，尤为在业务规模的降低期，根据业务的状况，可能要留出半小时到一小时不等的时间进行收缩。对于实在很小的业务，怎样把直播迁移到另外一个容器当中去，并且对用户的观看体验没有任何影响。这才是弹性伸缩实践中，云视频业务作到“缩”的时候很重要的一点。

左下角的图展现的是24小时内高峰期和低峰期的资源利用率。原本，高峰期和低峰期的峰值有10倍甚至百倍之差，但CPU资源的利用率还算平稳，并未出现大起大落。这就是弹性伸缩所须要作到的一个能力。

6. 云视频统一OPS平台

云服务上没有OPS，至关于人没有眼睛。操做每一块业务，可视化每一项服务，出了问题以后快速定位，OPS都是核心能力。业务监控、配置、调用链、日志规模分析等都能在OPS里很好地体现。这一部分与业务相关性较强，因此只展现了云视频能力，包括故障的定位定界、运营、管理、配置等都是必须的。

7. 云视频监控运维系统架构

OPS平台依赖大量的数据，尤为是日志的数据，由于问题的定位定界、故障，告警等，所有分析都依赖于这些数据。在云服务下，整个运维的架构很是重要。对于云视频板块，我向你们展现一下咱们的过程，供各位借鉴。

针对数据采集上报，须要考虑本地冗余，不能直接上报，在失败以后就丢掉。并且考虑成本，并不会预留很大的数据通道供使用，因此本地须要有缓存能力，以及上报失败后重复上报的能力。对于数据接入，咱们采用Kafka对数据进行二次汇聚，由于原始数据过大，对其分析、存储、查询等规模上都没法知足。目前，天天的日志量可达数百T，并且不能长久存储。我认为，运维架构能够不断演进。咱们的运维架构起初设计出来时，比如今的要简单不少，而上图的架构是咱们研究至今的状况。你们在构建日志系统或运维系统时，须要着重考虑如下两点：一、日志上报实时性。日志如同神经表现，快速得到日志，就能快速了解系统中存在的问题并解决。实时性是一个挑战，固然这也和成本挂钩。二、日志实时数据。包括数据的汇聚、分析、展现。

8. 工程能力-服务自治

前面提到在微服务架构下，会存在不少个拥有单独代码库的微服务，其相对单体软件而言更加独立，但随之而来的问题是——管理。每个微服务都须要人工部署，并且频度很高，几乎不可能实现。因此工程能力的工具化、自动化，且可以实现服务自治是云原生中很是重要的一部分，须要在最初时就开始构建。从开发人员写完代码到上线，须要经历哪些步骤？从第一幅图中能够看到，包括开发代码、静态检查、合规扫描、Alpha测试、Gamma测试、自动部署、灰度发布、在线测试等。虽然，开发一个功能可能只须要30-50行代码，但一套流程全靠人工几乎是不可能完成的。可是，在工具化以后，只需在本地开放代码并测试后一键提交，整个过程只在部署环节须要人工确认，其余步骤能够所有经过工具化自动完成，从而实现一人运维多个微服务。目前，咱们的团队每个月大约有500屡次变动，一年达数千次变动。按照业务发展，而且视频领域更加活跃，包括RTC等业务场景，明年的变动次数必定会更多，因此服务自治很是重要。

9. 功能能力-灰度发布

灰度发布也是云服务核心的一部分，服务上线、开发过程质量的基本保障，目前主要使用灰度发布。灰度方式可基于流量、内容、域名、特性等，与开发特性相关，在脚本里便捷地更改后就实现快速发布。每种发布都有验证，验证能够是自动的拨测用例、人工拨测，还能与客户共同测试。

10. 架构-分布式&高可用

前面所讲内容，除了提高效率和下降成本以外，最核心的一点是云服务的可用性。云服务可用性是对客户的服务承诺，出了问题，不只是赔款，更严重的是影响品牌信誉。那么如何作到可用性？总结以下：基于承认失败的理念设计，可以对失败的业务进行降级；同时对于底层资源作到多AZ，这样一个城市的机房出问题时，不会影响总体服务，多Region相互容灾，最后实现总体的可用性。可是可用性只能作到尽量高，不能作到百分之百，整个过程还须要你们共同探索。上图展现了一个比较严重的事件：某个Region区底层的全部资源几乎都不可用了，图中红线显示的是咱们的业务，几乎没有受到任何影响。在保证业务不受影响的前提下提升服务可用性，应该是咱们共同的愿望。

本文分享自华为云社区《Cloud Native云视频实践》，原文做者：音视频大管家。

 

点击关注，第一时间了解华为云新鲜技术~