「芒果TV」易桂：在微服务下基于GraphQL构建通用一层

在6月9日下午举办的【边缘加速论坛论坛】上，芒果TV后端研发工程师易桂带来了以《在微服务下基于GraphQL构建通用一层》为题的主题演讲。本次大会上，芒果TV荣膺亚太内容分发大会CDN运营领袖奖。

演讲开始，易桂感慨道：“时隔5年后来到曾经奋斗过的北京，日新月异的技术发展，让我有着许多的感慨。最令人兴奋的是酒店里已经配有智能机器人可以乘坐电梯为客人提供专业服务了，这是技术人不断努力的结果。CDN同样如此，技术的不断创新、升级、超越、突破，终使其在互联网上书写了浓墨重彩的一笔。”

易桂介绍，芒果TV是以视听互动为核心，融网络特色与电视特色于一体，实现“多屏合一”独播、跨屏、自制的新媒体视听综合传播服务平台，同时也是湖南广电旗下唯一互联网视频平台，提供湖南卫视电视栏目高清视频点播服务，并同步推送热门电视剧、电影、综艺和音乐视频等内容，以及部分电视台网络同步直播。作为芒果TV负责点、直播一层后端服务的技术人员，面对最核心业务，是如何做技术的创新升级的呢？

对此，易桂分为四点为大家进行了具体介绍。

首先是对芒果TV的播放一层业务和技术架构的发展，易桂介绍了播放一层的前世今生。播放一层负责客户端点、直播功能的后端业务逻辑，是直接面向终端的，所以叫我们一层。芒果TV从最开始的PcWeb端，逐步发展为拥有M站、手机、Pad等客户端，由于我们早期是按照终端来做产品的，这也间接决定了播放一层之前的架构如此。各个终端发起http请求到自己对应的播放一层，各端播放一层再请求下游http服务接口获取数据，进行业务逻辑处理。各端播放一层都包含播放的全部业务，且各端播放业务大体相似，抽象的说有取串、播放页信息、诸多列表和很多配置接口。

此架构的优点有包括以下几点：一是开发简洁，功能都在各个终端的播放一层内部，便于软件设计和开发规划；二是容易测试，核心业务没有复杂的服务调用关系，都是内部调用，方便测试；三是容易运维，各个终端独立部署，互相隔离。不存在分布式集群的复杂部署环境，降低了部署难度。

而随着业务的发展，工作模式发生了变化。由按终端来做产品变为统一做产品和业务，只是终端的承载方式不同。播放一层老的技术架构渐渐暴露出一些问题。“首先由于播放一层包含有复杂的业务逻辑，在终端、播放一层和服务层职责划分不清楚的情况下，小需求的修改，需要牵动终端、播放一层和服务层三方。其次，全端的相同需求，相同业务逻辑需要在各个终端的播放一层实现一遍，产生大量的重复代码。

因此面对这些问题急需改变，BFF架构开始实施，甚至向着越来越先进的CBA技术发展。这就是我们的第二部分内容——BFF架构。”易桂说。

那么，要解决播放一层的问题，芒果TV希望BFF架构做到以下几点。首先是明确定位，明确终端、播放一层和服务层的职责，最主要是搞清楚中间层：播放一层的定位。其次是终端适配，需要一种方便、标准的方式实现多端差异化需求适配。最后是服务化，播放一层合并的过程中抽象出通用业务可以下沉为服务。“这样下来，新的架构很容易就出来了。”易桂说。

播放一层我们定位为介于终端和服务层之间的实现终端差异化的系统。将播放一层的通用业务独立为微服务，下沉到服务层。微服务按功能划分为起播、取串、播放页信息、列表等各种服务化系统。而将各端播放一层合并为通用一层，合并后如何优雅实现多端和多版本的差异化适配成为重中之重。易桂也表示，这一点也是此次演讲的重点。

上述新的架构，其实就是BFF架构（Backend for Frontends），为前端而存在的后端中间层。传统的前后端分离应用中，前端直接调用后端服务，后端服务进行业务逻辑处理。那么引入了 BFF 之后，前端将直接和 BFF 通信，BFF 再和服务层进行 API 通信，所以本质上来说，BFF 更像是一种“中间层”服务。对于BFF需要做到实现多端和多版本差异化适配，有以下几种适配需求。

一是聚合，对于客户端（特别是移动端）来说，HTTP 请求是很昂贵的，所以为了减少请求的次数，前端一般会倾向于把有关联的数据API合并为一个。

二是裁剪，不同屏幕的大小等差异，导致相同接口客户端需要的响应结果内容大小不同。

