Martin Fowler最近非常推崇的serverless架構(gòu)模式粪般，是BaaS云架構(gòu)實現(xiàn)的核心架構(gòu)模式小作。

Martin Fowler在2016.6.17號發(fā)表了一篇博客： 《Serverless Architectures》,引起業(yè)界廣泛關(guān)注：
在這篇博客里，他介紹了serverless架構(gòu)滔蝉，以及FaaS矫夯，Microservice综液，Docker等流行的架構(gòu)和概念井誉，描述了Amazon AWS lambda的價值， 進(jìn)一步將這種云時代的架構(gòu)清晰的展現(xiàn)在大家的視野里祠丝。

__ 本文很多內(nèi)容來自這篇博客，讓大家清晰了解Martin對serverless架構(gòu)的概念和價值的闡述除嘹。__ 在此基礎(chǔ)上我按照模式的講解思路將進(jìn)一步闡述我個人對Serverless架構(gòu)和BaaS之間的關(guān)系，以及后續(xù)的發(fā)展。

sketch

概念(Concept)

Serverless是最新興起的架構(gòu)模式更啄，中文意思是“無服務(wù)器”架構(gòu)。跟很多其它軟件類似居灯，對Serverless還沒有清晰定義义锥，但是肯定有兩個互相有重疊的定義：

1. Serverless最初是用于描述依賴第三方服務(wù)（‘云端’）實現(xiàn)對邏輯和狀態(tài)進(jìn)行管理的應(yīng)用柳沙。典型的包括“富客戶端”（例如單頁Web應(yīng)用、移動應(yīng)用）拌倍，
他們一般都使用基于云端的數(shù)據(jù)庫（例如Parse赂鲤、Firebase），認(rèn)證服務(wù)（Auth0柱恤、AWS congnito）等数初。
這類服務(wù)以前被稱為“（Mobile） backend as a Service （https://en.wikipedia.org/wiki/Mobile_backend_as_a_service）”，我將在本文中稱他們?yōu)椤癇aaS”梗顺。

2. Serverless也可以指這樣的應(yīng)用泡孩，一部分服務(wù)邏輯由應(yīng)用實現(xiàn)，但是跟傳統(tǒng)架構(gòu)不同在于寺谤，他們運行于無狀態(tài)的容器中仑鸥，可以由事件觸發(fā)，短暫的变屁，完全被第三方管理眼俊。
（感謝ThoughtWorks在最近Tech Radar中做出的定義）。這種思路是‘Functions as a Service / FaaS’粟关，AWS Lambda是目前最佳的FaaS實現(xiàn)之一疮胖，
本文后續(xù)介紹中將使用FaaS作為這種架構(gòu)的縮寫。當(dāng)開發(fā)Baas shaped應(yīng)用誊役，特別當(dāng)開發(fā)一個富Web應(yīng)用获列，而不是移動應(yīng)用時谷市，你會需要一些服務(wù)器端定制功能蛔垢，
Faas功能也許對于這種情況是一種好的解決方案，特別是如果他們和你使用的BaaS服務(wù)集成到一定程度時迫悠，這樣功能案例包括數(shù)據(jù)校驗和計算敏感的處理鹏漆，比如圖片和視頻的制作。

但是我更愿意討論的是本領(lǐng)域第二種方式创泄，相比來說技術(shù)架構(gòu)更新艺玲，引領(lǐng)了Serverless的很多創(chuàng)新。然而鞠抑，這兩個領(lǐng)域開始融合饭聚，一個例子是Auth0（https://auth0.com/），一開始Auth0是作為Baas（‘Authentication as a Service’）搁拙，但是隨著Auth0 webtask的發(fā)布秒梳，演變成了FaaS應(yīng)用法绵。

更多場合，當(dāng)開發(fā)基于BaaS的應(yīng)用時酪碘，特別當(dāng)開發(fā)基于web的應(yīng)用而不是移動應(yīng)用時朋譬，更需要一部分服務(wù)端功能。特別當(dāng)跟正在使用的BaaS整合在一起時兴垦，F(xiàn)aaS模式可以作為最佳實踐徙赢。這類功能包括數(shù)據(jù)認(rèn)可（以免客戶端惡意攻擊）和計算敏感進(jìn)程（例如圖像或者視頻篡改）。

問題(Problem)：

