WRY

Where Are You?
You are on the brave land,
To experience, to remember...

0%

Fission 改动总结

目录

本篇博客主要记录了对Fission所进行的改进和优化,主要有:

  • 功能开发
    • 使用Fission CLI 查看函数日志的时候,优化日志的展示,包括添加从当前时间开始查询的功能
    • 全局配置和局部配置相结合的方式,对函数进行配置(传统部署方式使用环境变量的方案在fission中的替代解决办法)
    • 开发函数的本地测试环境,方便用户本地调试
    • 在定时任务触发的时候,允许用户给函数传入参数
    • 直接从Pod中获取函数的日志信息并且持续输出,方便调试
    • 基于配置的多途径日志采集组件
    • 可视化的数据流观测组件
  • 功能优化
    • 加快函数更新时的生效速度
    • Kafka消息队列的触发方式,添加并行方式来支持高并发

因为在开发过程中没有一个良好的代码提交习惯,所以看Git的提交记录时显得较为混乱,准备利用国庆的这段时间,从最新的fission分枝上进行改进,按照一个特性一个分支然后合并的思路,将做过的工作,重新梳理一遍,最后会有一个代码梳理的记录。

功能开发

使用Fission CLI 查看函数日志的时候,优化日志的展示

参考博客

全局配置与局部配置

Fission 函数在官方版本中,只能使用和函数同一个命名空间中configmapsecret。但是在实际使用过程中,几乎所有的函数都会需要一些基础的配置信息,例如pushgateway的地址等等,这个时候在每个命名空间下进行相同的配置就显得十分不便。因此添加了一个所有函数都可以拉取的全局配置的功能。全局配置在一个预设好的命名空间下,方便进行权限管理。

修改的部分如下:

  • CLI: 在函数创建和更新时,识别全局还是局部配置。Fissioin存储configmapsecret的时候会存储命名空间加配置名称,这一定程度上简化了整个改造的流程
  • Executorpoolmgrnewdeploy在给服务帐号fission-fetcher绑定权限的时候,添加对全局配置所在命名空间的权限绑定
  • Preupgradechecks: 在升级检查时,允许配置所在的命名空间,不仅仅是函数所在的命名空间,也可以是全局的配置中心
  • charts: 在创建fission环境的时候,创建全局配置所在的命名空间
  • Environment
    • 部署命令为每个函数默认添加一个configmap的配置,默认内容为对environment的需求功能开关
    • 添加一个功能,读取fetcher拉取到的配置,存储在字典中,供用户进行读取
    • 根据配置文件中对基础环境的要求,创建对应的资源句柄和设置日志的输出级别等

最终函数的配置有如下效果,通过全局和局部配置想结合的方式,让Environment预先获取好与基础设施之间的连接。

fission-configs

本地测试功能

为了方便用户在本地测试程序(本地最重要的一点可以加断点debug),开发了Fission 本地模拟测试环境,模拟内容如下:

  • 模拟全局配置文件:为了本地调试的时候完全和集群脱离关系,全局配置的设置通过本地的一个模拟文件来代替。
  • 对fission函数运行时的变量进行一个完全的模拟,依旧使用全局配置文件和局部配置文件进行配置的方式。
  • 本地模拟脱离了flask框架,但是仍采用相同的变量名g来传递基础变量。

通过本地模拟的方式,在本地编写代码的时候,除了可以便捷地进行调试之外,IDE 也能对基础环境中的变量和方法进行索引,加强了Environment和函数之间的联系,更容易避免低级错误。

定时任务传入参数

Fission函数虽然以简短功能单一为主要目标,但是在实际使用过程中,仍会遇到如下的情况:我需要一个定时任务的功能来完成3个任务,这三个任务之间的区别仅仅是一个字符串变量的不同,此外3个功能的执行频率也不一样。这个时候如果编写三个基本一模一样的函数,固定参数,分别设置定时器来触发,那么代码大量冗余且难以维护。如果我们采用编写一个用来实现功能的主函数,三个用来包含参数的定时触发函数的模式,那么函数数量众多,且没有有用的信息。因此为Fission 的定时任务添加了传入参数的功能(可选),来让Fission函数变得更加灵活

修改部分如下:

  • 修改定时任务的定义,添加参数的信息
  • CLI,识别用户的参数flag,写入定时任务中
  • Timer,更改请求Router的request,声明body为json结构,并且将参数放入body中

通过这个功能的开发,上述场景中的用户就可以通过编写一个功能函数,设置3个携带不同变量的定时触发器即可完成任务。

从Pod中获取函数的日志信息

在使用Fission原生的查看日志的功能时候会有如下几个弊端:

  • 延迟高,不能及时将日志反馈回来
  • 对Fission自带的日志收集与处理服务influxdb的要求极高,如果该服务挂掉了,导致查看函数日志的功能彻底失效

但这种方式也有自己的优势,那就是可以查看所以的历史日志信息,但是大多数的场景,用户只是想看看函数对刚刚的触发有什么反应。为了针对这种场景,在Fission的日志服务接口的规则下,开发了从pod直接查看函数日志的功能。改动如下:

  • Controller 添加检索函数对应的最新的pod的功能和从pod中拉取指定时间之后日志的接口
  • CLI对应logdb接口,请求Controller的接口,获取日志信息,包括时间,POD和日志内容三部分信息

通过这种获取日志的方式,依旧可以保证在pod发生变化的时候,拉取到正确pod中的日志。此外由于直接从pod中获取,这种方式更高效稳定。最后开发是在Fission的大框架基础上的改动,容易调整,易于维护(采用了分离式的设计,依旧能保证权限范围没有发生变化)。

基于配置的多途径日志采集组件

参考此处完整介绍

可视化的数据流观测组件

参考此处完整介绍

功能优化

加快函数更新时的生效速度

经过阅读代码,追踪pod删除的最大等待时间发现,fission在env中提供了graceperiod参数,该参数决定了pod被删除时,最长的等待时间,通过将该参数修改为10s,可以显著加速函数的更新时间(默认3600s)

消息队列高并发消费

官方正在开发,等等党终将胜利!

V1.11.0的Fission已经支持啦,官方万岁!

代码梳理

思路

  • 从官网master分支的上的Release 1.11.0 (#1716) Vishal* 2020/9/17 上午12:57节点创建新的分支,作为改动的初始化的分支
  • 根据功能进行分类,创建不同的分支进行开发
  • 按照功能的实现顺序,将代码合并起来

划分的分支

根据改动的功能,创建如下几个分支进行开发:

  • deploy:Fission的环境部署,镜像更新以及charts的规范
  • log:Fission的日志查看,以及日志收集等
  • trigger:触发器的改造和规范
  • config:使得Fission兼容全局配置
  • monitor:Fission数据流监控

最终的效果

每次合并代码之前都经过了简单的测试,但受限于时间有限,部分测试并不全面。

代码提交效果图

Fission相关内容的完整项目

发现的问题

  • 更新env时,不会删除正在运行的pod
  • 同一个函数出现大量的pod,初步排查是Router的问题,导致频繁调用UnTapService函数
  • mqtrigger-nats-streaming的更新策略需要修改为先杀后起,已修改