通常我们认为Serverless包含两个部分，FaaS和BaaS，本次主要讲的是FaaS部分。
什么是Serverless
通常我们认为Serverless包含两个部分，FaaS和BaaS，本次主要讲的是FaaS部分。
Serverless作为无服务架构，有几个最基本的特点。首先是 无需关心底层基础设施，开发者无需考虑扩展和网络方面的问题；由于它的部署单位是function，使得开发者无需关心运行实例和容器，减少了应用部署时间；可以做到按需运行，实现细粒度的成本控制。
Serverless带来的好处是显而易见的，这主要涉及公有云和私有云两种场景。公有云上的Serverless可以有效减少复杂度，运维开销、代码部署时间等。很多公有云厂商都提供相应的服务，让开发者无需管理操作系统，也不用构建容器，仅需为运行中的function付费，代码push之后不用关心后续的运维问题。
不过公有云提供的FaaS平台的问题在于标准不一致，会造成在A服务商平台上写的代码在B服务商平台上无法运行。 这对于初创企业来说可能影响不大，但有一定规模的企业应该会想要更多的选择自主权，而非限定于特定服务商，在私有云平台上搭建自己的FaaS平台是更优的方案。
Serverless in kubernetes
当前流行的开源FaaS平台有OpenFaas、Kuberless、Fission、openWhisk，Knative。这些项目大多是在2016的时候兴起的，基于kubernetes，因此我们可以认为FaaS的成长很大程度上是伴随着kubernetes的成熟而发展起来的。
Kubeless
Kubeless是基于kubernetes平台上原生的FaaS平台，这主要是因为它大量使用了kubernetes能力，包括auto-scaling、API routing、monitoring等。当前支持的开发语言也有很多，涵盖python、PHP、Nodejs、Ruby、Golang、.net、Java。
基于kubernetes原生能力的设计
kubeless基于kubernetes原生能力的设计包含多个方面：
Kubeless的核心概念
Kubeless的核心概念有三个：Function-被执行的代码、Trigger-触发函数的事件、Runtime-执行函数的语言和运行时环境。
![1]()
上图是一个简单的示例，可以看到构建Function只需要指定function名字和runtime，然后将代码push上去就行了。
有了Function之后就需要和具体的Trigger绑定才能够使用，目前主要有3种Triggers类型：HTTP-通过k8s的Ingress同步触发函数执行；CronJob-通过k8s的CronJob对象定时触发函数执行；PubSub-通过kafka/NAST消息队列异步触发函数执行。
Kubeless的应用维护
![1]()
上图为kubeless官方提供的UI工具，虽然看上去比较简陋，但功能还是够用的，它基本上涵盖了函数创建、函数执行、日志查询、代码修改，足以应付一些小规模测试。
前面提到过FaaS是按需运行的，一般在没有function执行的时候，Runtime会被销毁掉。这归功于k8s的弹性伸缩策略，该策略基于两种metric：CPU和QPS。
![1]()
监控方面FaaS主要关注Call rate、Failure rate、Execution duration这3个指标，通过它们来衡量function，也可以从中看出Kubeless本身的一些运行情况。
关于微服务与function的思考
一般来说FaaS比较适用于事件驱动的应用场景。典型的有Webhook、消息推送、IoT数据采集、定时任务、轻量级API网关、流式事件处理等。
![1]()
将微服务和function进行对比之后，我们可以看到Function是天然的微服务，从它们之间的各种特征来看，微服务的业务粒度划分和function很类似，function可以实现和微服务同样的功能。
从长期来看，FaaS会改变传统软件开发模式，这只是事件长短的问题。我们团队之所以这么关注kubeless，就是因为我们认为它会对未来的软件开发模式有非常大的影响，它可以能有效提高开发效率和代码质量。
微服务化过程是一个逐步演进的过程，无法一蹴而就。
关于微服务和function的部分基本就是以上这些。对于kubeless我们认为它最重要的价值在于提供了企业内部的代码微服务化的一种可选方案，实现了系统层和业务逻辑之间的隔离，让软件开发更贴近其目的的本源。
本文转自掘金-
基于 Kubernetes 的 FaaS 平台开源实现——Kubeless 的应用实践
