低代码、中台化：爱奇艺号微服务工作流实践

背景

微服务从诞生到现在，经历了很长时间。期间不同公司，不同的团队有各自独特的见解，但慢慢对于微服务的各个方面的理解，如服务发现一致性、容错、事务、熔断、降级、配置等等趋于一致。随着微服务在团队中应用，服务的划分越来越细致，单个服务的职责简单清晰，服务易于维护。微服务化确实给团队带来非常大的好处，同时微服务也会带来一些问题。  

       

1. 单个服务逻辑简单，职责清晰，但从整体上来讲，业务的复杂度是没有消失的，那业务的复杂度去哪里了？没错！就是服务间的直接或间接调用。业务逻辑如果很复杂，服务之间调用链路将变得很长，梳理服务之间的调用关系就成了很复杂的事情，代码同样会变得难以维护，新同学的业务学习成本依旧很高。

2. 微服务带来了额外的复杂度，服务发现，一致性，分布式事务等问题在单体应用的时代是不存在的。即便随着微服务的发展，这些功能封装的那么完整，服务中也会出现大量的模板引用，模板代码，增加了开发的成本，为了解决这个问题，服务网格出现了，服务网格将大量公用的复杂度封装在边车中，使开发人员专注于编写业务代码。那么在现有的解决方案中能否更近一步，使开发人员尽量的少些代码呢？

综上所述，如何以尽量少的代码，清晰地体现复杂的业务逻辑呢？在调研了很多方案后，最终将目光锁定在Knative上，基于Knative构建一个Serverless工作流平台将完美的解决上述问题。

Knative简介

Knative是由Google在2018年Google Cloud Nnext大会上发布的K8S sServerless框架，目前由Red Hat、Google、IBM、Pivotal 等多家公司共同维护。Knative拓展了K8S，在K8S和Istio基础上，Knative抽象了云服务通用功能服务部署，灰度等，使用户不用关心Deployment，Replicaset，Pods，Ingress，Distribution Rule等K8S，Istio的概念，从而专心于业务开发，K8S，Istio内部组件的整合则由Knative来实现。因此Knative本质上是以用户为角度，解决服务端构建，部署，应用管理等问题。整体架构如下图：

图片引用自knative官网

Knative模块构成

• Build 负责项目的CICD，已迁移到Tekton中，在此不做过多介绍

• Serving 负责severless应用和方法的部署

• Eventing 负责事件的发布订阅以及基于发布订阅产生的衍生产品

Serving主要组成

• Service，Service是应用的抽象，负责整个应用的生命周期以及其他模块的创建管理，例如Route，Configuration等

• Route，