Fission 改动总结

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

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

功能开发

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

全局配置与局部配置

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

修改的部分如下：

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

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

本地测试功能

为了方便用户在本地测试程序（本地最重要的一点可以加断点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的更新策略需要修改为先杀后起，已修改

WRY