共计 7443 个字符，预计需要花费 19 分钟才能阅读完成。
简介：当 Serverless 与低代码这两个不同的技术独特相交于同一个业务时会有怎么的价值展示？本文以“盲盒抽奖”这个 Serverless Devs 做过的创意营销流动为例，为大家讲述 Serverless 和低代码是如何搭配来满足一个业务诉求的。
作者 | 寒斜 & 江昱
当 Serverless 与低代码这两个不同的技术独特相交于同一个业务时会有怎么的价值展示？本文以“盲盒抽奖”这个 Serverless Devs 做过的创意营销流动为例，为大家讲述 Serverless 和低代码是如何搭配来满足一个业务诉求的。
前言
线上 H5 创意动画联合线下实体处分是互联网营销流动的一种常见伎俩。为了抓住要害工夫节点，流动从策动到落地的周期个别都比拟短，短时间内落地线上服务对于做技术开发的同学有着不小的挑战。
尤其是当有更多需要，比方减少后盾治理以及要害前端拜访数据埋点等需要时，挑战难度往往会加倍。对于开发而言除了实现业务外围诉求，往往还须要关注非业务诉求以外的其余情况，比方零碎拜访平安，高并发流量应答，零碎运行指标可观测等。
在以前这类需要往往须要跟多的角色参加，如产品，前端，后端，设计，测试，经营，运维等，使得投入产出比变得比拟低，流动持续性比拟差。明天应用 Serverless + 低代码的技术咱们能够大幅缩减做此类流动的老本，让它变成持续性的流动，从而大大提高经营成果。
实际上 Serverless Devs 此次的盲盒抽奖流动仅仅投了 3.5 集体，便实现了流动策动，产品设计, 前后端实现，零碎部署运维等工作。并且借助于 Serverless 的服务能力，轻松应答了零碎拜访平安，高并发流量，零碎可观测等这些非业务挑战。功能性的补齐 + 效率晋升，让本次经营获得了十分好的收益，流动服务的模板化积淀又为后续同类流动奠定好了良好的根底。
“盲盒抽奖”流动的整体流程如下：
- 需要设计（含业务逻辑和交互逻辑）
- 设计稿
- 低代码实现前端
- 编码实现 Serverless 服务
- 联调测试
- 部署上线
- 流动中问题修复
- 流动后复盘
利用成果预览：
“1 分钟 Serverless 极速部署盲盒”抽奖流动目前曾经完结，然而感兴趣的同学仍能够体验一下：
https://developer.aliyun.com/…
架构预览：
本次的部署架构没有应用阿里云 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':
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."})
整个流程是：
- 通过用户的 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/de…
- 数据库建模 https://gitee.com/robergroup/…
- 流程编排 https://github.com/i5ting/imove
另外跟云基础设施买通局部能够思考利用 Serverless Devs 的 Iac 能力，尤其是目前在跟 FC 的集成上成熟度比拟高，能够很不便的对函数全生命周期进行治理。
当然以上仅是笔者的一些构想，我深知实现这样的零碎绝非易事，这里也只是抛转引玉用。
谋求生产效率的晋升始终是企业生产的重要话题，Serverless 和低代码在各自的技术畛域上有着独立的分工，却也有着独特的进步生产效率的个性，学会同时把握利用好这两个生产力工具或者会是从事信息产业同学的重要竞争力。
原文链接
本文为阿里云原创内容，未经容许不得转载。