在目前主流云計算IaaS和PaaS中探越，開發(fā)者進(jìn)行業(yè)務(wù)開發(fā)時狡赐， 仍然需要關(guān)心很多和服務(wù)器相關(guān)的服務(wù)端開發(fā)， 比如緩存钦幔，消息服務(wù)阴汇， web應(yīng)用服務(wù)器， 數(shù)據(jù)庫节槐， 需要對服務(wù)器進(jìn)行性能優(yōu)化搀庶，考慮存儲和計算資源， 考慮負(fù)載和擴展铜异，考慮服務(wù)器容災(zāi)穩(wěn)定性等非業(yè)務(wù)邏輯的開發(fā)哥倔。 這些服務(wù)器的運維和開發(fā)，知識和經(jīng)驗極大的限制了開發(fā)者進(jìn)行業(yè)務(wù)開發(fā)的效率揍庄。 如何讓開發(fā)者無需在服務(wù)器實現(xiàn)和部署服務(wù)咆蒿，而直接租用服務(wù)或者開發(fā)服務(wù)而無需關(guān)注如何在服務(wù)器中運行部署服務(wù)，對開發(fā)者來說蚂子，這是一種去服務(wù)器而直接使用服務(wù)的架構(gòu)沃测。

背景(Context)

服務(wù)端開發(fā)在云計算時代基本是如下趨勢：

Real Server->Virtual Server-> Server with Middlewares -> Service

