使用Knative作为API聚合层的实践

作者：高松

前言

在2019年的今天，微服务这个词相信对于绝大多数的开发者都已经不再陌生。时至今日，非常多的项目都逐渐开始实践起微服务这一设计思想，将原本的磐石应用逐渐按照领域模型切分成一个个小的服务，对于微服务的实践也日渐趋向于成熟。在笔者目前工作的业务实践中，同样也使用着微服务作为后端服务的架构设立思想，微服务为我们的代码管理与项目管理带来了非常大的简便性。然而随着需求的迭代与代码的日益积累，曾经泾渭分明、代码精简的各个微服务也逐渐开始变得逻辑复杂、代码冗余，同时每个微服务之间又似乎存在着剪不断理还乱的关系。2019年是Serverless蓬勃发展的一年，作为Serverless领域的中的明星产品，Knative在今年8月份发布了0.8版本，其中Serving组件的0.8版本在笔者看来才真正达到了可用的程度。本篇文章将介绍笔者是如何使用Knative来作为API聚合层，来解决我们在实践微服务中所遇到的问题的。

微服务迭代之痛

在笔者目前的工作实践中，我们在架构设计中严格遵循着微服务的设计理念。每块业务上独立的领域作为一个微服务，每个微服务有自己单独的数据库。任何一个微服务只能读写自己的数据库，而绝对不能干涉其他微服务的数据库，所有微服务之间获取信息都是通过http协议进行通信。在业务初期时，由于产品处于雏形中，所有服务的接口在逻辑上都比较简单，大部分接口都可以看做各自领域模型上的增删改查形态，服务与服务之间的调用也并不密集频繁。随着业务的持续发展与产品的迭代，大大小小、许许多多的功能需求交织重叠在一起，相应的各个服务直接服务于需求的接口也逐渐变多，每个接口越来越“需求相关”。并且我们逐渐发现随着需求的逐渐复杂，每个接口涉及的服务也越来越多，很难有一个强有力的理由去确定这个接口就必须放在某个服务里。这个时候将这个接口放在哪个服务里面，往往取决于做这个需求的开发对哪个服务的掌控力更强，或者说这个接口看上去更倾向于哪块业务领域。同时由于大大小小的“需求相关”的接口越来越多的堆积在各个微服务内以后，整个服务仓库的代码量逐渐增大，代码质量也逐渐下降、微服务仿佛变得不再那么“微”。

Serverless

Serverless，又或者说无服务器、Faas，几乎是2019年内整个云原生领域甚至是整个互联网技术圈领域内呼声最旺的关键字。当然Serverless并非只是在2019年才开始出现相关的技术，早在2014、2015年的时候，AWS就已经在各个文章、博客渠道上就已经开始宣传与推广自家的AWS Lambda服务了。当然，在如今2019年，国内的各个云服务厂商也都已经开始提供了成熟的Serverless产品，整个云原生开源社区内各个Serverless产品技术也逐渐走向成熟，同时Serverless这一技术落地的场景比起过去几年也越来越清晰、边界也越来越广。如同今年Kubecon上越来越多关于Serverless的议题一样。以及针对Serverless落地的技术分享也越来越多，这块笔者听到的最多的就是关于前端领域和Serverless结合的落地分享了。而在许多开源的Serverless产品中，最饱受关注的莫过于Knative了。而在今年8月份，Knative也终于发布了0.8版本，虽然这依然还不是一个生产就绪版本，但是0.8版本在API、稳定性上已经“几乎”可以认为是一个生产就绪版本了。这其中最关键的就是Knative Serving组件的更新了，可以说在Knative Serving 0.7及其之前的版本，这个组件都一直处于一个“几乎”可用的状态，有着不少令人困扰的小bug。好在这些许多影响正常使用的bug都最终在Knative Serving 0.8版本中被修复了。

Serverless在API聚合层的尝试

Api聚合层，第一次听到这个名词依旧也是在今年前端领域的技术分享中。相应的、API聚合层在前端领域中也有个专门的名词叫做BFF，即Backend For Frontend。在这一块，国内已经有过不少BFF与Serverless结合的的分享。可以说BFF与Serverless的结合即解决了在前端领域中，多端适配、又或者是UI模型与后端API数据的转化这一系列问题，同时也没有引入多余的维护服务稳定性以及服务治理等一系列额外的运维负担。

那么，既然在前端场景中可以有API聚合层，在后端服务的场景中是否也可以引入API聚合层这一个概念？既然在目前的微服务中，许多直接服务于需求、业务，并且在整个请求链路周期内会跨越许多微服务的API难以定位应该放在哪个微服务里，那么倒不如将思维逆转过来，对于这些“无处安放”的API，我们就干脆不把他们放在任何一个服务上，我们用Serverless去支持这些API，使得这些API一直以独立的函数单元存在。这样就让每个后端微服务的定位更加“靠后”，每个微服务提供的API，用如今一个比较流行的词来形容就是更加“中台化”，更加领域相关，更加的可复用化，而不再是直接面向需求，难以复用的接口。让Serverless去承载那些直接面向需求的接口，直接接受来自客户端的请求，然后通过调用更加“靠后”的微服务接口，来将各个API聚合在一起进行处理，最终返回给客户端。

<