共计 4948 个字符,预计需要花费 13 分钟才能阅读完成。
“美术狮 AI 绘画”(以下简称“美术狮”),是咱们小团队的一次尝试,定位是人人都能够上手的,充斥创意的,了解中文和中国文化的图片生成工具。
在欠缺图像模型和论证外围问题之后,咱们开始构建 MVP(最小化可行产品)。MVP 的构建须要:
- 实现快,开发周期较短
- 模式轻,产品重点突出
- 成本低,只投入较少的人力、物力
这些指标,对于咱们而言都是不小的挑战。得益于 Laf 的应用,从开发到第一个版本上线,只用了一周工夫 ; 小程序性能精简、指标清晰 ;主体服务 老本(杭州 + 新加坡)在 100 元 / 月以内(含有优化空间)。
上面会联合“美术狮”MVP 构建的全过程,和大家交换应用 Laf 这个平台(技术)的思考。
原文链接:https://forum.laf.run/d/984
技术选型过程
函数即服务 ,是目前咱们对 Laf 范式 的思考和了解。也是“美术狮”抉择 Laf 作为服务端的次要因素。
我在 2015 年就接触了“相似”的 BaaS 平台 LeanCloud,并做过两次实际。第一次是对爬取的小红书内容做保护,第二次是给一个中科院的敌人做化学试剂编号的治理。
LeanCloud,偏差于 数据库即服务 这种范式,对数据增删改查,提供基于数据的丰盛的查问、聚合运算办法是这个范式的外围。
范式无优劣之分,取决于须要解决的问题 场景、复杂度和规模 。对于以 数据库为核心 的,蕴含简略鉴权的零碎比方 CRM、甚至是 ERP,LeanCloud 都能够很好地适应和匹配。
咱们还尝试和理解过主打实时性的 野狗云 (已下线),以及起初上线一段时间又被字节跳动下线的 轻服务(已下线)。也尝试过跟着教程应用 Firebase。
“美术狮”或者其余的 AI 利用的理论应用场景中,数据库的操作只是一个局部,简单的内容生成逻辑、多平台资源调度、绝对密集的计算 是这类场景中的 重心。
小程序自身,尽管运行在客户端内领有肯定的计算能力,然而把它看作一个 加强的 BS 构造 通用性会更好,咱们须要 把大量地生成逻辑和计算解决流程剥离进去放在服务端由多平台协同实现;同时为了减小散发包的大小,当须要蕴含其余 SDK 文件时,咱们也会分外审慎。
因而,数据库即服务,并不能很好地解决咱们所面临的问题,可能并不是 AICG 利用优先会抉择的范式。
腾讯云函数(Serverless)
接下来尝试了应用腾讯云函数,能满足了咱们的一部分需要。
然而对于单次计算绝对密集,调用资源繁多,访问量不稳固的利用而言。冷启动是可怕的 ,服务被冷却后,再一次被拉起来须要较长地等待时间。在 并发和访问量不大时,云函数被频繁地冷却,对用户体验挫伤较大,较为致命。这个对于每一个从 0 到 1 的独立开发者可能都是个头疼的问题。
对存储桶、数据库,腾讯云函数并没有做深度地整合,独自配置云数据库、存储桶,会在 MVP 阶段减少不必要的工夫和费用的开销。
微信云开发
微信云开发能够通过微信开发者工具一键开明。在“美术狮”迁徙的 Laf 之前,咱们在微信云开发中做了大量的尝试。
放弃应用微信云开发,次要是上面一些起因:
- 根底库 Node 版本过低,对第三方包反对不好;
- IDE 开发体验不好,写代码像是看 PPT,本地调试不够不便直观;
- 计费零碎诡异,尽管咱们是腾讯云的老用户,小程序无奈在原有账户中开明服务,必须以小程序的维度新开通账户,付费和治理保护不不便;
- 对跨区域、跨服务反对不佳;
- 冷启动提早仍然显著。
通过内置的鉴权机制疾速获取 openid,是微信云开发声称的劣势。
在“美术狮”产品迁徙后到 Laf 后,联合社区教程,也能够在“3 分钟”内,实现实现这些性能。
从 0 写一个微信小程序对接 Laf 云开发获取用户 openid – Sealos 开发者社区
Supabase、Vercel、Cloudflare
Verce、Cloudflare 是我特地喜爱的两个平台,这里一笔带过。次要起因是无奈整合到国内的网络环境中。
最终咱们抉择了 Laf。在应用 Laf 的过程中,咱们取得简直等同于 Woker、EdgeFunction 的应用体验和开发效率。
为什么抉择 Laf?
函数即服务
Laf 最吸引咱们的,是通过 云函数 的构建利用的形式。
函数即服务 在肯定水平上,是能够容纳(蕴含)数据库即服务 这个范式的。
传统的 Server 端开发,通过 Router
和 Controller
去组织代码,利于治理和保护。然而,从另一个层面看,会在肯定水平上,升高了 MVP 产品的开发效率,妨碍了翻新的落地。
“美术狮”在第一个版本上线前半个小时,决定增加一个每日签到的性能。
通过云函数,咱们更聚焦新个性、新性能,而不是困在这个签到性能应该放在哪个 Router 下,哪个 Controller 下这些工程治理的思考中。通过定义一个 task_user_daily_check_in
,咱们很快地实现了这个性能。
云函数调用云函数,是另外一个我喜爱的个性,咱们定义了若干个“外部”云函数(同时敞开了所有 HTTP 办法),来为其余云函数服务。比方获取第三方服务的 access token
并在本地长久化。一方面,代码可能解耦和复用,另一方,安全性也大大晋升。
例如这段代码,获取百度云服务的 access token
,敞开申请办法后,仅能被外部调用。
import cloud from '@lafjs/cloud'
export default async function (ctx: FunctionContext) {
const ret = await cloud.fetch({
url: "https://aip.baidubce.com//oauth/2.0/token?",
method: "get",
params: {
'grant_type': 'client_credentials',
'client_id': process.env.BAE_CLIENT_ID,
'client_secret': process.env.BAE_CLIENT_SECRET
},
});
cloud.shared.set('bae_access_tooen', ret.data.access_token)
}
当然,云函数过多后,仅能通过批改函数名去人为地调整云函数的排序,目录构造会显得凌乱,如果能依照 Tag(虚构文件夹)去聚合、治理云函数,对我而言,会更清晰和直观。
技术栈敌对
Laf 应用 Typescript
(Javascript
)进行开发,与 web 端、小程序开发属于同一技术栈。大大 升高了全栈开发的难度 ,同时 绝大多数代码能够在两端进行复用。
在防止探讨“谁是世界上最好的编程语言”的前提下,仅从团队、老本、开发效率几个方面探讨,统一的技术栈 是 MVP 开发的一个好抉择。
良好地第三方反对
Laf 对 第三方 NPM
包的反对很好。我尝试过援用 moment
等这些第三方库解决工夫数据,七牛 等第三方服务解决图片资源,同时内置了大量罕用的第三方库。
如同 乐高拼图,云函数能够一直地、从不同维度地整合和丰盛。存在大量第三方依赖的我的项目,迁徙时老本较低。
实测,秒下各类第三方 NPM 包,精准版本控制,不须要“魔法”。
开箱即用的数据库
Laf 内置了对 Mongodb
的良好反对,提供了一个开箱即用的数据库。够用,好用。
Laf 除了提供大量封装后的查问、聚合办法外,也提供了与原生 Mongo
交互的接口。
例如:通过与原生数据库交互创立索引。
import cloud from "@lafjs/cloud";
const db = cloud.database()
export async function main(ctx: FunctionContext) {let res = await cloud.mongo.db.collection('users').createIndex({"openid": 1})
const resIndexs = await cloud.mongo.db.collection("users").indexes()
return resIndexs
};
便当、直观的在线调试
在 Laf 中通过控制台、日志,能够实现绝大部分的调试工作。简单一点的操作能够通过内置的 极简 的 Postman(接口调试)去实现。
这种 极简、老练 的格调贯通 Laf 的性能(也包含下面提到的数据库设计)、UI,是咱们 fancy Laf 的另一个重要起因。
理论的应用过程中,除了“存储”这个性能,其余所有的功能区,面板都能被咱们高频地应用到。聚焦指标,专一效率,冗余度低。
杭州、新加坡两地部署
在“美术狮”的开发过程中,咱们在 laf.run(杭州)、laf.dev(新加坡)别离购买和部署了 Laf。多服务融合、跨区域的开发是一种微妙的体验。
“美术狮”在图片的生成过程中,利用了腾讯云在新加坡的 GPU,图片的存储、优化又在国内实现,最终由七牛提供长久化和 CDN 服务。
Laf 在杭州与新加坡之间 通信通顺,可用性 高,与其余第三方平台可能完满地整合。
一键弹性伸缩
得益于同门的 Sealos
等我的项目和 Laf
在云计算方面的深耕,Laf 能够一键配置利用规格和弹性伸缩。
尽管,有数的产品默默地隐没了,除非被 DDOS,很多产品很难触发弹性伸缩的条件(比方“美术狮”),然而幻想总是要有的。
短时间的高平发须要业余的运维,极快地做出程度拓展,对于小团队而言,在技术、资金方面都很难做到。Laf 很好地解决了这个后顾之忧,给咱们提供了莫大的安全感,这个方面,我会在前面的局部持续补充。
开源、凋谢
Laf 与我应用过的其余 BaaS 不同,是一个开源我的项目。
之前有幸和 @ 马斯洛 有过一次对话,马老板是一个高深、有远见的 Leader。
如果一个我的项目只隶属于一个公司,那么这个我的项目的命运大抵会捆绑在这个公司的命运上。而一个我的项目属于社群,哪怕公司没有了,我的项目依然能倒退、欠缺。
开源的决定让 Laf 领有了更长的生命周期和可靠性。用户再也不必放心像“轻服务”忽然下线这种事件的产生,能够更释怀地实际和应用平台和技术。
另外,不到万不得已,我不会去尝试部署 Laf 的服务。我有一堆本人的理由:
- 牢靠和稳固可能节俭更多的老本,自部署相当于本人承当服务的可靠性,很多人的专业性和运维能力并不足以实现这个工作;
- 我的项目的维护者们更理解我的项目,也能更好、更快地解决突发问题;
- Laf 的局部个性,是靠集群施展的,购买和保护集群的老本会更高;
- 向开源我的项目付费、奉献代码,是对开发者很好地激励和反对。
良好用户经营和免费
在应用了 Laf 的过程中,曾遇到一个无奈为文档创立索引的故障。@ 白夜 帮忙分割了 @ 马斯洛 后,很快解决了我的问题。绝大多数问题能够在文档和社区找到解答和 代码片段。
咱们反馈过心愿有一个“回收站”的性能。Laf 迭代更新后,回收站如期而至,作为用户,想法被聆听、尊重并实现真是一件开心的事件。
之前对 Laf 的配置不足理解,在后盾调整了过高的配置。马老板 会把理论资源耗费状况和倡议调整值通知我,每一次沟通都能让咱们感触到技术大牛的魅力和一颗为用户着想的心。
共计下来,价廉物美,比一台中等配置的云服务器性价比高很多,同时,我也不必放心可能会到来的流量顶峰,我置信 Laf 业余的运维肯定会解决“美术狮”将来会遇到的问题。
番外篇
咱们是 Midjourney 和 SD 的忠诚粉丝。“美术狮”这个名称是 GPT-4 出谋划策的,小程序 Logo 和局部图片资源也是由“美术狮”生成的。
在应用 Mid 和 SD 的过程中,咱们发现两个问题:
- 精确的 Prompts 须要应用英文书写,特定的英文词汇须要记忆、积攒(比方格调、镜头、视角等);
- Prompts 须要通过结构化排列,关键词的程序也会影响出图品质,同时创作者须要具备肯定的美术、摄影方面的业余素养。
身边能把 Mid 或者 SD 用好的人少之又少;一个是语言问题,一个是业余问题。
咱们以 Dalle2 模型,作为训练终点,没错,就是画面惨不忍睹的 Dalle2,尽管如此,Dalle 是目前绘画模型中最懂自然语言的。
Prompts 是文字,由图片 describe
出的 Tag
也是文字,语言文字是信息沟通最重要的媒介,大语言模型更是这次 AI 浪潮的基石。
咱们通过 3 个多月,晋升了“美术狮”对自然语言特地是中文的了解,让它更灵动、更懂你,只管还有诸多不完满,过程中依然带给咱们许多惊喜。
咱们团队在当前的实际中,会持续应用 Laf,应用 Laf 是高兴的事件。心愿越来越多的人可能感触到 Laf 的魅力。也心愿 Laf 今天会更好。