__ 云計算的發(fā)展從IaaS，PaaS食茎，SaaS蒂破，到最新的BaaS，在這個趨勢中serverless(去服務(wù)器化）越來越明顯别渔。
IaaS將真實的物理機變成了虛擬機附迷， PaaS進(jìn)一步將虛擬機變成了包含基礎(chǔ)設(shè)施的中間件服務(wù)。 BaaS&SaaS將中間件服務(wù)擴展到更基礎(chǔ)的后端能力哎媚。 這些是云計算解決效率很成本的重要體現(xiàn)喇伯。 Serverless這種無服務(wù)器架構(gòu)，用服務(wù)代替服務(wù)器拨与，無需了解落實服務(wù)進(jìn)一步提高云計算的成本和效率稻据，從而為BaaS這種新時代云計算提供架構(gòu)基礎(chǔ)__

限制(Force)

BaaS要被開發(fā)者廣泛接受，需要在云端解決以下的限制：

• BaaS服務(wù)的治理
• BaaS服務(wù)需要提供邏輯定制擴展
• BaaS服務(wù)能力獨立部署买喧，快速啟動
• BaaS服務(wù)可以彈性擴展捻悯，滿足大并發(fā)需要
• BaaS服務(wù)可以被監(jiān)控箩朴，計費
• BaaS服務(wù)要解決DevOps相關(guān)的問題
• ...

解決(Solution)

要實現(xiàn)serverless架構(gòu)， 需要利用以下技術(shù)和方案秋度，

• 實現(xiàn)BaaS中的云代碼特性炸庞， 開發(fā)者可以直接開發(fā)在云端業(yè)務(wù)代碼，實現(xiàn)Functions as a Service荚斯。
• 實現(xiàn)API網(wǎng)關(guān)埠居，對用API代表服務(wù)的入口，并對所有服務(wù)進(jìn)行治理事期。
• 微服務(wù)架構(gòu)技術(shù)滥壕，用微服務(wù)的概念來實施服務(wù)的開發(fā)。
• 利用docker容器技術(shù)部署運行微服務(wù)

典型場景

UI驅(qū)動應(yīng)用

先討論一個帶有服務(wù)功能邏輯的傳統(tǒng)面向客戶端的三層應(yīng)用兽泣，一個典型的電子商務(wù)應(yīng)用（例如在線寵物商店）绎橘。

一般架構(gòu)如圖所示，假如服務(wù)端用Java開發(fā)完成唠倦，客戶端用HTML/Javascript：

640

這種架構(gòu)中称鳞，因為有不少系統(tǒng)邏輯，例如認(rèn)證稠鼻、頁面導(dǎo)航冈止、搜索、交易等在服務(wù)端完成候齿，客戶端顯得相對不太智能熙暴。
采用Serverless架構(gòu)，開起來如圖二所示：

23147360

1. 刪除了認(rèn)證邏輯，而用第三方BaaS服務(wù)取代孕讳。
2. 使用另外一個BaaS匠楚，允許客戶端直接訪問架構(gòu)與第三方（例如AWS Dynamo）上的數(shù)據(jù)子庫。通過這種方式提供給客戶更安全的訪問數(shù)據(jù)庫模式厂财。
3. 前兩點中包含著很重要的第三點，也就是以前運行在寵物商店服務(wù)端的邏輯現(xiàn)在都轉(zhuǎn)移到客戶端中峡懈，例如跟蹤用戶訪問璃饱，理解應(yīng)用的UX架構(gòu)（例如頁面導(dǎo)航），讀取數(shù)據(jù)庫轉(zhuǎn)化為可視視圖等肪康〖远瘢客戶端則慢慢轉(zhuǎn)化為單頁面應(yīng)用撩穿。
4. 某些我們想保留在服務(wù)端的UX相關(guān)功能，例如谒撼，計算敏感或者需要訪問大量數(shù)據(jù)食寡，比如搜索這類應(yīng)用。對于搜索這類需求廓潜，我們不需要運行一個專用服務(wù)抵皱，而是通過FaaS模塊，通過API Gateway對http訪問提供響應(yīng)辩蛋。 這樣可以使得客戶端和服務(wù)端都從同一個數(shù)據(jù)庫讀取相關(guān)數(shù)據(jù)呻畸。 由于原始服務(wù)使用Java開發(fā)，AWS Lambda（FaaS提供者）支持Java功能悼院，因此可以直接從寵物商店服務(wù)端將代碼直接移植到寵物商店搜索功能伤为，而不用重寫代碼。
5. 最后据途，可以將‘purchase’功能用另外一個FaaS功能取代绞愚，因為安全原因放在服務(wù)端還不如重新在客戶端重新實現(xiàn)，當(dāng)然前端還是APIGateway颖医。 

消息驅(qū)動應(yīng)用

一個不同的例子是后臺數(shù)據(jù)處理服務(wù)爽醋。例如正在寫一個面向用戶的應(yīng)用，需要對UI請求快速響應(yīng)便脊，但是同時還想獲取所有發(fā)生的行為蚂四。我們設(shè)想一個在線廣告系統(tǒng)，當(dāng)用戶點擊一個廣告時哪痰，希望快速導(dǎo)向目標(biāo)遂赠，但是同時，需要搜集點擊量以便向廣告商收取費用晌杰。

傳統(tǒng)的架構(gòu)跷睦，‘Ad Server’同步地響應(yīng)客戶，但是同時還會向異步處理‘點擊量’的應(yīng)用發(fā)送一個消息更新肋演，以便以后向廣告商收費的數(shù)據(jù)庫抑诸。

6401

而Serverless架構(gòu)則如下：

6402

架構(gòu)跟我們第一個例子有些許不同，這里我們用FaaS功能取代了一個一直運行的應(yīng)用爹殊。此FaaS運行于方案提供商提供的消息驅(qū)動上下文之間蜕乡。需要注意的是供應(yīng)商提供了消息代理和FaaS，兩者之間更加緊密地合作在一起梗夸。
FaaS環(huán)境通過復(fù)制出若干實例也可以并行處理這些點擊层玲，這對開發(fā)無疑帶來全新概念。

BaaS云代碼解決方案 - FaaS(Function as a Service)

FaaS可以作為最細(xì)粒度的BaaS， 就像一個接口實現(xiàn)可能有多個Function來完成一樣辛块。 一個BaaS服務(wù)可以有一個FaaS來實現(xiàn)畔派，也可能是多個FaaS一起成一個chain來完成。 在這里我們將考慮FaaS的概念和實現(xiàn)润绵。

下面的架構(gòu)圖來自IBM OpenWhisk线椰， 非常貼切的描述了BaaS云代碼的架構(gòu)：

OpenWhisk_Arch2

我們已經(jīng)多次提過FaaS概念，現(xiàn)在我們來看看其真正含義尘盼。我們先看看Amazon Lambda產(chǎn)品的公開說明憨愉。我自己添加了標(biāo)記，將會逐一展開說明悔叽。

AWS Lambda使得用戶不需部署或者管理服務(wù)就可運行代碼（1）…通過Lambda莱衩，可以虛擬化地運行任何類型應(yīng)用和后臺服務(wù)（2）—都是免管理的。只需上載代碼娇澎，Lambda會管理其他一切（3）并且以高可用模式擴展應(yīng)用（4）可以配置自動從其他AWS服務(wù)激活代碼（5）或者從任何移動應(yīng)用中調(diào)用笨蚁。(6)

1. 功能上FaaS就是不需要關(guān)心后臺服務(wù)器或者應(yīng)用服務(wù)，只需關(guān)心自己的代碼即可趟庄。與現(xiàn)代其他架構(gòu)相比（例如容器和PaaS）括细，這是最大的不同。 如果回到上面所說的點擊案例戚啥，F(xiàn)aaS代替了點擊處理服務(wù)器（至少是一臺物理服務(wù)器奋单，但是絕對是一個特定應(yīng)用），因為這種架構(gòu)不需要一臺指定服務(wù)器猫十，甚至不需要一個一直運行的應(yīng)用模塊來處理览濒。

2. FaaS并不需要特定框架或者庫，從編程語言和環(huán)境角度更像是一個普通應(yīng)用拖云。例如AWS Lambda功能可以采用JavaScript贷笛、Python和任何其他JVM語言（Java、Clojure宙项、Scala等）乏苦。Lambda功能可以運行任何其他綁定部署的代碼，因此可以用任何可以編譯成Unix進(jìn)程的語言尤筐。FaaS功能也有一些架構(gòu)上的限制汇荐，特別當(dāng)面對狀態(tài)（state）或者執(zhí)行區(qū)間（execution duration）的問題，后面我們會提到盆繁∠铺裕回到上面說的點擊系統(tǒng)，轉(zhuǎn)到FaaS架構(gòu)唯一需要更改的代碼就是‘main method/startup’代碼（示例中被刪除了）改基，開始來代碼應(yīng)該是在頂層消息處理器中（‘message listener interface’實現(xiàn)）繁疤，但卻可能只是在方法簽名(method signature)的一個小小改變咖为。所有其他代碼（例如寫入數(shù)據(jù)庫的代碼）都沒有任何改變秕狰。

3. 因為沒有應(yīng)用服務(wù)需要部署因此FaaS跟傳統(tǒng)架構(gòu)差別很大稠腊，只需要上載代碼到FaaS提供者就足夠了。現(xiàn)在這也就意味著上載一個代碼包（例如以zip或者JAR形式）鸣哀，然后調(diào)用特定API初始話此更新架忌。

4. 水平擴展是完全自動、彈性我衬，由提供者來管理叹放。如果應(yīng)用需要并發(fā)處理100個請求，提供者將會處理后臺所有需求挠羔【觯‘計算容器’只是短暫運行應(yīng)用代碼，運行完畢后就銷毀這些需求破加。仍然回到點擊案例俱恶，假如今天運氣不錯，客戶點擊了日常點擊量的十倍范舀。點擊進(jìn)程能處理這些變化嗎合是？例如，我們設(shè)計的代碼可以同時處理多條消息嗎锭环？即使可以聪全，一個進(jìn)程可以處理這么多負(fù)載嗎？是否可以動態(tài)自動擴展進(jìn)程還是需要手工重新配置辅辩？有了FaaS难礼，代碼只需要處理并發(fā)，而其他自擴展功能則由提供者自動處理玫锋。

5. FaaS功能是由提供者定義的消息類型觸發(fā)的蛾茉。對于Amazon AWS，這些出發(fā)包括 S3（文件）更新景醇，時間（調(diào)度任務(wù)）和添加到消息總線上的消息（例如kinesis）臀稚。代碼一般都會提供消息源所需的參數(shù)。點擊案例中三痰，已經(jīng)假定我們使用了支持FaaS的消息代理吧寺。如果還沒有的話，就需要一個散劫，對消息生產(chǎn)者也有同樣的要求稚机。

6. 許多提供者允許FaaS功能作為http響應(yīng)來出發(fā)，一般是API網(wǎng)關(guān)获搏。例如在寵物商店案例中车荔，‘search’和‘purchase’功能项贺。

以下是FaaS隧枫，云代碼實施中解決的關(guān)鍵問題：

• State(狀態(tài))

FaaS功能如果使用本地狀態(tài)，會有很多嚴(yán)格限制碱茁。簡單說需要假設(shè)任何進(jìn)程間或者主機狀態(tài)對子進(jìn)程都不可見，包括在RAM和寫到本地盤上的狀態(tài)仿贬。換句話說纽竣，從一個部署單元來看FaaS功能是無狀態(tài)的。這一點對應(yīng)用架構(gòu)來說影響很大茧泪，同樣‘Twelve-Factor App’概念對架構(gòu)也有細(xì)致的限制蜓氨。

考慮到限制，應(yīng)該如何解決呢队伟？一般來說FaaS功能要么是自然無狀態(tài)穴吹，也就是提供純功能調(diào)用，要么會使用數(shù)據(jù)庫嗜侮，跨進(jìn)程見cache（例如Redis）港令，或者共享文件系統(tǒng)（或者S3）來存放狀態(tài)或者提供處理請求所需的更多輸入信息。

• Execution Duration(執(zhí)行區(qū)間)

FaaS功能一般會限制每個功能允許運行多長棘钞。目前AWS Lambda功能允許最多運行5分鐘缠借，如果超出就被強行退出。這意味著某些長時間運行的任務(wù)如果轉(zhuǎn)到FaaS架構(gòu)宜猜，就需要重新設(shè)計泼返，也就是說需要多創(chuàng)建幾個不同F(xiàn)aaS功能協(xié)調(diào)器，而在傳統(tǒng)架構(gòu)中姨拥，只需有一個就可以了绅喉。

• Startup Latency(啟動延遲)

目前FaaS功能多長時間會響應(yīng)跟很多因素有關(guān)，其延遲可能從10ms到2分鐘叫乌。聽起來不太好柴罐，我們用AWS Lambda舉個例子。
加入你的功能用Javascript或者Python開發(fā)憨奸，也不大（例如小于幾千行代碼）革屠，此時延遲一般不會超過10-100ms。更大的功能有可能會有更長的響應(yīng)時間排宰。
如果Lambda功能運行在JVM上似芝，當(dāng)JVM運行時，偶爾會看到響應(yīng)時間更長（例如大于10秒）的情況板甘，然而對于以下情況党瓮，高延遲則會很顯著：

* 應(yīng)用并不是很活躍，大概每十分種處理一次事件盐类。
* 突然流量爆發(fā)寞奸。例如從每秒10次濡染增長到每秒100次呛谜。

前者一般可以通過提高響應(yīng)頻次的方法來解決。

這些問題需要考慮嗎枪萄？的確需要看應(yīng)用的具體情況隐岛。我以前團(tuán)隊用Java開發(fā)過一個異步消息處理Lambda應(yīng)用，每天處理上億條消息呻引，而且沒有啟動延遲問題礼仗。也就是說不管采用什么開發(fā)語言吐咳，如果你想寫一個低延時交易應(yīng)用逻悠，現(xiàn)在可能并不適合采用FaaS架構(gòu)。

為了確認(rèn)應(yīng)用是否有問題韭脊，最好是用生產(chǎn)類型負(fù)載測試一下童谒。如果場景不適合，可以考慮轉(zhuǎn)向FaaS提供商沪羔。

BaaS服務(wù)治理解決方案 - API網(wǎng)關(guān)(API Gateway)

6403

BaaS云架構(gòu)中需要將一個后端服務(wù)以一個服務(wù)點(Restful API)的方式暴露給使用著饥伊，同是需要對這些服務(wù)點進(jìn)行管理，提供文檔蔫饰，測試等信息琅豆，提高開發(fā)者體驗。 當(dāng)一個服務(wù)被實現(xiàn)后篓吁，提供一個API 網(wǎng)關(guān)的東西茫因，將這個服務(wù)和服務(wù)點API關(guān)聯(lián)起來。

API Gateway是一個服務(wù)器杖剪，也可以說是進(jìn)入系統(tǒng)的唯一節(jié)點冻押。這跟面向?qū)ο笤O(shè)計模式中的Facet模式很像。API Gateway封裝內(nèi)部系統(tǒng)的架構(gòu)盛嘿，并且提供API給各個客戶端洛巢。它還可能有其他功能，如授權(quán)次兆、監(jiān)控稿茉、負(fù)載均衡、緩存芥炭、請求分片和管理漓库、靜態(tài)響應(yīng)處理等。

