原文作者：kaiyun開云創(chuàng)新CEO 馬洪喜
啥是函數(shù)編程
我先用通俗的大白話給大家解釋一下函數(shù)(Functions, Function as a Service, FaaS)的幾個(gè)要點(diǎn)，這樣看后面示例時(shí)才不會(huì)容易懵。
· 函數(shù)就是在云平臺體系內(nèi)運(yùn)行的、與云平臺融合一體的一段程序邏輯（當(dāng)然也有鏡像什么的其他形態(tài)）。
· 通過云平臺本身能力，在HTTP事件或是云平臺其他事件（如：消息隊(duì)列有新消息時(shí)）發(fā)生時(shí)，函數(shù)會(huì)被云平臺調(diào)度執(zhí)行。
· 函數(shù)的運(yùn)行實(shí)例（理解為進(jìn)程或是容器POD）的數(shù)量可以配置，在無負(fù)載時(shí)甚至可以是0，負(fù)載到來時(shí)云平臺會(huì)Auto-Scale函數(shù)。
其他大理論再講就枯燥了，不如先在實(shí)際環(huán)境看看函數(shù)編程長啥樣。
我們看看微軟Azure云上的函數(shù)產(chǎn)品的設(shè)計(jì)思路。
在Azure云上函數(shù)產(chǎn)品叫 Function App。創(chuàng)建一個(gè)Function App如下，我們選擇采用Python編碼：
在Function App的上下文菜單內(nèi)，創(chuàng)建一個(gè)function，選擇HTTP Trigger，當(dāng)你函數(shù)對應(yīng)域名收到HTTP事件（GET,POST,UPDATE,DELETE）時(shí)函數(shù)會(huì)被執(zhí)行，同時(shí)我們看到有大量的其他非HTTP事件可以訂閱，比如：定時(shí)器執(zhí)行函數(shù)或是每當(dāng)消息被添加到RabbitQ時(shí)運(yùn)行的函數(shù)等：
然后進(jìn)入函數(shù)編碼階段。這里我已經(jīng)做了很多簡化，本來是一大堆代碼可以通過上下文來判斷HTTP請求類型什么的，但其主體邏輯僅僅是一個(gè)def main函數(shù)：
其運(yùn)行效果如下：
我們再來看看阿里云的產(chǎn)品，函數(shù)計(jì)算FC。
我們先創(chuàng)建一個(gè)函數(shù)，就用最簡單的模式吧，主要我們還是關(guān)注云平臺上函數(shù)相關(guān)產(chǎn)品的設(shè)計(jì)思路：
函數(shù)本身的代碼是可以支持許多不同語言的，提供的示例代碼讓我們體驗(yàn)函數(shù)功能就非常方便：
這里有個(gè)觸發(fā)器，我們先試試HTTP觸發(fā)，大家看到阿里云做的比較細(xì)膩，還可以訂閱具體的HTTP請求方法，比如：只有在HTTP GET時(shí)才觸發(fā)函數(shù)，這比只是在函數(shù)體內(nèi)邏輯加以區(qū)分多了一個(gè)選擇。
然后就進(jìn)入云端IDE看函數(shù)的代碼了，我們可以看到全部的代碼真的只是一個(gè)函數(shù) def handler，函數(shù)的內(nèi)容就是對我們之前設(shè)置的HTTP事件做出響應(yīng)。
通過云平臺提供的URL訪問函數(shù)時(shí)，我們可以得到預(yù)期的返回結(jié)果（阿里云平臺遵守相關(guān)規(guī)定，在沒有綁自己的域名時(shí)，會(huì)強(qiáng)制以附件形式下載）：
通過前述示例，我們可以看到函數(shù)本身真的就是一個(gè)程序里的函數(shù)(def handler)，把函數(shù)寫好了，其他的諸如：①引入庫、開端口什么的框架代碼；②HTTP和其他平臺事件的接管、對接；③程序?qū)嵗旧淼倪\(yùn)行和程序容量的管理等，都不需要再操心了，因?yàn)樵破脚_本身幫我們?nèi)扛愣ā?
因此，大家可以看到函數(shù)產(chǎn)品有至少如下的兩點(diǎn)好處：
· 把編程從原來的作文題變成了填空題，極大程度地簡化了我們對于代碼的編寫工作。讓我們關(guān)注于業(yè)務(wù)邏輯本身，其他的不用過多操心，而且通過云平臺的包括云端IDE能力，讓函數(shù)的編寫和調(diào)試更加方便；
· 原來，可能存在大量的平時(shí)沒有什么訪問量的業(yè)務(wù)，但不得不還得跑上幾個(gè)虛擬機(jī)或是容器干等著，以備偶然少量的訪問；而突如其來的大業(yè)務(wù)量又讓我們的Scale能力跟不上，這個(gè)資源上的尷尬局面，函數(shù)可以很好地加以解決——沒有訪問量時(shí)實(shí)例數(shù)可以縮小到0（或是你指定的一個(gè)值），而有了訪問量平臺可以自動(dòng)并快速地Scale函數(shù)。
但也要注意，當(dāng)決定使用函數(shù)時(shí)有以下的不利因素也需要考慮清楚：
· 函數(shù)和云平臺深度耦合，離開云平臺函數(shù)不能再獨(dú)立運(yùn)行；
· 不同云平臺的函數(shù)產(chǎn)品完全不一致，你在A云上的函數(shù)代碼到B云上不能運(yùn)行；
· 如果不是新業(yè)務(wù)場景，已有代碼邏輯需要大幅度改動(dòng)才能適配函數(shù)（除非以鏡像形態(tài)只享受云平臺帶來的資源管理優(yōu)勢）；
· 函數(shù)不是萬能的，有些復(fù)雜的場景函數(shù)不一定是合適的選擇。
云平臺是如何工作以支持函數(shù)的
前面咱們介紹的函數(shù)本身背景，大伙會(huì)明白云平臺本身對函數(shù)來說極為重要，離開了云平臺函數(shù)就不能工作了。那這一節(jié)我們一起聊聊云平臺本身是如何支持函數(shù)運(yùn)行的，我相信這對于希望在私有云建設(shè)函數(shù)能力的朋友們會(huì)有些借鑒意義。
問題一：關(guān)于函數(shù)本體和運(yùn)行他所需的代碼框架
我們都知道原來寫一個(gè)最簡單的HTTP響應(yīng)也得用Flask之類的庫, 前后代碼把函數(shù)框成一個(gè)完整的代碼，程序才能跑得起來：
但為什么函數(shù)編程真的只有一個(gè)函數(shù) def handler 就能運(yùn)行呢？這不科學(xué)啊。其實(shí)他也沒那么神秘。云平臺本身是通過一個(gè)function-framework 或是叫bootstrap的框架把函數(shù)包起來，還是一個(gè)運(yùn)行在容器里的完整的應(yīng)用程序來執(zhí)行的。不同云平臺或是不同語言的實(shí)現(xiàn)方式可能有所不同，比如采用代碼合成或是反射機(jī)制等。這里我們可以看看Google的一套開源實(shí)現(xiàn)：
所以這樣的一套框架相當(dāng)于把作文中開頭、結(jié)尾給寫好了，只要遵循他，把填空內(nèi)容弄好，則最后的結(jié)果，還是一個(gè)我們可以理解的、完整的程序代碼實(shí)現(xiàn)，然后云平臺再一起把他們打包運(yùn)行。
恰恰是從包裹函數(shù)的framework或是bootstrap就各家實(shí)現(xiàn)不一了，所以函數(shù)的跨云兼容性可能是個(gè)阻礙用戶選擇函數(shù)的重要原因。因此，行業(yè)有一些開源項(xiàng)目，在努力形成不同云上的統(tǒng)一函數(shù)的使用方法（使用標(biāo)準(zhǔn)還遠(yuǎn)遠(yuǎn)談不上），大家可以參考看看。
問題二：HTTP事件和平臺事件的管理和與函數(shù)對接
因?yàn)榍懊嬉呀?jīng)通過framework或是bootstrap包裹技術(shù)實(shí)現(xiàn)了函數(shù)的運(yùn)行，基本上他表達(dá)的就是一個(gè)HTTP形態(tài)的API。通過云平臺提供的域名接入或是私有云的Ingress-Controller或是其他類似的機(jī)制把域名綁起來，然后把對應(yīng)的域名的HTTP事件和函數(shù)觸發(fā)綁起來，這個(gè)不太難。但云平臺上的其他事件就千奇百態(tài)，云平臺上不同的產(chǎn)品的不同事件，理論上都應(yīng)該可以觸發(fā)函數(shù)，那么有的云平臺內(nèi)部產(chǎn)品（如：數(shù)據(jù)庫、中間件、AI、大數(shù)據(jù)）豐富一些，那自然函數(shù)的用武之地也更多；而如果有些云平臺本身的產(chǎn)品就比較少，即便提供了函數(shù)編程產(chǎn)品，其適用場景也有一定局限性。
問題三：函數(shù)的運(yùn)行實(shí)例是如何管理和Scale的
即然函數(shù)是可以0實(shí)例存在（此時(shí)不產(chǎn)生云平臺費(fèi)用），也可以在流量到達(dá)時(shí)快速響應(yīng)， 我相信容器技術(shù)會(huì)扮演一個(gè)重要的角色?；蛟S更具體地說，可能用到了Knative技術(shù)。Knative是繼Kubernetes之后在云原生領(lǐng)域眾多新興技術(shù)之一，我和我和團(tuán)隊(duì)關(guān)注Knative非常的早。用他官網(wǎng)的定義來說：“Knative is a platform-agnostic solution for running serverless deployments.”
似乎看了和沒看一樣，我個(gè)人對Knative的研究沒有我行云的同事們那么精通，我的粗糙理解就是三個(gè)事：
· (Serving) Kubernetes 上實(shí)現(xiàn)對實(shí)例更精細(xì)的scaling管理，可以支持0實(shí)例等，這個(gè)能力原來標(biāo)準(zhǔn)的K8s HPA是做不到的，區(qū)別行業(yè)管Knative的scaling能力叫KPA
· (Eventing) 事件管理機(jī)制，Knative引入了標(biāo)準(zhǔn)，來通過CRD等能力擴(kuò)展Kubernetes 實(shí)現(xiàn)對事件的管理。
· (Building) 就是簡單理解為Kubernetes上實(shí)現(xiàn)了CICD，就是Tekton技術(shù)。
小結(jié)
今天和大伙簡單聊聊函數(shù)編程FaaS是怎么回事，并且從其工作原理角度進(jìn)行了些許闡述。后面我會(huì)從私有云平臺建設(shè)函數(shù)編程能力來分享幾個(gè)話題：
· 眾多FaaS開源項(xiàng)目的發(fā)展如何，作何選擇？
· Knative技術(shù)和你已有的PaaS平臺如何融合？
· 最為關(guān)鍵的是，你的企業(yè)真的需要建設(shè)函數(shù)能力嗎？
· 那么，函數(shù)在私有云里最有意義的落地場景是什么？
對這些話題感興趣的朋友們，“深圳kaiyun開云創(chuàng)新”公眾號等你來撩，后續(xù)我們將持續(xù)為您分享更多云原生干貨。
如果您有有任何好的建議，或是想了解的議題也請留言告訴我們。云原生時(shí)代，行云與您攜手前行……
添加kaiyun開云創(chuàng)新CEO馬洪喜微信，一起聊聊云原生吧……
讓企業(yè)都能高效創(chuàng)新
企業(yè)云原生數(shù)字化創(chuàng)新平臺CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發(fā)者專屬一站式在線服務(wù)Methodot
