6月9日下午，在【边缘加速论坛】上，芒果TV后端RD工程师易贵做了题为《微服务下基于GraphQL构建通用层》的主题演讲。在本次大会上，芒果TV荣获亚太内容分发大会CDN运营领袖奖。
演讲一开始，易贵就感慨地说:“时隔五年，我来到了曾经奋斗过的北京。日新月异的科技发展让我感慨良多。最令人兴奋的是，酒店已经配备了可以乘坐电梯的智能机器人，为客人提供专业服务，这是技术人员不断努力的结果。同样，CDN在技术上的不断创新、升级、超越和突破，也终于让它在互联网上写下了浓墨重彩的一笔。”
易贵介绍，芒果TV是一个以视听互动为核心，融合网络特色和电视特色，实现独播、多屏、自制“多屏合一”的新媒体视听综合传播服务平台。也是湖南广电旗下唯一的互联网视频平台，提供湖南卫视的电视栏目高清视频点播服务，同步推送热门电视剧、电影、综艺、音乐视频，以及部分电视台的同步直播。作为一个负责芒果TV，直播一层后台服务的技术人员，面对核心业务，如何创新升级技术？
对此，易贵分四点给大家做了详细的介绍。
首先是芒果TV的播出层业务和技术架构的发展。易贵介绍了播层的前世。负责客户端点和直播功能的播出层的后端业务逻辑是直接面向终端的，所以称为我们层。电视从最初的PcWeb端，逐渐发展到拥有M站、手机、pad等客户端。由于早期我们是按照终端做产品的，这就间接决定了打第一层之前的架构。每个终端向其对应的播放层发起http请求，每个终端播放一层后请求下游http服务接口获取数据进行业务逻辑处理。每个端播层包含所有的播放服务，每个端的播放服务一般都差不多。抽象来说，有取字符串，播放页面信息，很多列表，很多配置界面。
这种架构的优点包括以下几点:一是开发简洁，功能都在各个终端的广播层内部，便于软件设计和开发规划；二是易于测试，核心业务没有复杂的服务调用关系，都是内部调用，方便测试；第三，易于运维，各终端独立部署，相互隔离。没有复杂的分布式集群部署环境，降低了部署难度。
随着业务的发展，工作模式也发生了变化。从终端做产品到统一做产品和服务，但是终端的承载方式不一样。广播层陈旧的技术架构逐渐暴露出一些问题。“首先，由于广播层包含复杂的业务逻辑，当终端、广播层、服务层的职责划分不明确时，小需求的修改需要影响到终端、广播层、服务层。其次，所有终端相同的需求、相同的业务逻辑需要在每个终端的回放层实现，导致大量的重复代码。
因此，面对这些问题，BFF架构急需改变，并开始实施，甚至向越来越先进的CBA技术发展。这是我们的第二部分-BFF架构。”易贵说道。
那么，要解决第一层的播放问题，芒果TV希望BFF架构可以做到以下几点。首先明确定位，明确终端、广播层、服务层的职责，最重要的是明确中间层:广播层的定位。其次是终端适配，这需要一种便捷、标准的方式来实现多端差异化需求适配。最后是服务，在玩一层合并的过程中抽象出来的一般业务都可以下沉到服务中。“这样，新的架构就容易出来了。”易贵说。
在广播层，我们的定位是介于终端层和服务层之间的终端差异化系统。将广播层的一般服务分离为微服务，下沉到服务层。按照功能，服务分为各种服务系统，如开播、取字符串、播放页面信息、列表等。然而，如何在将各端的广播层合并为一个公共层后，优雅地实现多端多版本的差异化适配成为当务之急。易贵还说，这也是这次演讲的重点。
上面提到的新架构，其实就是BFF架构，为前端而存在的后端中间层。在传统的前端分离应用中，前端直接调用后端服务，后端服务进行业务逻辑处理。那么引入BFF后，前端会直接和BFF通信，BFF通过API和服务层通信，所以本质上BFF更像是一个“中间层”服务。BFF要实现多端多版本的差异化适配，有以下适配要求。
第一，聚合。对于客户端来说，HTTP请求是非常昂贵的，所以为了减少请求的数量，前端一般倾向于将相关的数据API合并为一个。
第二，剪裁，不同屏幕尺寸的差异等。，导致具有相同接口的客户端所需的响应结果大小不同。
第三，适应。不同的客户端对后端响应结果名称有不同的要求。
那么，具体的聚合、裁剪、适配是如何实现的呢？
易贵说，经过研究，选择了为API而生的高性能查询语言GraphQL。Graph作为一种API查询语言，专门用来处理已有服务接口的响应结果。它已经被脸书、网飞和GitHub使用。例如，Gui介绍了“获取视频信息的界面。GraphQL分为服务器端描述数据部分。我们在回放层定义了视频类型数据，有vid、videoName、序列号等字段，同时GraphQL会将描述的数据与后端微服务接口关联起来，指定哪个服务的哪个接口会返回视频类型数据。客户端根据需求请求播放一层定义好的视频类型数据，比如获取一个vid为10000的视频，只需要videoName字段。此时播放一层给客户端的响应内容只有视频名称信息。”
GraphQL不是一种编程语言，而是一种API查询规范。它的结构是三层结构，其中顶层的QuerySchema是客户端按需请求的接口数据内容，可以裁剪和适配服务器端描述数据的DataSchema。中间数据模式用于描述服务器端的数据。最底层的DataFetcher是静态数据、DB、第三方接口等的包装器。
然后易贵介绍:“以上是对GraphQL的初步了解，那么GraphQL是如何实现聚合的呢？它是通过多个服务接口进行数据聚合，裁剪掉冗余信息，定制响应内容，以及GraphQL的高性能，即DataLoader，一个并发获取数据和N+1个问题的解决方案。”
对于客户端来说，HTTP请求是非常昂贵的，所以为了减少请求的数量，前端一般倾向于将相关的数据API合并为一个。比如视频类型的数据，客户端期望返回视频的基本信息，同时也返回播放次数的信息。在服务器的描述数据Video中添加playCount字段来标识视频播放的次数。同时，playCount绑定到播放次数服务的接口。当客户端请求视频数据时，还增加了playCount字段，使得服务器响应的视频数据聚合了视频的基本信息和播放次数。
那如何实现剪裁呢？如果有客户端在获取视频信息时不需要serialno设置号字段，那么当客户端请求时，可以去掉serialno设置号字段，服务器响应的视频类型数据没有serialno字段。如果客户端需要响应的视频名称不是VideoName而是vname，那么客户端请求将视频名称重命名为vname，服务器响应的视频类型数据中的视频名称字段为vname。
GraphQL引擎不仅灵活，而且通过将查询策略指定为AsyncExecutionStrategy，可以实现多个DataFetcher的并发执行，从而提高性能。比如QuerySchema在获取视频信息时，还需要获取播放次数和明星名单。GraphQL引擎获取视频信息后，会同时请求播放次数和明星列表。“虽然GraphQL很灵活，但它也有固有的缺陷。比如获取视频列表的接口，每个视频都需要返回它的明星列表。所以我们可以通过FaceBook的DataLoader解决N+1的问题。DataLoader支持通过缓存删除重复请求，并在重复数据删除和合并后批量处理请求。”易贵说。
最终，GraphQL提供了如此丰富的功能，以至于可以非常轻松地玩一层来实现业务差异化。易贵介绍:“页面显示时，视频播放页面显示列表时，是在播放技术和收藏，如左图所示。有不同的使用场景，所以对同样的数据有不同的关注点。我们可以很容易地实现这些功能。GraphQL让玩一层应用不再复杂。”
基于GraphQL的通用层在微服务下是什么样子的？这就涉及到第四部分——配置就是接口，你值得拥有。"我们已经实现了在配置之后向客户端提供新界面的目标."易贵说。
播放层基于Graphql-java开发，分为三个部分。QuerySchema部分是访问层，它管理QuerySchema配置。支持客户端传入的QuerySchema，也可以根据客户端传入的代码或请求路径和参数，通过规则映射到QuerySchema。而DataSchema部分是每个服务返回的数据的图形化组织，用于服务器描述数据。
最后，DataFetcher是下游服务的抽象层，可以配置域名、接口地址、请求参数、响应结果等。每种业务，并配备了熔断，容错和降级等功能。易贵介绍:“一楼玩这三个部分，因为主体是配置文件。因此，只需修改配置，就可以在现有微服务的基础上开发新的接口。”
在演讲的最后，易规提出，当一般的层算法固定，只有配置变化的时候，和我们的边缘加速能擦出什么样的火花？
最后，易贵表示，期待与业界伙伴深入交流，获得先进技术的意见。