API Gateway負(fù)責(zé)請求轉(zhuǎn)發(fā)蚤认、合成和協(xié)議轉(zhuǎn)換米苹。所有來自客戶端的請求都要先經(jīng)過API Gateway，然后路由這些請求到對應(yīng)的微服務(wù)砰琢。API Gateway將經(jīng)常通過調(diào)用多個微服務(wù)來處理一個請求以及聚合多個服務(wù)的結(jié)果蘸嘶。它可以在web協(xié)議與內(nèi)部使用的非Web友好型協(xié)議間進(jìn)行轉(zhuǎn)換良瞧，如 HTTP協(xié)議、WebSocket協(xié)議训唱。

關(guān)于FaaS我們之前討論過‘API Gateway’褥蚯，一個API Gateway是一個http服務(wù)器，路由和服務(wù)點都在配置里定義况增，每個路由都跟一個FaaS功能有聯(lián)系赞庶。當(dāng)一個API Gateway接受請求，找到提供請求服務(wù)的路徑澳骤，然后調(diào)用相關(guān)FaaS功能歧强。一般API Gateway允許將http參數(shù)映射成FaaS功能需要的輸入?yún)?shù)。API Gateway將FaaS功能結(jié)果轉(zhuǎn)換為http響應(yīng)为肮，返回調(diào)用者摊册。

