作者：闲鱼技术-无浩
关于GCLI
闲鱼技术团队推行了基于Flutter+Servless的一体化研发方案, 在Serverless技术的加持下，客户端开发可以轻松独立完成业务闭环。FaaS作为Serverless技术业务功能主要载体，其开发效率影响需求交付的速度。GCLI是一个基于支撑FaaS研发生命周期的命令行工具，它定义了闲鱼FaaS开发闭环，统一了FaaS的研发环境，是提升FaaS研发效率的利器。
关键问题
FaaS开发闭环
下图是简化后的闲鱼FaaS开发视角下的开发生命周期，和传统服务端开发相同，图中2.1～2.3是最高频动作，将这些动作串联起来、提供标准的操作语义，以高效的运转对于提升FaaS开发生产力至关重要。闲鱼FaaS希望给用户提供像开发本地函数一样开发FaaS代码的体验。
研发环境统一
闲鱼的FaaS自建了一套适配自家JAVA生态的工具链以简化FaaS的编程平面,但同时引入了开发环境的一致性问题, 开发环境不能收敛管理可能带来
- 陷入「It works for me」困境，开发环境的干扰让问题本质迟迟无法重现
- 开发环境退化，如环境变量被覆盖、OS被动升级导致兼容性问题等
- 开发环境适应，基于linux开发的库、工具无法在非linux环境下运行
- Start From Scratch, 对于一个新的技术栈，开发环境安装和配置是阻碍用户尝试创新的因素之一
上述几点在闲鱼的实践里得到了应验，之后闲鱼尝试基于WebIDE开发来解决环境的问题，但现阶段体验上和理想有差距，WebIDE由于用户研发习惯和工具也得不到很好的继承，开发效率反而因此下降；如何统一开发环境、延续用户开发习惯也是需要重点考虑的。
GCLI的解决方案
为了解决上面两个核心问题，如下图所述，GCli将研发闭环拆解成适合Serverless研发风俗的开发指令；为了让用户继承其研发习惯和工具，闲鱼优先选择了基于本地的开发方案；使用Docker技术统一开发环境，在Dcoker内声明Dart FaaS技术栈依赖的运行环境(软件+配置)。
借助容器技术，FaaS的软件环境可以移植到任何支持Linux运行的操作系统，从而解决了环境统一的问题；GCLI通过FaaS Open API实现本地和函数平台实现互操作，形成完整的研发闭环。
GCLI命令行
GCLI命令行被设计Standalone的可执行程序以消除编程语言Runtime的依赖。它会将用户开发指令转换为Docker的操作命令，并以一定的策略来控制Docker的生命周期。下面是GCLI的功能片段：
用户可以借助GCLI定义的研发指令开发函数。例如用户用开启热部署，只用关心代码编写，GCLI将代码实时同步到云端，随后调用一次函数并观察函数返回和结果即可。
- 利用GCLI热部署和日志指令开发函数
#打开热部署能力，实时监听代码变化，并实时在云端生效
gcli hotdeploy -f my_function --watch
#调用远程函数,获取调用结果
gcli invoke -f my_function --data '{"data":{}}'
#查看云端函数日志以tail的方式运行
gcli logs -f my_function --tail- 本地运行或debug函数
#本地拉起函数容器
gcli local start
#本地debug
gcli local debugGCLI Docker容器
GCLI Docker容器希望提供一个和技术栈无关的FaaS开发镜像规范，并解决与IDE本地协同开发的问题。在基于Dart的FaaS技术栈里，容器的设计参考下图：
-
宿主机IDE侧
- 用户代码目录通过bind mount到Container，然后在容器内完成编译，之后的产物能够被IDE识别
- GCLI通过Docker同步的配置文件，执行端口映射、bind mount或环境变量导入操作
- 宿主通过Volume共享容器内的文件（如Pub仓库、Maven仓库），提升编译速度
- 宿主通过NAT地址转换和容器打通网络，端口转换信息定义在GCLI的配置文件里
-
容器侧
- 镜像加速区，为了提升编译的速度，在镜像里预置了可能需要的缓存文件以及环境变量
- 软件仓库，定义需要同步到host的软件
- 编译/运行时环境，包括语言运行时、环境变量、仓库等
- 定制软件，GCLI提供的开发指令的实现来自这里
有了对开发容器的抽象和定义，对于开发环境的提供者只要遵循镜像的设计标准，即可以复用GCLI的能力，快速交付一个基于统一开发环境的研发工具。
总结和展望
闲鱼自从在FaaS开发中实施了GCLI，开发人员在下面几点上获益：
- 开发门槛降低了，对跨栈开发友好，非Dart技术栈开发人员可以在30分钟内从裸机到完成开发部署FaaS服务。
- 本地开发环境稳定可靠，彻底消灭了开发环境不一致引起的问题，节约了宝贵的开发时间。
- 开发闭环指令简单易用，而在GCli产出之前，50%的开发会由于定制开发工具复杂、易出错而选择放弃使用，进而选择传统低效的开发方式。以部署为例，传统方式需要10分钟完成部署，GCLI只需要5秒。
- 容忍Windows等操作系统的开发，对于一种新的开发模式推广有正面作用。
文章前面提过GCLI为了延续用户的开发习惯,选择在宿主机IDE开发代码,基于Docker的GCLI解决了统一环境问题，但由于共享开发机的方式对于宿主的性能有一定要求，在非Linux系统上运行Docker多了虚拟机的开销，在本地运行Docker并不是提升编译性能的最优解。未来，特别在云原生开发技术不断发展中，不单是FaaS技术栈，开发环境会逐渐走向容器化，云主机托管用户的开发环境，另外IDE的职责更加单一，更加轻量化。作为对开发技术最了解的架构人员可以根据规范交付开发镜像，让开发人员享受「统一」带来的红利。
