![](https://intranetproxy.alipay.com/skylark/lark/0/2022/webp/22456429/1644462478048-b8f9965a-245e-4be9-9d2b-54445ea61b60.webp#clientId=u835603d7-532a-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u0b912901&margin=%5Bobject%20Object%5D&originHeight=469&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u249ab129-01a4-4b5b-bc43-8349e7111ca&title=)
作者 | 寒斜 & 江昱

當 Serverless 與低程式碼這兩個不同的技術共同相交於同一個業務時會有怎樣的價值展現？本文以 “盲盒抽獎”  這個 Serverless Devs 做過的創意營銷活動為例，為大家講述 Serverless 和低程式碼是如何搭配來滿足一個業務訴求的。
# 前言

線上 H5 創意動畫結合線下實體獎勵是網際網路營銷活動的一種常見手段。為了抓住關鍵時間節點，活動從策劃到落地的週期一般都比較短，短時間內落地線上服務對於做技術開發的同學有著不小的挑戰。

尤其是當有更多需求，比如增加後臺管理以及關鍵前端訪問資料埋點等需求時，挑戰難度往往會加倍。對於開發而言除了完成業務核心訴求，往往還需要關注非業務訴求以外的其他狀況，比如系統訪問安全，高併發流量應對，系統執行指標可觀測等。

在以前這類需求往往需要跟多的角色參與，如產品，前端，後端，設計，測試，運營，運維等，使得投入產出比變得比較低，活動持續性比較差。今天使用 Serverless + 低程式碼的技術我們可以大幅縮減做此類活動的成本，讓它變成持續性的活動，從而大大提高運營效果。

實際上 Serverless Devs 此次的盲盒抽獎活動僅僅投了 3.5 個人，便完成了活動策劃，產品設計, 前後端實現，系統部署運維等工作。並且藉助於 Serverless 的服務能力，輕鬆應對了系統訪問安全，高併發流量，系統可觀測等這些非業務挑戰。功能性的補齊 + 效率提升，讓本次運營取得了非常好的收益，活動服務的模板化沉澱又為後續同類活動奠定好了良好的基礎。

“盲盒抽獎” 活動的整體流程如下：

1. 需求設計（含業務邏輯和互動邏輯）
1. 設計稿
1. 低程式碼實現前端
1. 編碼實現 Serverless 服務
1. 聯調測試
1. 部署上線
1. 活動中問題修復
1. 活動後覆盤
### 應用效果預覽：

![](https://intranetproxy.alipay.com/skylark/lark/0/2022/webp/22456429/1644462478094-62652631-ba40-4e71-be41-e5d649f0f35a.webp#clientId=u835603d7-532a-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u74627183&margin=%5Bobject%20Object%5D&originHeight=1176&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u0a779194-cef9-462d-a9bc-d398d7c6d79&title=)

“1 分鐘 Serverless 極速部署盲盒” 抽獎活動目前已經結束，但是感興趣的同學仍可以體驗一下：

https://developer.aliyun.com/adc/series/serverless2

### 架構預覽：
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/webp/22456429/1644462478051-1dea14bc-6fd3-4a69-aeef-6c9b3188c3d4.webp#clientId=u835603d7-532a-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=uc9b59360&margin=%5Bobject%20Object%5D&originHeight=494&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u77811748-4cad-4938-9b85-9d6d616505b&title=)
本次的部署架構沒有使用[阿里雲API閘道器](https://www.aliyun.com/search?scene=all&k=api%E7%BD%91%E5%85%B3&scm=20140722.S_api%E7%BD%91%E5%85%B3._.ID_api%E7%BD%91%E5%85%B3-RL_api-LOC_bar-OR_ser-V_2-P0_0)，而是直接用[函式計算](https://help.aliyun.com/product/50980.html) [Custom Runtime](https://help.aliyun.com/document_detail/132044.html) 作為託管形態，這樣做是因為本次需求的特殊性，我們是**“自己部署自己抽”**，實際上意味著端側訪問是非中心化的，端側訪問的服務做的也比較薄，只是資料處理介面呼叫和提供靜態渲染服務，後經過一箇中心化的邏輯後臺處理中獎機率，管理獎品查詢資料庫等。

![](https://intranetproxy.alipay.com/skylark/lark/0/2022/webp/22456429/1644462478069-7c6decb3-92db-4e7a-8b5a-2f0658b70b45.webp#clientId=u835603d7-532a-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=DwQEj&margin=%5Bobject%20Object%5D&originHeight=552&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u62d8d181-61ca-4aea-b967-c06cd7be7c0&title=)

如果您是自己做中心化的的活動後臺的話建議參考下面的架構模式，採用 [API閘道器](https://www.aliyun.com/search?scene=all&k=api%E7%BD%91%E5%85%B3&scm=20140722.S_api%E7%BD%91%E5%85%B3._.ID_api%E7%BD%91%E5%85%B3-RL_api-LOC_bar-OR_ser-V_2-P0_0)作為流量入口。方便做更多的安全限制以及更靈活的擴充套件

# 實現解析

### 前端互動低程式碼實現

本次前端實現使用低程式碼工作 hype4，hype4 的具體使用這裡不做詳細介紹，有興趣的同學可以自行搜尋。

設計稿除了之後將需要的圖切出來，然後跟處理 Flash 一樣將動畫效果實現，最後就是新增 js 程式碼實現介面訪問，場景切換等能力。整個流程會比全編碼要快很多，尤其是動效實現上比純手寫效率高 2-3 倍。
####

### 資料層 Serverless 服務

如架構所示，這裡的資料層實際上就是我們理解的 SSF ，這層僅做資料轉發和靜態的渲染。程式碼實現比較簡單，採用 express 框架，然後以函式計算 Custom runtime 形式部署。

目的是為了這個服務既可以託管靜態內容也可以做動態的資料轉發。值得注意的是，使用者的資訊獲取也是在這層實現的。

![](https://intranetproxy.alipay.com/skylark/lark/0/2022/webp/22456429/1644462478419-0f816c74-549a-4ed0-bbb9-10dec9f6a864.webp#clientId=u835603d7-532a-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u19be7319&margin=%5Bobject%20Object%5D&originHeight=660&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u8ab3e72e-672e-4547-819f-b2b36f40aa3&title=)

這裡我們獲取的是阿里雲使用者的 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 服務接收到使用者的抽獎請求時，會：

1. 獲取使用者賬號下的 Serverless 服務發起抽獎請求時所傳遞 uid 資訊；
   1. 使用獲得到的 uid 資訊在臨時域名下發系統中進行資料匹配，確定使用者本次使用了臨時域名下發系統，並下發了對應的域名；
   1. 實現抽獎操作；

### 抽獎核心實現

在抽獎操作的過程中，也是對當前系統進行了初步的評估，設定了一個簡單的，易於實現的，可以針對小規模抽獎活動的抽獎功能：
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/13970/1644213213461-d2068965-5b0b-4454-952c-23b685f2d377.png#clientId=ua8d7c67e-330e-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=182&id=VJ3Rl&margin=%5Bobject%20Object%5D&name=image.png&originHeight=363&originWidth=1500&originalType=binary&ratio=1&rotation=0&showTitle=false&size=114248&status=done&style=none&taskId=u74632859-ee48-4ba5-a4a6-4c05bca6c41&title=&width=750)
關於這一部分，Django專案的實現方法：
```
@csrf_exempt
def prize(request):
    uid = request.POST.get("uid", None)
    if not uid:
        return JsonResponse({"Error": "Uid is required."})

temp_url = "?uid=" + str(uid)
    if json.loads(urllib.request.urlopen(temp_url).read().decode("utf-8"))["Response"] == '0':
        return JsonResponse({"Error": "Uid is required."})

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:
        try:
            if not UserModel.objects.get(uid=uid).result:
                return JsonResponse({"Result": "0"})
        except:
            pass
        return JsonResponse({"Error": "Everyone can only participate once."})
    if not pre_prize:
        return JsonResponse({"Result": "0"})
    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):
        return JsonResponse({"Result": "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`，在一定程度上，提升了被暴力遍歷的複雜度。而這一部分的方法也很簡單：

```
@csrf_exempt
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."})
```
整個流程是：

1. 透過使用者的`uid`和`token`進行相關使用者資訊的獲取；
1. 如果請求方法是GET方法，那麼則直接返回使用者的中獎資訊（指的是收貨資訊）；
1. 如果請求方法是POST方法，則允許使用者進行中獎資訊的修改（指的是收貨資訊）；

其他安全方面的補充：

1. 如何保證使用者的token等資訊的唯一性以及不可偽造性，這一部分在瀏覽器端是不太容易實現的，因為使用者可能換瀏覽器，但是對於使用者的在函式計算平臺的函式服務中就相對容易實現了，所以採用域名下發階段，對指定時間段下發過的域名資訊進行記錄，再在後期進行對比，以保證使用者確實透過Serverless Devs開發者工具進行了專案部署，下發了臨時域名，並在規定的時間內參加了活動；（當然，如果使用者註冊了多個阿里雲賬號，進行該活動的參加，這個時候是被允許的）
1. 如何保證獎品不會被超發，這一部分在該系統中，採用了一個比較”笨“的方法，但是也是針對小型平臺更容易實現的方法，即先給使用者一個獎品標記，然後再根據使用者獎品在資料庫中的時序位置，進行最終中獎資訊的判斷，例如，使用者中獎一個機械鍵盤，在資料庫中是中機械鍵盤的第6位置，但是一共只有5個機械鍵盤，所以此時會對使用者的中獎資訊二次核對並標記未中獎。（當然，這種做法針對小規模活動是可以的，但是針對大型活動是不可取的，因為使用者是否中獎這件事情，會導致多次資料庫的讀寫操作，在一定程度上是不合理的）
1. 使用者中獎之後，提交了獎品郵寄資訊，如何保證該資訊的安全性，不被其他人暴力遍歷出來也是值得關注的問題，此處採用增加了一個隨機token，以增加被暴力遍歷出來的複雜度，進一步保障安全；

# 部署準備工作

本次部署無需域名，使用函式計算生成的自定義域名即可，依然需要安裝好 Serverless Devs 工具，本次只需開通函式計算即可。

### 操作步驟
搖獎後臺的部分模板還在準備中，僅演示部署前端和資料層的服務。
#### 步驟1：秘鑰配置
參考[Serverless devs 阿里雲秘鑰配置](http://www.serverless-devs.com/zh-cn/docs/provider-config/alibabacloud.html)
#### 步驟2：初始化
使用serverless devs 命令列工具執行
```tsx
s init blindbox-game
```
進入引導式操作：

![](https://intranetproxy.alipay.com/skylark/lark/0/2022/gif/22456429/1644462478475-9946de2b-a8c7-407d-84e9-fb2f31837516.gif#clientId=u835603d7-532a-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u17902c8a&margin=%5Bobject%20Object%5D&originHeight=579&originWidth=1078&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u324fc892-7a11-4cd0-b775-398502cc9b1&title=)
####

#### 步驟3：構建部署
修改一下相關的配置資訊，執行**s deploy**
![blindbox2.gif](https://intranetproxy.alipay.com/skylark/lark/0/2022/gif/13970/1642661674710-f1712430-38fd-43cd-ae3d-cb253f90c40d.gif#clientId=u95e360d9-d8d0-4&crop=0&crop=0&crop=1&crop=1&from=drop&id=E6EAC&margin=%5Bobject%20Object%5D&name=blindbox2.gif&originHeight=954&originWidth=1777&originalType=binary&ratio=1&rotation=0&showTitle=false&size=6720517&status=done&style=none&taskId=u491353b5-316d-4d5f-8ebe-83df9d83234&title=)
# 效果檢視

函式部署情況：
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/13970/1642661769188-fa4a4ffe-e3a5-4d90-b92f-1b2224e6baa5.png#clientId=u95e360d9-d8d0-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=821&id=l4p1x&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1642&originWidth=3532&originalType=binary&ratio=1&rotation=0&showTitle=false&size=553969&status=done&style=none&taskId=u9dbf7ede-a423-494c-b646-5a6f7abf58e&title=&width=1766)
頁面效果：
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/13970/1642661812607-0406bfbb-d5df-4344-b7cc-0b085955d826.png#clientId=u95e360d9-d8d0-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=896&id=LNcCu&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1792&originWidth=742&originalType=binary&ratio=1&rotation=0&showTitle=false&size=2029440&status=done&style=none&taskId=uee486a91-6f0d-4f6b-979f-3dc5d69bce8&title=&width=371)

搖獎部分的應用模板正在準備中，後續也會統一在這個應用模板給大家提供展示。
# 結語

上面實踐結束後關於低程式碼和 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
- 應用可觀測

這裡可以簡單理一下這個平臺的功能設計，依託於雲廠商的基礎設施構建相應的能力。

![](https://intranetproxy.alipay.com/skylark/lark/0/2022/webp/22456429/1644462478974-a9394f7b-a6fc-440d-8c84-50031f331957.webp#clientId=u835603d7-532a-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=uc0816444&margin=%5Bobject%20Object%5D&originHeight=639&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ue525be33-a801-47d2-847d-78b7aafa359&title=)

相關的低程式碼能部分的能力有一些相關的開源產品，這裡可以分享給大家：

- ui 頁面搭建https://github.com/alibaba/designable
- 資料庫建模https://gitee.com/robergroup/chiner
- 流程編排https://github.com/i5ting/imove

另外跟雲基礎設施打通部分可以考慮利用 Serverless Devs 的 Iac 能力，尤其是目前在跟 FC 的整合上成熟度比較高，可以很方便的對函式全生命週期進行管理。

當然以上僅是筆者的一些設想，我深知實現這樣的系統絕非易事，這裡也只是拋轉引玉用。

追求生產效率的提升始終是企業生產的重要話題，Serverless 和低程式碼在各自的技術領域上有著獨立的分工，卻也有著共同的提高生產效率的特性，學會同時掌握利用好這兩個生產力工具或許會是從事資訊產業同學的重要競爭力。

人人都是 Serverless 架構師之 “盲盒抽獎”創意營銷活動實踐

相關文章