Amazon Web Services等云服務(wù)提供商都各自提供自己的API Gateway。

除了API Gateway路由請求需要認(rèn)證颊艳，輸入驗證茅特，相應(yīng)代碼映射等，有時候可能還會想是否這是個好主意棋枕，那么讓我們更深入論證一下白修。
APIGateway+FaaS的一個應(yīng)用場景就是用Serverless方式創(chuàng)建http前端微服務(wù)，充分利用擴展重斑，管理和其它與FaaS功能有關(guān)的其它優(yōu)點兵睛。
目前API Gateway開發(fā)工具并不太成熟，因此定義API Gateway應(yīng)用時候最好不是非常核心的引用绸狐。

BaaS服務(wù)實施方案 - Microservice

微服務(wù)用于解決如何分解巨大單體式應(yīng)用為多個服務(wù)方法解決了復(fù)雜性問題卤恳。在功能不變的情況下，應(yīng)用被分解為多個可管理的分支或服務(wù)寒矿。每個服務(wù)都有一個用RPC-或者消息驅(qū)動API定義清楚的邊界突琳。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實現(xiàn)的功能提供了模塊化的解決方案，由此符相，單個服務(wù)很容易開發(fā)拆融、理解和維護(hù)。

對于Serverless架構(gòu)里啊终，最關(guān)鍵的就是用將代表復(fù)雜答題時應(yīng)用的服務(wù)器消除镜豹，取而代之用一些列輕量，簡單蓝牲，易開發(fā)維護(hù)擴展趟脂，相互松耦合，原子性的服務(wù)來代替例衍。 MicroService架構(gòu)也是BaaS種很重要的架構(gòu)模式昔期， 我們會在后續(xù)詳細(xì)介紹已卸。

