發(fā)端
云計算機經(jīng)過這么多年的發(fā)展，逐漸進化到用戶僅需關(guān)注業(yè)務(wù)和所需的資源。通過Swarm割岛、K8S這些編排工具揍诽，容器服務(wù)讓開發(fā)者的體驗達到很完美的境界诀蓉。我曾經(jīng)覺得Docker可以替代虛機，用戶只要關(guān)注自己的計算和需要的資源就行暑脆，不需要操心到機器這一層渠啤。但是因為Docker對資源的隔離不夠好，各大云廠商的做法還是一個Docker對應(yīng)一臺虛機添吗，不僅成本高沥曹，給用戶暴露虛機也多余了。
用戶為什么需要關(guān)注業(yè)務(wù)運行所需要的CPU碟联、內(nèi)存妓美、網(wǎng)絡(luò)情況？還有沒有更好的解決方案鲤孵？Serverless架構(gòu)應(yīng)運而生壶栋，讓人們不再操心運行所需的資源，只需關(guān)注自己的業(yè)務(wù)邏輯普监，并且為實際消耗的資源付費贵试×鸲担可以說，隨著Serverless架構(gòu)的興起毙玻，真正的云計算時代才算到來了豌蟋。
容器在開發(fā)模式方面并沒有提出新的想法，大家還是在用傳統(tǒng)的那一套開發(fā)模式桑滩，需要寫一個大而全的后端服務(wù)夺饲。與之對比，Serverless架構(gòu)是事件驅(qū)動的施符，這樣讓后端的開發(fā)體驗變得跟前端和移動端很類似了往声。針對不同客戶的需求，先讓其購買好相關(guān)的資源戳吝，然后一個個填坑浩销，給不同的產(chǎn)品添加各種事件處理邏輯就行。這就跟iOS開發(fā)一樣听哭，界面寫出來慢洋，然后處理一個個事件就好了，大家都很容易理解這種開發(fā)模式陆盘。
AWS Lambda體驗
AWS在2014年11月的re:Invent大會上推出Lambda普筹，經(jīng)過將近三年的發(fā)展，已經(jīng)達到了非常完善的程度隘马。Lambda主要有三個作用太防。
- 跟API Gateway結(jié)合起來，方便快捷地提供API服務(wù)酸员。
- 串聯(lián)關(guān)鍵產(chǎn)品蜒车，比如在DDB插入一條新數(shù)據(jù)之后，觸發(fā)Lambda執(zhí)行幔嗦，讀取新記錄送給搜索引擎建索引酿愧。
-
擴展功能，比如Cognito User Pool提供非常多的點邀泉，方便用戶在登錄的時候增加自己的處理邏輯嬉挡。
image.png
AWS Lambda支持多種語言開發(fā)，比如C#汇恤、Java庞钢、Node.js和Python，擁有廣泛的群眾基礎(chǔ)屁置。
AWS Lambda在除北京之外的所有region均可用焊夸。AWS中國支持的產(chǎn)品可以參考：地區(qū)表。
Serverless Reference Architecture: Mobile Backend是一個非常好的實例蓝角，講述了如何通過Serverless架構(gòu)實現(xiàn)一個App阱穗。
這個App的主要功能類似Evernote饭冬，支持上傳圖片，編寫和上傳文章揪阶。功能非常簡單昌抠，但是涉及到的產(chǎn)品非常多，玩法也非常老練鲁僚。
| 1 | 2 | 3 |
|---|---|---|
 image.png
|
 image.png
|
 image.png
