簡介：當 Serverless 與低代碼這兩個不同的技術共同相交于同一個業務時會有怎樣的價值展現？本文以 “盲盒抽獎” 這個 Serverless Devs 做過的創意營銷活動為例，為大家講述 Serverless 和低代碼是如何搭配來滿足一個業務訴求的。
作者 | 寒斜 & 江昱
當 Serverless 與低代碼這兩個不同的技術共同相交于同一個業務時會有怎樣的價值展現？本文以 “盲盒抽獎” 這個 Serverless Devs 做過的創意營銷活動為例，為大家講述 Serverless 和低代碼是如何搭配來滿足一個業務訴求的。
前言
線上 H5 創意動畫結合線下實體獎勵是網際網路營銷活動的一種常見手段。為了抓住關鍵時間節點，活動從策劃到落地的周期一般都比較短，短時間内落地線上服務對于做技術開發的同學有着不小的挑戰。
尤其是當有更多需求，比如增加背景管理以及關鍵前端通路資料埋點等需求時，挑戰難度往往會加倍。對于開發而言除了完成業務核心訴求，往往還需要關注非業務訴求以外的其他狀況，比如系統通路安全，高并發流量應對，系統運作名額可觀測等。
在以前這類需求往往需要跟多的角色參與，如産品，前端，後端，設計，測試，營運，運維等，使得投入産出比變得比較低，活動持續性比較差。今天使用 Serverless + 低代碼的技術我們可以大幅縮減做此類活動的成本，讓它變成持續性的活動，進而大大提高營運效果。
實際上 Serverless Devs 此次的盲盒抽獎活動僅僅投了 3.5 個人，便完成了活動策劃，産品設計, 前後端實作，系統部署運維等工作。并且借助于 Serverless 的服務能力，輕松應對了系統通路安全，高并發流量，系統可觀測等這些非業務挑戰。功能性的補齊 + 效率提升，讓本次營運取得了非常好的收益，活動服務的模闆化沉澱又為後續同類活動奠定好了良好的基礎。
“盲盒抽獎” 活動的整體流程如下：
- 需求設計（含業務邏輯和互動邏輯）
- 設計稿
- 低代碼實作前端
- 編碼實作 Serverless 服務
- 聯調測試
- 部署上線
- 活動中問題修複
- 活動後複盤
應用效果預覽：
“1 分鐘 Serverless 極速部署盲盒” 抽獎活動目前已經結束，但是感興趣的同學仍可以體驗一下：
https://developer.aliyun.com/adc/series/serverless2
架構預覽：
本次的部署架構沒有使用阿裡雲API網關，而是直接用函數計算 Custom Runtime 作為托管形态，這樣做是因為本次需求的特殊性，我們是“自己部署自己抽”，實際上意味着端側通路是非中心化的，端側通路的服務做的也比較薄，隻是資料處理接口調用和提供靜态渲染服務，後經過一個中心化的邏輯背景進行中獎機率，管理獎品查詢資料庫等。
如果您是自己做中心化的的活動背景的話建議參考下面的架構模式，采用 API網關作為流量入口。友善做更多的安全限制以及更靈活的擴充
實作解析
前端互動低代碼實作
本次前端實作使用低代碼工作 hype4，hype4 的具體使用這裡不做詳細介紹，有興趣的同學可以自行搜尋。
設計稿除了之後将需要的圖切出來，然後跟處理 Flash 一樣将動畫效果實作，最後就是添加 js 代碼實作接口通路，場景切換等能力。整個流程會比全編碼要快很多，尤其是動效實作上比純手寫效率高 2-3 倍。
資料層 Serverless 服務
如架構所示，這裡的資料層實際上就是我們了解的 SSF ，這層僅做資料轉發和靜态的渲染。代碼實作比較簡單，采用 express 架構，然後以函數計算 Custom runtime 形式部署。
目的是為了這個服務既可以托管靜态内容也可以做動态的資料轉發。值得注意的是，使用者的資訊擷取也是在這層實作的。
這裡我們擷取的是阿裡雲使用者的 accountId，友善對齊中獎資訊發放獎品。對于普通開發者而言這個參數沒有太大意義。
我們會提前将搖獎背景部署完畢，接下來就是，每個使用者自己部署完這層服務後，通路自己部署好的服務，然後向搖獎背景傳遞 uid 等基本資訊，發起搖獎。最終傳回中獎結果透傳給前端展示。作為管理者則可以通過背景操作設定獎品和機率等。
背景抽獎邏輯實作
後端服務采用 Python Web 架構：Django 進行實作，主要方法有：
1.擷取使用者的 uid 資訊，并對uid資訊進行校驗，以確定：
- uid 資訊的準确性
- 該用戶端服務是通過 Serverless Devs 開發者工具進行部署；
2.當日獎品池的建構；
3.使用者中獎資訊的初步确定；
4.使用者中獎資訊的複核；
5.傳回最終的結果給用戶端；
基本流程
1.使用者在本地，将盲盒抽獎的用戶端服務，通過 Serverless Devs 開發者工具進行部署，部署到使用者自己的賬号下；
在部署期間，需要給使用者下發一個臨時域名 （這個臨時域名需要用到使用者的 uid），Serverless Devs 在進行臨時域名下發的過程中，會生成部分的用戶端token，并記錄到 Serverless Devs 後端服務中；這個token實際上就是鑒定使用者身份的重要标記；
(如果使用者在 Yaml 中聲明了不使用系統自動下發的域名資訊，可能就沒辦法順利參加本次活動）。
2.使用者部署完成之後，會傳回一個Serverless Devs下發的臨時域名，供使用者學習和測試使用。
3.接下來使用者通過浏覽器，打開該臨時域名，便可以看到抽獎的相關頁面，使用者可以點選進行抽獎操作。
4.使用者點選抽獎操作之後，會發起請求，請求使用者賬号下的 Serverless 服務，該服務會根據使用者的 uid 資訊進行相關的處理，并發起真正的抽獎請求到本次活動的後端 Serverless 服務上；
5.本次活動的後端 Serverless 服務接收到使用者的抽獎請求時，會：
- 擷取使用者賬号下的 Serverless 服務發起抽獎請求時所傳遞 uid 資訊；
- 使用獲得到的 uid 資訊在臨時域名下發系統中進行資料比對，确定使用者本次使用了臨時域名下發系統，并下發了對應的域名；
- 實作抽獎操作；
抽獎核心實作
在抽獎操作的過程中，也是對目前系統進行了初步的評估，設定了一個簡單的，易于實作的，可以針對小規模抽獎活動的抽獎功能：
關于這一部分，Django項目的實作方法：
@csrf_exempt
def prize(request):
uid = request.POST.get("uid", None)
if not uid:
return JsonResponse({"Error": "Uid is required."})
temp_url = "<擷取uid的合法性和有效性，重要判斷依據>?uid=" + str(uid)
if json.loads(urllib.request.urlopen(temp_url).read().decode("utf-8"))["Response"] == '0':
token = randomStr(10)
# 擷取當日獎品
prizes = {}
for eve_prize in PrizeModel.objects.filter(date=time.strftime("%Y-%m-%d", time.localtime())):
prizes[eve_prize.name] = {
"count": eve_prize.count,
"rate": eve_prize.rate
}
# 建構抽獎池
prize_list = []
for evePrize, eveInfo in prizes.items():
temp_prize_list = [evePrize, ] * int((100 * eveInfo['rate']))
prize_list = prize_list + temp_prize_list
none_list = [None, ] * (100 - len(prize_list))
prize_list = prize_list + none_list
pre_prize = random.choice(prize_list)
# 資料入庫
try:
UserModel.objects.create(uid=uid,
token=token,
pre_prize=pre_prize,
result=False)
except:
if not UserModel.objects.get(uid=uid).result:
return JsonResponse({"Result": "0"})
pass
return JsonResponse({"Error": "Everyone can only participate once."})
if not pre_prize:
user_id = UserModel.objects.get(uid=uid, token=token).id
users_count = UserModel.objects.filter(pre_prize=pre_prize, id__lt=user_id, date=time.strftime("%Y-%m-%d", time.localtime())).count()
# 是否獲獎的最終判斷
if users_count >= prizes.get(pre_prize, {}).get("count", 0):
UserModel.objects.filter(uid=uid, token=token).update(result=True)
return JsonResponse({"Result": {
"token": token,
"prize": pre_prize
}})
系統安全設定
當使用者中獎之後，系統會生成一個token，該token與uid的組合，是用來判斷使用者是否中獎的重要依據，這裡可能涉及到一個問題：什麼有了uid，還要增加一個token來進行組合判斷呢？其實原因很簡單的，送出中獎資訊和查詢中獎資訊，如果是通過uid來直接進行處理的，那麼很有可能會有使用者通過周遊等手段，非法擷取到其他使用者送出過的資訊，而這一部分資訊很有可能涉及到使用者送出的收貨位址等，是以為了安全，增加了一個token，在一定程度上，提升了被暴力周遊的複雜度。而這一部分的方法也很簡單：
def information(request):
uid = request.GET.get("uid", None)
token = request.GET.get("token", None)
if None in [uid, token]:
return JsonResponse({"Error": "Uid and token are required."})
userInfor = UserModel.objects.filter(uid=uid, token=token)
if userInfor.count() == 0:
return JsonResponse({"Error": "No information found yet."})
if not userInfor[0].result:
return JsonResponse({"Error": "No winning information has been found yet."})
if request.method == "GET":
return JsonResponse({
"Result": {
"prize": userInfor[0].pre_prize,
"name": userInfor[0].name,
"phone": userInfor[0].phone,
"address": userInfor[0].address
})
elif request.method == "POST":
name = request.POST.get("name", None)
phone = request.POST.get("phone", None)
address = request.POST.get("address", None)
if None in [name, phone, address]:
return JsonResponse({"Error": "Name, phone and address are required."})
userInfor.update(name=name,
phone=phone,
address=address)
return JsonResponse({"Result": "Saved successfully."})
整個流程是：
- 通過使用者的uid和token進行相關使用者資訊的擷取；
- 如果請求方法是GET方法，那麼則直接傳回使用者的中獎資訊（指的是收貨資訊）；
- 如果請求方法是POST方法，則允許使用者進行中獎資訊的修改（指的是收貨資訊）；
其他安全方面的補充：
- 如何保證使用者的token等資訊的唯一性以及不可僞造性，這一部分在浏覽器端是不太容易實作的，因為使用者可能換浏覽器，但是對于使用者的在函數計算平台的函數服務中就相對容易實作了，是以采用域名下發階段，對指定時間段下發過的域名資訊進行記錄，再在後期進行對比，以保證使用者确實通過Serverless Devs開發者工具進行了項目部署，下發了臨時域名，并在規定的時間内參加了活動；（當然，如果使用者注冊了多個阿裡雲賬号，進行該活動的參加，這個時候是被允許的）
- 如何保證獎品不會被超發，這一部分在該系統中，采用了一個比較”笨“的方法，但是也是針對小型平台更容易實作的方法，即先給使用者一個獎品标記，然後再根據使用者獎品在資料庫中的時序位置，進行最終中獎資訊的判斷，例如，使用者中獎一個機械鍵盤，在資料庫中是中機械鍵盤的第6位置，但是一共隻有5個機械鍵盤，是以此時會對使用者的中獎資訊二次核對并标記未中獎。（當然，這種做法針對小規模活動是可以的，但是針對大型活動是不可取的，因為使用者是否中獎這件事情，會導緻多次資料庫的讀寫操作，在一定程度上是不合理的）
- 使用者中獎之後，送出了獎品郵寄資訊，如何保證該資訊的安全性，不被其他人暴力周遊出來也是值得關注的問題，此處采用增加了一個随機token，以增加被暴力周遊出來的複雜度，進一步保障安全；
部署準備工作
本次部署無需域名，使用函數計算生成的自定義域名即可，依然需要安裝好 Serverless Devs 工具，本次隻需開通函數計算即可。
操作步驟
搖獎背景的部分模闆還在準備中，僅示範部署前端和資料層的服務。
步驟1：秘鑰配置
參考Serverless devs 阿裡雲秘鑰配置
步驟2：初始化
使用serverless devs 指令行工具執行:
s init blindbox-game
進入引導式操作：
步驟3：建構部署
修改一下相關的配置資訊，執行s deploy
效果檢視
函數部署情況：
頁面效果：
搖獎部分的應用模闆正在準備中，後續也會統一在這個應用模闆給大家提供展示。
結語
上面實踐結束後關于低代碼和 Serverless 這個話題想跟大家再展開一下，以下部分并會以理論性為主，希望能夠給讀者帶來不一樣的收獲。
開發者視角的 Serverless + 低代碼
就我自身而言的話，明确的結論是我并不排斥兩者的相容，反而非常期待這兩者結合能夠進一步讓我的工作更加高效，安全。
本次活動我的最大感觸是，如果低代碼平台能夠跟 Serverless 無縫銜接就好了，比如我在低代碼上調用接口現在隻能建構發到線上之後才能測試，這點天然內建好的平台優勢就會很明顯。另外就是釋出建構好前端之後還得再去跟後端接口組裝，這個如果是統一平台的話搞完需求就可以一鍵釋出，會省不少事。不過這裡也比較沖突，因為我也擔心一旦低代碼的前端跟 Serverless 的後端耦合在一起就會變得不靈活，被服務商鎖定。
供應商視角的 Serverless + 低代碼
可以看到現在雲服務商的 Serverless 和低代碼的服務商在互相融合。比如低代碼平台上司者 outsystem 早在 2016 年就開始使用 AWS 的服務，比如 Lambda 等為他們的客戶提供原生 APP 服務的建構。
以 serverless & model-driven application 作為主體服務的低代碼平台 Trillo 則是以 Google 雲服務構為基礎幫助他們的使用者建構 Serverless 服務和前端應用，當然國内外的各家雲廠商也沒閑着 Azure 将自家的低代碼産品 Power Apps 融入了 Serverless 的能力形成 Serverless Power Apps，将二者的優勢做了充分融合。
Aws 将前端的內建都交給了夥伴，自身更專注于服務側的 Serverless 內建，并且推出了 Step Functions Workflow Studio 産品将 Serverless 跟自家幾乎所有的産品串聯到了一起。
國内騰訊推出了微搭低代碼平台，也是主打 Serverless + 低代碼，在小程式場景發力，各廠商的跟進也說明了對這個領域的重視。
打造 Serverless + 低代碼平台的設想
Serverless + 低代碼平台的價值是比較明确的，效率，安全，成本都是它的關鍵詞。那麼假設我們要去建設這樣的平台需要做哪些方面的考慮呢？
首先是從平台能力上，應該要做到能夠覆寫一個應用開發從前到後的方方面面。比如：
- 資料模組化
- 資料模型 API 化
- 使用 Serverless 建構後端應用邏輯
- 支援部署 Long-Runing 的後端服務
- 可擴充的外部服務內建
- 檔案存儲
- 邏輯編排
- 各種安全能力比如身份驗證，權限控制等
- UI 編排
- CI/CD
- 應用可觀測
這裡可以簡單理一下這個平台的功能設計，依托于雲廠商的基礎設施建構相應的能力。
相關的低代碼能部分的能力有一些相關的開源産品，這裡可以分享給大家：
- ui 頁面搭建https://github.com/alibaba/designable
- 資料庫模組化https://gitee.com/robergroup/chiner
- 流程編排https://github.com/i5ting/imove
另外跟雲基礎設施打通部分可以考慮利用 Serverless Devs 的 Iac 能力，尤其是目前在跟 FC 的內建上成熟度比較高，可以很友善的對函數全生命周期進行管理。
當然以上僅是筆者的一些設想，我深知實作這樣的系統絕非易事，這裡也隻是抛轉引玉用。
追求生産效率的提升始終是企業生産的重要話題，Serverless 和低代碼在各自的技術領域上有着獨立的分工，卻也有着共同的提高生産效率的特性，學會同時掌握利用好這兩個生産力工具或許會是從事資訊産業同學的重要競争力。
原文連結：301 Moved Permanently
本文為阿裡雲原創内容，未經允許不得轉載。