BaaS服務(wù)DevOps方案 - Docker

在BaaS開發(fā)架構(gòu)中，服務(wù)的需要能夠動態(tài)靈活按需的發(fā)布在一個輕量級無狀態(tài)的容器里硼一，這個容器就是目前流行的Docker累澡，Docker對實施服務(wù)的DevOps提供了革命性的方案，后續(xù)會詳細(xì)介紹Docker在BaaS架構(gòu)體系中的重要性般贼。

Case(案例)

• Beehive云開發(fā)平臺 - 阿里內(nèi)部自己的BaaS開發(fā)平臺

Beehive是按照BaaS架構(gòu)理念構(gòu)建的云開發(fā)平臺愧哟， 在這個平臺我們預(yù)先實現(xiàn)了對社交內(nèi)容類開發(fā)必要的多種功能，包括數(shù)據(jù)哼蛆，社交蕊梧，權(quán)限，事件人芽，計數(shù)望几，文件儲存，地理位置等萤厅。 提供給開發(fā)者快速業(yè)務(wù)創(chuàng)新的平臺。 目前已經(jīng)有2個內(nèi)部項目通過Beehive云開發(fā)平臺開發(fā)靴迫。 該平臺在服務(wù)器端實現(xiàn)了API Gateway, Data as a Service（通用數(shù)據(jù)存儲）等架構(gòu)特性惕味。