|
整個demo用到的云產(chǎn)品和它們相互之間的關(guān)系如下圖所示炊苫。除了Lambda本身，IAM冰沙、API Gateway等產(chǎn)品也發(fā)揮了巨大的作用侨艾。
$ tree cloudformation lambda-functions
cloudformation
├── config-helper.template
├── mobile-backend-no-cloudfront.template //去除CloudFront相關(guān)配置的template文件。在CloudFormation控制臺上傳該文件拓挥。
└── mobile-backend.template //如果CloudFront可用的話唠梨，上傳這個template文件也OK。
lambda-functions //Lambda代碼已經(jīng)壓縮好并放到一個公共的S3 bucket里面侥啤，所以不用管這些代碼当叭。
├── search
│ └── index.js //CloudSearch搜索接口的代碼
├── stream-handler
│ └── index.js //DDB觸發(fā)建索引的代碼
└── upload-note
└── index.js //新增文章接口的代碼，主要是寫DDB盖灸。
配置
CloudFormation真的很方便蚁鳖，template上傳之后，相關(guān)的資源就創(chuàng)建和設(shè)置好了赁炎。cloudformation目錄下有兩個template文件醉箕，只需上傳mobile-backend.template，它會把config-helper.template加載好甘邀。阿里云對應(yīng)的產(chǎn)品是：資源編排ROS琅攘。
看起來API Gateway、Cognito松邪、CloudSearch這幾款個產(chǎn)品對CloudFormation支持的并不好，所以還需要通過文章中那么多命令行和Web控制臺上的設(shè)置哨查。
為了能運行這些命令逗抑，要把AWS CLI配置好，region設(shè)置為us-east-1（弗吉尼亞北部）寒亥，因為文章中存放Lambda代碼壓縮包的S3也是在us-east-1區(qū)域的邮府。
$ aws configure
AWS Access Key ID [****************X3CA]:
AWS Secret Access Key [****************Qo3J]:
Default region name [us-east-1]:
$ cat ~/.aws/config
[default]
region = us-east-1
配置里面的一些坑
一個坑是CloudFront可能沒有初始化好，導(dǎo)致CloudFormation創(chuàng)建失敗溉奕。懶得去配置了褂傀，所以我干脆刪除了CloudFormation里面CloudFront相關(guān)的配置。這樣并不會影響體驗加勤。
CloudFormation有一個資源創(chuàng)建失敗后仙辟，會rollback同波。它把資源的創(chuàng)建當(dāng)做一個事務(wù)來處理，全部成功才行叠国。
客戶端使用Swift 2.3寫的未檩。因為代碼也比較簡單，所以Convert到3.0就行粟焊。后面接著會報Ambiguous use of 'continue'錯誤冤狡，類似下面這樣的代碼使用一對小括號括住block就行。
let noteApiClient = APINotesApiClient(forKey: "USEast1NoteAPIManagerClient")
noteApiClient?.notesPost(noteRequest).continue ({ (task) -> AnyObject! in
if let error = task?.error {
print("Failed creating note: [\(error)]")
}
if let exception = task?.exception {
print("Failed creating note: [\(exception)]")
}
if let noteResponse = task?.result as? APICreateNoteResponse {
if((noteResponse.success) != nil) {
print("Saved note successfully")
}else {
print("Unable to save note due to unknown error")
}
}
return task
})
程序運行起來之后项棠，Upload Image到S3沒有問題悲雳。但是上傳文章的時候會報forbidden的錯誤。Xcode里面會打印下面這個錯誤香追。通過Charles抓包合瓢，發(fā)現(xiàn)服務(wù)器端給了錯誤提示。
需要在Usage Plans里面Add API Stage里面操作一下翅阵，API和Stage對上就好了歪玲。文章中沒有提到這個配置。
一些技術(shù)細節(jié)
App直接面對API Gateway和S3掷匠，要先從Cognito Identity Pool獲取到一個id（Unauthenticated）滥崩，這個Pool對應(yīng)MobileClientRole角色，可以看一下這個角色的具體配置讹语，主要是針對S3和API Gateway相關(guān)action的allow 钙皮。這里直接使用了API Gateway生成的SDK，結(jié)合Cognito Identity Pool用著也挺方便顽决。API Gateway也支持使用Cognito UserPool做驗證器短条，不需要SDK，用起來更加簡單一些才菠，詳細信息可以參看：對AWS Cognito的一些理解
茸时。
/notes的post接口交給NotesApiFunction Lambda來處理，在控制臺可以看得很清楚赋访。
DDB變動會觸發(fā)執(zhí)行DynamoStreamHandlerFunction這個Lambda可都，從配置里面也可以很清楚看到這個trigger。
效果
S3里面可以看到圖片蚓耽。
Dynamo DB里面可以看到Post數(shù)據(jù)渠牲。
但是CloudSearch里面Searchable Documents卻一直都是0。
可以看看DynamoStreamHandlerFunction這個Lambda的數(shù)據(jù)步悠，發(fā)現(xiàn)調(diào)用都失敗了签杈。
去CloudWatch里面看看。提示TypeError: Cannot read property 'S' of undefined鼎兽。
對著stream-handler/index.js看了一下答姥，發(fā)現(xiàn)拿到Dynamo DB的數(shù)據(jù)之后铣除，要通過.S將其轉(zhuǎn)型為字符串類型。再對著文檔看看踢涌，其實是沒有毛病的通孽，所以這個問題還不知道怎么解決。
function createSearchDocuments(records) {
var searchDocuments = [];
for(var i = 0; i<records.length; i++) {
var record = records[i];
if (record.eventName === "INSERT") {
var searchDocument = {
type : 'add',
id : record.dynamodb.Keys.noteId.S,
fields : {
headline : record.dynamodb.NewImage.headline.S,
note_text : record.dynamodb.NewImage.text.S
}
};
searchDocuments.push(searchDocument);
}
}
return searchDocuments;
}
這個問題突然就消失了睁壁，建索引和檢索功能都正常了背苦，amazing~
費用
Lambda根據(jù)使用內(nèi)存和調(diào)用次數(shù)收費。內(nèi)存最低是128MB潘明。具體信息請參看：Lambda 定價詳情行剂。
這個App使勁玩，花不了幾塊錢的钳降。Lambda累計運行了240秒厚宰，沒有花錢，主要是S3和數(shù)據(jù)傳輸花了點錢遂填。
Serverless成功的關(guān)鍵
擁有豐富的產(chǎn)品铲觉，并且打通所有的云產(chǎn)品，是Serverless成功的前提條件吓坚。Lambda不適合處理復(fù)雜的業(yè)務(wù)邏輯撵幽，比較適合作為膠水代碼，粘合關(guān)鍵的產(chǎn)品礁击。另外就是Lambda不管怎么完善盐杂，可能只能解決80%的問題，剩下20%的邏輯需要用戶自己寫服務(wù)哆窿，通過docker發(fā)布链烈，然后給Lambda或者用戶使用。這種混合的編碼方式可能是未來的主流開發(fā)模式挚躯。
Serverless的主要優(yōu)點
- 開發(fā)者更加專注于業(yè)務(wù)邏輯强衡，開發(fā)效率更高。開發(fā)一個典型的服務(wù)器端項目码荔，需要花很多時間處理依賴食侮、線程、日志目胡、發(fā)布和使用服務(wù)、部署及維護等相關(guān)的工作链快，基于Serverless架構(gòu)則不需要操心這些工作誉己。
- 用戶為實際使用的資源付費。用戶購買的ECS使用時間一般不到5成域蜗，但是為另外5成閑置時間付費了巨双。Lambda按照運行的時間收費噪猾，成本會低很多。
- NO Architecture筑累，NO Ops袱蜡。架構(gòu)師的責(zé)任是設(shè)計一個高可用、高擴展的架構(gòu)慢宗。運維負責(zé)整個系統(tǒng)穩(wěn)定可靠地運行坪蚁，適當(dāng)縮減和增加資源。大型云廠商能保證產(chǎn)品的高可用镜沽，Serverless架構(gòu)本身就是高擴展的敏晤。Serverless不再需要服務(wù)器端的工作人員，給客戶節(jié)省了大量的資源缅茉。架構(gòu)師和運維的同學(xué)應(yīng)該好好思考一下未來的出路了嘴脾。架構(gòu)師可以轉(zhuǎn)型去做銷售，整理用戶的需求蔬墩，然后寫寫CloudFormation的template就好了译打。
- 還是成本。IT行業(yè)一些領(lǐng)先的公司基礎(chǔ)設(shè)施非常完善拇颅，開發(fā)工程師寫好代碼奏司，然后通過發(fā)布平臺發(fā)布，感覺也是挺方便的蔬蕊。比起Serverless的架構(gòu)结澄，成本還是要高不少。
- 機器成本岸夯。日常麻献、預(yù)發(fā)、線上猜扮，1+1+2=4臺服務(wù)器少不了勉吻。
- 時刻要關(guān)注業(yè)務(wù)數(shù)據(jù)，盤點資源旅赢，看看是否需要擴容和縮減資源齿桃。擴容容易，縮減難煮盼，造成大量資源閑置短纵。
- 全鏈路壓測是不是很煩？
Serverless的主要缺點
-
排查問題困難僵控，因為邏輯散落在各處香到，一個操作可能觸發(fā)成百上千個Lambda執(zhí)行。AWS的X-Ray和CloudWatch等產(chǎn)品可以幫助用戶排查問題。
image.png 準備runtime需要時間悠就，流量瞬間爆發(fā)容易導(dǎo)致超時千绪。
帶狀態(tài)的Lambda寫起來很困難。
-
Lambda運行有諸多資源限制梗脾，比如運行時長荸型、內(nèi)存、磁盤炸茧、打開的文件數(shù)量等瑞妇。
image.png 廠商鎖定。云計算是贏者通吃的行業(yè)宇立，大而全的云廠商優(yōu)勢巨大踪宠，Serverless加劇了這種趨勢。以前用戶還需要自己寫很多服務(wù)器端的邏輯妈嘹，遷移的時候柳琢，把服務(wù)器端代碼重新部署一下。采用Serverless架構(gòu)之后润脸，代碼都是各個平臺的Lambda代碼片段柬脸，沒法遷移。從客戶的角度來看毙驯，是不希望自己被某家云廠商所綁架的倒堕。所以云計算行業(yè)需要做很多標準化的工作，方便用戶無縫在各種云之間遷移爆价。
阿里云對Serverless的支持情況
阿里云在今年四月份南京云棲大會上推出了自己的Serverless產(chǎn)品：函數(shù)計算垦巴，目前只支持API Gateway和OSS，并且只能在華東2區(qū)域使用铭段。還沒有形成體系骤宣，很難滿足用戶多樣的需求。
推廣Serverless不是一件容易的事情序愚，一是現(xiàn)有產(chǎn)品上云要接入的東西有點多憔披，比如售賣、權(quán)限爸吮、風(fēng)控芬膝、服務(wù)等級等，未來還需要接入Serverless形娇。開發(fā)團隊很累锰霜。第二個是，現(xiàn)有大量的產(chǎn)品要一個個去推動做改造桐早，不是一件容易的事情锈遥。
不過阿里云也在很努力完善對Serverless的支持纫事，未來可期。函數(shù)計算攜手API網(wǎng)關(guān)輕松實踐Serverless架構(gòu)
云棲社區(qū)有一些相關(guān)的文章：阿里云 Serverless Computing所灸，講得非常好，可以了解一下炫七。
MBaaS/MPaaS為什么不賺錢爬立？
移動開發(fā)領(lǐng)域最早有一些廠商提供移動推送、Crash收集分析万哪、移動數(shù)據(jù)分析等基礎(chǔ)服務(wù)侠驯，也就是MPaaS。然后逐漸有一些廠商開始提供數(shù)據(jù)庫奕巍、存儲吟策、配置等相關(guān)的服務(wù)，管理員在Web控制臺上操作的止，移動端直接使用這些服務(wù)檩坚，不需要經(jīng)過服務(wù)器端中轉(zhuǎn)，這就是MBaaS诅福。
目前移動開發(fā)領(lǐng)域的服務(wù)提供商匾委，比如Facebook的Parse（已關(guān)閉）、Firebase（已被Google收購氓润，現(xiàn)在很強大）赂乐、國內(nèi)的LeanCloud都發(fā)展得不好。我覺得主要還是因為產(chǎn)品線不夠豐富咖气，只能滿足一些小App或者App發(fā)展初期的需要挨措。MBaaS/MPaaS依托主流云廠商豐富的產(chǎn)品線，通過類似Lambda機制將這些產(chǎn)品串聯(lián)起來崩溪，應(yīng)該會有不錯的發(fā)展浅役。
