背景
成都创新互联专注于企业成都全网营销、网站重做改版、武宣网站定制设计、自适应品牌网站建设、H5建站、商城网站开发、集团公司官网建设、成都外贸网站建设公司、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为武宣等各大城市提供网站开发制作服务。
随着Flutter对现有业务的不断参透,闲鱼Serverless基建的重心也倾向了dart生态,先是将dart容器打包到服务器上,实现dart编程语言的统一,在统一的容器之上实现编程框架一体化(nexus、story),以及后端领域服务一体化。基于dart生态下,前端的FaaS在研发交付其实并不高效,研发阶段主要面临的问题是:
编程语言不统一:编程语言本身虽然不是最大的障碍,但这也确实给前端开发者增加不少门槛,而且更重要的是语言背后的生态、环境与体系更是一道高高的墙。
工程割裂与背后环境复杂:端侧一个工程,FaaS侧也有一个独立的工程,它们背后都有着自己的一套构建、调试、集成/发布的工具链;除此之外FaaS还有自己配套的环境、runtime、框架作为支撑。开发者面对这样复杂的FaaS研发环境与双重的研发工作流是无法做到高效交付的。
编程语言一体化
Typescript作为Javascript的超集,弥补了Javascript的静态类型检查,同时扩展了很多OOP的语法特性,使得TS跟dart在语法特性上有非常多相似的地方,为后面的转换提供了可能与便利。要实现语言层面转换背后都会有一个小型的编译器在支撑着,不过幸运的是Typescript官方已经提供语法解析器,通过它我们很容易就拿到一份可靠的AST,所以我们只需要实现一个dart generator就行了。生成器大致可以分为四个层面的工作:
基础语法转换
原生方法差异转换
业务框架桥接
依赖库与头文件桥接
基础语法转换
这部分很好理解,就是最基本的语法层面转换,用个最简单的例子看下。
原生方法差异转换
两种语言在内置原生方法上也有很大区别,举个例子:可以看到下面数组的实例方法在两种语言体系上是不一致的,除了数组插入还有很多很多原生方法是不一致的。当然也没太必要被这个难以想象的数量吓到,大多数情况:90%的场景只会用到那10%的方法,完成了10%的转换就能cover到90%的场景。
// ts
list2.push(10)
// dart
list2.add(10)
要实现系统方法的差异转化首先要识别出该方法是来自于哪个类,比如说list2.push(10)
我不可能只检查push
,因为随便一个类/对象都可以实现一个push方法。我们必须识别出list2.push
的push
属于Array.push
,别忘了整个typescript编译器中占比最大的类型检查器ts.TypeChecker
,它可以很好的帮我们解决这个问题。大致思路如下:
业务框架桥接
在完成上面两块能力转换后,常规裸写一段逻辑进行转换问题是不大的;但业务是不可能裸写,业务需要框架,需要借助框架进行通讯、与容器打交道。需要借助框架进行业务抽象,更好的组织、管理业务逻辑。我们来看个例子:
DartMtopResultresult = awaitHsfServices.request(moduleName, parameter);
上面的这段代码是用于在dart侧进行内部服务请求的,从代码表明我们可以获取到三部分信息:
有一个HsfServices的类
HsfServices有一个同步返回结果的request方法,接收两个参数
最终返回DartMtopResult的数据结构
我们再翻一下request
的实现与DartMtopResult
的申明:
// DartMtopResult.dart
classDartMtopResult
implements xxxx {
T data;
bool success;
String errMsg;
String errCode;
// more code hidden
}
// HsfServices.dart
classHsfServices{
// more code hidden
staticFuture
> request(String moduletName,String parameter)async{
// more code hidden
}
// more code hidden
}
就看这么多足够了,打个比方如果我希望在typescript侧编写一个能用HsfServices.request
发请求的ts代码且不报错,那应该怎么做呢?像下面这样申明一个:
// HsfServices.d.ts
export declareclassHsfServices{
static request(moduletName:string, parameter:string):Promise
>;
}
// DartMtopResult.d.ts
export declareclassDartMtopResult
{
data: T;
success:boolean;
errMsg:string;
errCode:string;
}
// business.ts
import{HsfServices}from"HsfServices.d.ts"
import{DartMtopResult}from"DartMtopResult.d.ts"
const result:DartMtopResult
=awaitHsfServices.request >('recycleGet', parameter);
非常简单就能让业务逻辑正常写下去并且不报错。但你肯定会说这样的代码也没法运行起来,是的,但我并不需要上面代码运行起来,我需要的是将它转成dart,并能在dart runtime中运行就可以了。大致的桥接思路如下:
依赖库与头文件桥接
// business.tsimport {HsfServices} from "@ali/faas-hsf"import {DartMtopResult} from "@ali/faas-mtop-result"const result: DartMtopResult= await HsfServices.request >('recycleGet', parameter);
// business.dartimport 'package:hsf_services/hsf_services.dart';import 'package:dart_mtop_result/dart_mtop_result.dart';DartMtopResultresult = await HsfServices.request(moduleName, parameter);
@ali/faas-hsf
对应dart侧的pub包与引入头文件。我们的解决思路大致是这样的:在@ali/faas-hsf
模块中放入faas.yaml
文件来指定对应的映射关系。
@ali/faas-hsf
|--lib/
|--faas.yaml
|--package.json
// faas.yaml
faas_pub:
# 映射的dart侧依赖包
hsf_services: ^1.1.7
# 映射引入头文件
index: hsf_services.dart
faas_src
存放业务逻辑的ts版,package.json
存放业务逻辑所依赖的编程框架(前面我们介绍到业务框架桥接最终就体现在端侧的依赖包上)├── faas_pub.yaml├── faas_src│ └── Home│ └── index.ts├── package.json├── src│ ├── components│ └── pages│ └── Home│ ├── index.css│ └── index.js└── README.md
init
dev
,让开发者0门槛初始化出一套统一而可靠环境的FaaS工程。faas_pub.yaml
由脚手架通过探测端侧package.json中的faas依赖包来进行提取生成的,并不需要人工维护。闲鱼技术团队不仅是阿里巴巴集团旗下闲置交易社区的创造者,更是移动与高并发大数据应用新技术的引导者与创新者。我们与Google Flutter/Dart小组密切合作,为社区贡献了多个高star的项目和大量PR。我们正在积极探索深度学习和视觉技术在互动、交易、社区场景的创新应用。闲鱼技术与集团中间件团队共同打造的FaaS平台每天支持数以千万级用户的高并发访问场景。
就是现在!客户端/服务端java/架构/前端/质量工程师面向社会+校园招聘,base杭州阿里巴巴西溪园区,一起做有创想空间的社区产品、做深度顶级的开源项目,一起拓展技术边界成就极致!