下個版本，將重點實現(xiàn)Cloud Code(FaaS）玉锌， 微服務(wù)docker化部署名挥， 能力市場等特性。 打造云時代的新一代開發(fā)者平臺主守。 對標(biāo)Amazon APIGateway & lambda, Google FireBase, IBM BlueMix + OpenWhisk.

• Amazon APIGateway & lambda

• IBM OpenWhisk

  IBM Bluemix OpenWhisk平臺讓廣大開發(fā)人員能夠迅速構(gòu)建微服務(wù)禀倔，從而可以響應(yīng)諸多事件，比如鼠標(biāo)點擊或收到來自監(jiān)視攝像頭的傳感器數(shù)據(jù)参淫，執(zhí)行軟件代碼救湖。事件發(fā)生后，代碼會自動執(zhí)行涎才。因而鞋既，開發(fā)人員不需要為預(yù)先配置基礎(chǔ)設(shè)施之類的事情（比如服務(wù)器或系統(tǒng)運行）而操心――他們只需專注于代碼，因而顯著加快了工作流程耍铜。

• Google FireBase

  • 《2016 Google I/O Firebase, Google在BaaS上又前進(jìn)了一步》 -這里有對Google Firebase BaaS開發(fā)平臺詳細(xì)介紹邑闺。

• Auth0

  一開始Auth0是作為Baas（‘Authentication as a Service’），但是隨著Auth0 webtask的發(fā)布棕兼，演變成了FaaS應(yīng)用陡舅。

• Contentful

  在BaaS云開發(fā)平臺基礎(chǔ)上，可以很容易開發(fā)出各種垂直類的SaaS平臺伴挚。 Contentful就是一個很好的示例靶衍。

  
  
  _2016_06_30_16_16_34

  Contenful可以理解為基于BaaS基礎(chǔ)上的一個CMS SaaS平臺臂寝， 雖然是個內(nèi)容管理平臺，對充分體現(xiàn)了BaaS摊灭，Serverless咆贬， 定制化SaaS等理念。 有興趣的同學(xué)可以深入研究下帚呼。

  這是一個幾乎不用服務(wù)器Serverless的內(nèi)容管理系統(tǒng)網(wǎng)站架構(gòu)掏缎，相比于傳統(tǒng)使用WordPress和CraftCMS等內(nèi)容管理系統(tǒng)可以節(jié)省網(wǎng)站的運營管理，相比于維護(hù)傳統(tǒng)的LAMP架構(gòu)煤杀，Serverless幾乎可以沒有DevOps眷蜈。

  有時很多客戶只是需要一個靜態(tài)網(wǎng)站，有一個漂亮的圖形首頁和一些其他靜態(tài)頁面即可沈自，網(wǎng)站一旦發(fā)布酌儒，幾乎很少需要運營維護(hù)。那么使用什么技術(shù)構(gòu)建這種靜態(tài)網(wǎng)站枯途？無疑是Serverless架構(gòu)忌怎，亞馬遜的Web服務(wù)已經(jīng)羅列出優(yōu)點：
  1.不需要糾結(jié)于操作系統(tǒng)的選擇以及安全與管理
  2.沒有服務(wù)器需要配置 監(jiān)控或擴展
  3.沒有成本超額造成的風(fēng)險
  4.沒有性能考量造成的風(fēng)險

Serverless更多思考

什么不是Serverless?

目前我們定義Serverless主要意味著’Backend as a Service’ 和 ‘Functions as a Service’。針對他們我們也深入探討了各種因素酪夷。
開始討論有缺點之前榴啸，我們再來看看定義，或者至少定義一下什么不是‘Serverless’晚岭。很多人會很迷惘鸥印，因此討論一下還是很值得的。

跟PaaS比較

考慮到Serverless FaaS功能很像12-Factor applications（譯者注：是一種創(chuàng)建現(xiàn)代坦报，可擴展库说，可維護(hù)SaaS應(yīng)用的方法論），它們只是像Heroku的另外一種PaaS嗎片择？下面引用Adrian Cockcroft的一段論述：

如果你的PaaS可以將以前半秒啟動的應(yīng)用在20ms內(nèi)啟動潜的，就叫它Serverless」够兀——Adrian Cockcroft

換句話說夏块，許多PaaS應(yīng)用不會每次請求來了啟動，請求結(jié)束則關(guān)閉纤掸。而FaaS平臺是這樣的脐供。

好吧，然并卵借跪。如果我是一個很好地12-Factor App開發(fā)者政己，并不會太多開發(fā)上的不同吧？這是真的掏愁。但是在運維應(yīng)用上卻又很大不同歇由。因為所有好的DevOps-savvy工程師都會同時考慮開發(fā)和運維卵牍，對吧？FaaS和PaaS在運維方面最大不同來自于可擴展性（scaling）沦泌。許多PaaS架構(gòu)糊昙，用戶必須考慮scale，例如杜宇Heroku來說需要運行多少Dynos谢谦；而對于FaaS應(yīng)用來說释牺，這是完全透明的。即使配置PaaS應(yīng)用自擴展回挽，也不會將它設(shè)置為請求級別的（除非負(fù)載訪問情況很特殊）没咙，而對FaaS應(yīng)用來說，從投入角度更加有效千劈。

考慮到這些優(yōu)勢祭刚，為什么還是用PaaS架構(gòu)？有一些原因墙牌，但是工具涡驮，API Gateway成熟度應(yīng)該是最大原因。另外憔古，12-Factor Apps為了優(yōu)化遮怜，實現(xiàn)PaaS時會采用App內(nèi)部只讀cache，而對于FaaS來說則沒有這個選項鸿市。

NoOps

Serverless并不意味著‘免維護(hù)’〖赐耄或許根據(jù)你對Serverless有多適應(yīng)焰情，應(yīng)該意味著‘不需定時維護(hù)’，有很重要的兩點需要考慮剥懒。
首先内舟，‘Ops’意味著比服務(wù)器維護(hù)更多的內(nèi)容。至少還包括監(jiān)控初橘，部署验游，安全，網(wǎng)絡(luò)保檐，以及產(chǎn)品排錯和系統(tǒng)擴展耕蝉。這些問題對于Serverless應(yīng)用來說仍然還在，需要一種策略來處理夜只。某種程度上垒在，在Serverless世界Ops有些困難，因為一切都是新的扔亥。

第二场躯，即使系統(tǒng)管理還在發(fā)生谈为，其實我們是他們外包給了Serverless。這并不是件壞事踢关，我們實際上外包了很多事情伞鲫。但是根據(jù)你真正想做什么，可能是件好事也可能時間壞事签舞，有時候這種抽象會出現(xiàn)問題秕脓，你需要確認(rèn)到底是誰在支持你的應(yīng)用。

Stored Procedures as a Service

關(guān)于Serverless FaaS另外一個論點在于‘Stored Precedures as a Service’瘪菌，我認(rèn)為這一論點來自于很多FaaS的實現(xiàn)（包括本文中用到的例子）都是小段代碼訪問數(shù)據(jù)庫撒会。如果這就是所有要求，用FaaS當(dāng)然是可以的师妙。但是因為這僅僅是FaaS的一小部分功能诵肛，用這種想法考慮FaaS是以偏概全了。

還有人說默穴，考慮FaaS是否會帶來跟stored procedures同樣的問題是值得的怔檩，包括技術(shù)方面的問題（Camile在tweet上提到這些問題）。使用stored procs值得審視FaaS上下文蓄诽，這里有很多教訓(xùn)薛训。例如：

經(jīng)常需要用特定語言，或者是特定的框架仑氛、某種語言的擴展乙埃。
因為執(zhí)行時必須要有數(shù)據(jù)庫上下文，測試很困難锯岖。
版本控制需要技巧

注意介袜，以上所述并不能涵蓋所有stored procs，但是確實是我實際中遇到的問題出吹。我們看看是否也適用于FaaS：

第一點對FaaS實施絕對不使用遇伞，因此可以毫不猶豫將它劃去。
因為這里我們只討論編碼捶牢。整合測試是我們需要后續(xù)討論的另外一個問題鸠珠。
應(yīng)為FaaS功能對于代碼版本控制足夠了，但是對于應(yīng)用打包來說并沒有成熟模板秋麸。Serverless框架自己提供了一套渐排，AWS也宣稱在2016年五月Serverless大會上發(fā)布一套，但是至少現(xiàn)在是一個值得擔(dān)心的問題竹勉。

總結(jié)

• Serverless代表無服務(wù)器計算技術(shù)崛起飞盆， 是新一代云服務(wù)和開發(fā)架構(gòu)的實踐。
• BaaS是云端一體的開發(fā)架構(gòu)，而serverless是BaaS的服務(wù)器端實現(xiàn)的主要架構(gòu)方式吓歇。
• Serverless架構(gòu)是BaaS實現(xiàn)的精髓孽水，是BaaS進(jìn)一步的解讀，F(xiàn)aaS（Function as a service)是BaaS中云代碼的實現(xiàn)方式城看。 Amazon的Lambda是FaaS的實現(xiàn)之一女气，是很好的參考。
• Amazon的BaaS戰(zhàn)略通過Amazon API Gateway测柠， Amazon Lambda來實現(xiàn)炼鞠，在后端服務(wù)上已經(jīng)處于領(lǐng)跑地位，真正把微服務(wù)轰胁，docker谒主，BaaS等思想落地。

下面有一些簡單公示赃阀，方便大家理解：

BaaS = 云API + 端API霎肯。 
云API = service with Serverless(API Gateway + Mirocroserivce + Docker) + ...
端API= 多端SDKs + Component(前端組件) 

參考資料

• Beehive云開發(fā)平臺 - 阿里自己的Serverless架構(gòu)的BaaS云開發(fā)平臺
• AMA社區(qū)-Beehive開發(fā)實例 - 基于Beehive開發(fā)，沒寫一行后端代碼
• Beehive云開發(fā)平臺ATA圈 - 更多Beehive資料榛斯，請關(guān)注該圈子
• 《Serverless Architectures》- Martin Fowler最新Serverless架構(gòu)大作
• 《The Twelve-Factor App》 - SaaS類應(yīng)用開發(fā)人員必讀
• 《BaaS后端即服務(wù) - 通往中臺架構(gòu)之路》- 介紹BaaS的一些總體思考观游。
• 《BaaS后端即服務(wù) - 概念篇》- 介紹BaaS的概念，在云架構(gòu)體系中的定位驮俗。
• 《BaaS后端即服務(wù) - 分析篇》- 介紹當(dāng)前BaaS發(fā)展的趨勢和主流BaaS平臺功能的對比懂缕。

serverless