背景
听上去很美的 Serverless 在实际落地开发过程中,却确存在一些痛点。比如您在使用 Serverless 的过程中,肯定有如下的困扰:
- 使用函数计算 Custom Runtime/Container 想要一键平迁原有 SpringBoot,Python Flask,ThinkPHP 等各种语言框架的应用,实例启动过程中需要访问云端环境中的其他服务(如数据库或者注册中心),遇到应用启动不起来时,该怎么排查原因?
- 应用采用微服务架构,涉及到多个服务。能否在本地代码开发完成后快速进行端对端测试?
- 事件驱动的应用,通过事件源触发函数,环节多,链路长,能不能在本地快速测试整个链路?
- ……
端云联调
- 变更代码,实时查看结果,调试迭代的闭环最短。例如要开发的服务被其他服务依赖,当本地代码开发完成后,最好能发起端对端的测试,看看改动有没有 break 调用方服务。如果采用传统方式,需要把代码部署到远端,发起测试才可以,流程很冗长。
- 能够复用本地丰富的开发调试工具,效率最高。例如调查远端环境中的测试用例失败,以往只能靠日志。如果能把生产流量导入到本地环境的实例上,使用本地环境上各种 IDE 进行调试,是不是很爽?
用户只要在 s.yaml 的目录下, 执行 s proxied setup,这个命令做了如下事情:
- 根据您 s.yaml 的 vpc 配置等信息创建一个辅助的 Service/Function, 并对辅助函数预留1个实例。该辅助函数的作用是作为代理服务,本地实例所有进出流量都会通过该代理服务。
- 启动本地环境的代理容器实例, 通过通道服务, 和 1 中的 FC 网络代理容器实例建立一条双向通信 TCP 隧道。
- 启动本地的函数容器实例, 比如您是 Custom Runtime 直接跑 SpringBoot 应用, 启动 SpringBoot 的本地函数容器实例和 2 中的代理容器实例共享网络, springboot 应用已经能内网访问线上 VPC 资源。
- 本地函数容器实例启动成功, 即可以开始调试,直接使用 s proxied invoke 或者 curl 自定义域名调用辅助的 Service/Function, 流量会通过代理服务打回到本地函数容器实例, 开启本地 IDE 对实例内的应用进行断点调试。
因为会有一个辅助函数预留1个实例, 所以调试结束后, 您可以手动清理资源, 以免产生不必要的费用。
使用上面 1 或者 2 其中一个方法即可, 如果您不放心, 可以多次执行 s proxied cleanup。
即使您忘记清理, 如果本地开发机关机或者断网, 通道 session 会自动关闭, 预留的资源也会自动清理。
实战场景举例
以阿里云函数计算一个真实的企业客户为例:小王是一个业务驱动型的公司的开发, 公司为了提高业务迭代效率, 技术架构向全面云原生化演进, 减少基本设施的管理和运维, 架构大致如下:
$ s proxied setup
我们从本地实例的启动过程信息就可以明确定位到原因是 Nacos 访问不通,我们需要查看函数是否正确配置了 Nacos 所在的 VPC 信息,或者 Nacos 是否有白名单限制等等。
总结
相关链接
[1] hacknoon serverless report:
本文为阿里云原创内容,未经允许不得转载。