三是适配，不同客户端对后端响应结果名称要求不同。

那么，具体的聚合、裁剪、适配如何实现呢？

易桂表示，经过调研之后，选中了GraphQL，一种为API而生的高性能查询语言。GraphQL 作为一种 API 查询语言，专门用于处理已有服务接口的响应结果，已被Facebook、Netflix、GitHub使用。易桂举例介绍道：“一个获取视频信息的接口，GraphQL分为服务端描述数据部分，我们在播放一层定义了Video类型数据，有vid，videoName和serialno字段。同时GraphQL会把描述的数据与后端微服务接口做关联，指定哪个服务的哪个接口返回Video类型数据。客户端按需求请求播放一层定义的Video类型数据，例如获取vid为10000的视频，且只需要videoName字段。此时播放一层给客户端的响应内容就只有视频名称信息。”

GraphQL并不是一种编程语言，而是一种 API 查询规格。它的结构为三层结构，其中，最上层QuerySchema是客户端按需请求的接口数据内容，可对服务端描述数据的DataSchema做裁剪和适配等。中间DataSchema是用于服务端描述数据的。最底层的DataFetcher是静态数据、DB、第三方接口等的包装。

随后易桂介绍：“以上就是对GraphQL的初步了解，那么GraphQL是如何做到聚合的？是通过多个服务接口数据聚合、裁剪掉冗余信息、自定义响应内容，以及GraphQL的高性能，即并发获取数据和N+1问题的解决方案DataLoader等。”

而对于客户端（特别是移动端）来说，HTTP 请求是很昂贵的，所以为了减少请求的次数，前端一般会倾向于把有关联的数据API合并为一个。比如Video类型的数据中，客户端期望返回该视频的基础信息同时，还返回播放次数信息。服务端描述数据Video中增加playCount字段，标识视频的播放次数。同时给playCount绑定到播放次数服务的接口。客户端请求Video数据时，也增加playCount字段，那么服务端响应的Video数据就同时聚合了视频基础信息和播放次数信息。

那如何实现裁剪呢？ 如果有客户端获取视频信息时，不需要serialno集数字段，那么客户端请求时，去掉serialno集数字段即可，服务端响应的Video类型数据则没有serialno字段。如果有客户端需要接口响应的视频名称不是videoName，而是vname， 那么客户端请求给videoName取别名为vname，服务端响应的Video类型数据中视频名称字段则为vname。

GraphQL引擎不仅灵活，还可以通过指定查询策略为AsyncExecutionStrategy，实现多个DataFetcher并发执行，提高性能。比如当QuerySchema获取视频信息的同时，还要获取播放次数和明星列表。GraphQL引擎在获取到视频信息后，会同时发起播放次数和明星列表的请求。“虽然GraphQL灵活，但也有天生的缺陷。比如获取视频列表的接口，每个视频都需要返回其的明星列表。因此我们可以通过FaceBook的DataLoader来解决N+1问题。DataLoader支持通过Cache去除重复请求，同时支持去重、合并后，批量请求。”易桂说。

最终，GraphQL提供了如此丰富的特性，让播放一层非常容易就实现了业务的差异化。易桂介绍：“在页面展示的时候，视频播放页面展示列表的时候是播放技术和收藏，如左图所示。存在着不同的使用场景，所以对于相同的数据却有着不同的关注点，我们轻松就能实现这些功能。GraphQL让播放一层应用不再复杂。”

在微服务下基于 GraphQL 构建的通用一层是什么样子的呢？这便涉及到第四部分内容——配置即接口，你值得拥有。“我们实现了配置即可提供新接口给客户端使用的目标。”易桂说。

播放一层基于Graphql-java开发，整体分为三个部分。其中，QuerySchema部分是接入层，管理QuerySchema配置。支持客户端传入QuerySchema，也可以根据客户端传入的code或请求path和params通过规则映射到QuerySchema。而DataSchema部分是各个服务返回数据的图形化组织，用于服务端描述数据。

最后，DataFetcher部分是下游服务的抽象层，可配置各个服务的域名、接口地址、请求参数（包括参数验证）、响应结果等，配套有熔断、容错和降级等功能。易桂介绍：“播放一层这三个部分，由于主体都是配置文件。故可以做到只需要修改配置，即可在已有微服务的基础上，开发出新的接口。”

演讲最后易桂提出，当通用一层算法固定，只有配置变化时，能与我们的边缘加速擦出怎样的火花呢？

最后，易桂表示，期待后续与行业伙伴有深入的交流，并能得到先进技术的意见。