云原生集成开发环境——TitanIDE
通过网页在任何地方更安全、更高效地编码2023-01-30
777
原文作者:kaiyun开云创新CEO 马洪喜
啥是函数编程
我先用通俗的大白话给大家解释一下函数(Functions, Function as a Service, FaaS)的几个要点,这样看后面示例时才不会容易懵。
· 函数就是在云平台体系内运行的、与云平台融合一体的一段程序逻辑(当然也有镜像什么的其他形态)。
· 通过云平台本身能力,在HTTP事件或是云平台其他事件(如:消息队列有新消息时)发生时,函数会被云平台调度执行。
· 函数的运行实例(理解为进程或是容器POD)的数量可以配置,在无负载时甚至可以是0,负载到来时云平台会Auto-Scale函数。
其他大理论再讲就枯燥了,不如先在实际环境看看函数编程长啥样。
我们看看微软Azure云上的函数产品的设计思路。
在Azure云上函数产品叫 Function App。创建一个Function App如下,我们选择采用Python编码:
在Function App的上下文菜单内,创建一个function,选择HTTP Trigger,当你函数对应域名收到HTTP事件(GET,POST,UPDATE,DELETE)时函数会被执行,同时我们看到有大量的其他非HTTP事件可以订阅,比如:定时器执行函数或是每当消息被添加到RabbitQ时运行的函数等:
然后进入函数编码阶段。这里我已经做了很多简化,本来是一大堆代码可以通过上下文来判断HTTP请求类型什么的,但其主体逻辑仅仅是一个def main函数:
其运行效果如下:
我们再来看看阿里云的产品,函数计算FC。
我们先创建一个函数,就用最简单的模式吧,主要我们还是关注云平台上函数相关产品的设计思路:
函数本身的代码是可以支持许多不同语言的,提供的示例代码让我们体验函数功能就非常方便:
这里有个触发器,我们先试试HTTP触发,大家看到阿里云做的比较细腻,还可以订阅具体的HTTP请求方法,比如:只有在HTTP GET时才触发函数,这比只是在函数体内逻辑加以区分多了一个选择。
然后就进入云端IDE看函数的代码了,我们可以看到全部的代码真的只是一个函数 def handler,函数的内容就是对我们之前设置的HTTP事件做出响应。
通过云平台提供的URL访问函数时,我们可以得到预期的返回结果(阿里云平台遵守相关规定,在没有绑自己的域名时,会强制以附件形式下载):
通过前述示例,我们可以看到函数本身真的就是一个程序里的函数(def handler),把函数写好了,其他的诸如:①引入库、开端口什么的框架代码;②HTTP和其他平台事件的接管、对接;③程序实例本身的运行和程序容量的管理等,都不需要再操心了,因为云平台本身帮我们全部搞定。
因此,大家可以看到函数产品有至少如下的两点好处:
· 把编程从原来的作文题变成了填空题,极大程度地简化了我们对于代码的编写工作。让我们关注于业务逻辑本身,其他的不用过多操心,而且通过云平台的包括云端IDE能力,让函数的编写和调试更加方便;
· 原来,可能存在大量的平时没有什么访问量的业务,但不得不还得跑上几个虚拟机或是容器干等着,以备偶然少量的访问;而突如其来的大业务量又让我们的Scale能力跟不上,这个资源上的尴尬局面,函数可以很好地加以解决——没有访问量时实例数可以缩小到0(或是你指定的一个值),而有了访问量平台可以自动并快速地Scale函数。
但也要注意,当决定使用函数时有以下的不利因素也需要考虑清楚:
· 函数和云平台深度耦合,离开云平台函数不能再独立运行;
· 不同云平台的函数产品完全不一致,你在A云上的函数代码到B云上不能运行;
· 如果不是新业务场景,已有代码逻辑需要大幅度改动才能适配函数(除非以镜像形态只享受云平台带来的资源管理优势);
· 函数不是万能的,有些复杂的场景函数不一定是合适的选择。
云平台是如何工作以支持函数的
前面咱们介绍的函数本身背景,大伙会明白云平台本身对函数来说极为重要,离开了云平台函数就不能工作了。那这一节我们一起聊聊云平台本身是如何支持函数运行的,我相信这对于希望在私有云建设函数能力的朋友们会有些借鉴意义。
问题一:关于函数本体和运行他所需的代码框架
我们都知道原来写一个最简单的HTTP响应也得用Flask之类的库, 前后代码把函数框成一个完整的代码,程序才能跑得起来:
但为什么函数编程真的只有一个函数 def handler 就能运行呢?这不科学啊。其实他也没那么神秘。云平台本身是通过一个function-framework 或是叫bootstrap的框架把函数包起来,还是一个运行在容器里的完整的应用程序来执行的。不同云平台或是不同语言的实现方式可能有所不同,比如采用代码合成或是反射机制等。这里我们可以看看Google的一套开源实现:
所以这样的一套框架相当于把作文中开头、结尾给写好了,只要遵循他,把填空内容弄好,则最后的结果,还是一个我们可以理解的、完整的程序代码实现,然后云平台再一起把他们打包运行。
恰恰是从包裹函数的framework或是bootstrap就各家实现不一了,所以函数的跨云兼容性可能是个阻碍用户选择函数的重要原因。因此,行业有一些开源项目,在努力形成不同云上的统一函数的使用方法(使用标准还远远谈不上),大家可以参考看看。
问题二:HTTP事件和平台事件的管理和与函数对接
因为前面已经通过framework或是bootstrap包裹技术实现了函数的运行,基本上他表达的就是一个HTTP形态的API。通过云平台提供的域名接入或是私有云的Ingress-Controller或是其他类似的机制把域名绑起来,然后把对应的域名的HTTP事件和函数触发绑起来,这个不太难。但云平台上的其他事件就千奇百态,云平台上不同的产品的不同事件,理论上都应该可以触发函数,那么有的云平台内部产品(如:数据库、中间件、AI、大数据)丰富一些,那自然函数的用武之地也更多;而如果有些云平台本身的产品就比较少,即便提供了函数编程产品,其适用场景也有一定局限性。
问题三:函数的运行实例是如何管理和Scale的
即然函数是可以0实例存在(此时不产生云平台费用),也可以在流量到达时快速响应, 我相信容器技术会扮演一个重要的角色。或许更具体地说,可能用到了Knative技术。Knative是继Kubernetes之后在云原生领域众多新兴技术之一,我和我和团队关注Knative非常的早。用他官网的定义来说:“Knative is a platform-agnostic solution for running serverless deployments.”
似乎看了和没看一样,我个人对Knative的研究没有我行云的同事们那么精通,我的粗糙理解就是三个事:
· (Serving) Kubernetes 上实现对实例更精细的scaling管理,可以支持0实例等,这个能力原来标准的K8s HPA是做不到的,区别行业管Knative的scaling能力叫KPA
· (Eventing) 事件管理机制,Knative引入了标准,来通过CRD等能力扩展Kubernetes 实现对事件的管理。
· (Building) 就是简单理解为Kubernetes上实现了CICD,就是Tekton技术。
小结
今天和大伙简单聊聊函数编程FaaS是怎么回事,并且从其工作原理角度进行了些许阐述。后面我会从私有云平台建设函数编程能力来分享几个话题:
· 众多FaaS开源项目的发展如何,作何选择?
· Knative技术和你已有的PaaS平台如何融合?
· 最为关键的是,你的企业真的需要建设函数能力吗?
· 那么,函数在私有云里最有意义的落地场景是什么?
对这些话题感兴趣的朋友们,“深圳kaiyun开云创新”公众号等你来撩,后续我们将持续为您分享更多云原生干货。
如果您有有任何好的建议,或是想了解的议题也请留言告诉我们。云原生时代,行云与您携手前行……
添加kaiyun开云创新CEO马洪喜微信,一起聊聊云原生吧……