1.1.11 现状与局限

Serverless现状与局限

当前国内的很多公司也在尝试Faas或者Serverless架构，不过可以猜测出大家或多或少都心存疑虑或者有不放心之感，不敢真正的放上自己的线上服务。
目前看来，虽然Serverless市面上都吹的很火，但实际落地的寥寥可数，星星点点的一些火花，还是难以形成燎原之势。Serverless这片土地十分辽阔，但是各大云厂商却都是在自己和自己过家家，至于其他人怎么玩的，就不怎么关心了。
所以，目前一个很大的问题就是我们在一家函数计算平台跑了自己的服务之后，基本上就和这个平台绑定了，特别是如果你还用到Eventing，由于都是基于平台内部特定的事件触发机制，迁移成本还是比较高的。
终极原因，目前还没有一个强势而大一统的框架和平台，可以让大家甘愿臣服。想当年，容器编排领域兴起，Kubernetes和Mesos大战，两边各自有人站队，云厂商也各自押宝，如今Kubernetes一统江湖，大家都默默的建立起了基于Kubernetes的容器云平台，于是围绕着Kubernetes的云原生生态蓬勃发展。由于没有统一的平台，针对Serverless目前还存在的一些局限，大家做的优化和改进也是各自为战，难以落地生根。

实现：Knative

Knative是某厂商开源的Serverless架构方案，旨在提供一套简单易用的Serverless平台，把Serverless 标准化。Knative不局限于Faas，而是期望能够运行所有的无状态工作负载。像其他绝大部分的Faas或者Serverless平台一样，Knative也是基于Kubernetes，不过，Knative还基于Istio或者Gloo网关等实现流量的分发和管理。

还在不久之前，Knative分为三个组件：

• Build
• Serving
• Eventing

Build负责将代码转换成我们需要的容器镜像，Serving则是提供Serverless的运行方式，Eventing则致力于提供标准化的事件触发机制。
不过，现在Build模块已经被弃用，被由Build的设计思路而发起的Tekton项目替换（参考：《Kubernetes原生CI/CD工具：Tekton探秘与上手实践》）。当然你也可以使用其他合适的CI/CD工具替代。
Serving模块主要做的工作本质上就两个：

• 流量入口的自动创建和管理

以基于istio为例，Knative自动创建istio的ingressgateway，服务的service等，将流量导入新部署的服务，而不需要手动的创建各种service，ingress暴露服务和流量入口。同时，将不同版本对应不同的deployment，可以方便的实现蓝绿、灰度等发布部署方式。如下图所示：

• 冷启动和自动扩缩容

Knative有自身基于流量请求算法的metric自动扩缩容（KPA）的方式，也支持Kubernetes原生的HPA实现自动扩缩容。同时，在服务缩容为0之后，Serving会将服务流量路由到冷启动的组件，缓存请求，然后扩容服务，再将流量导入启动后的服务副本。
Knative Eventing则联合 CNCF Serverless WG制定一套事件格式规范并推广：Knative Eventing与CNCF Serverless WG制定的事件格式规范只需要各个云厂商都按照这个规范，我们的Serverless服务就可以进行跨平台的事件触发，也不会被特定的云厂商绑定。