Triggerflow是一个基于事件驱动的无服务器工作流编排系统。项目已经在github上开源，但是目前还不够完善，尝试在自己搭建的knative上部署也并没有成功工作，但是其中的一些思路还是不错的，所以本文就简单分享一下它的思路。
项目地址：http://github.com/triggerflow/triggerflow
整体把握可以参考github中的图，事件从事件源接收后发送到指定的trigger，trigger对比condition后决定是否运行，运行其实就是调用具体的函数。triggerflow未来发展顺利的话是有可能整合进knative中的。
由于是一个粗略的把握，所以这里我也就分点粗糙的记录一下一些想法吧。
------------------------------------------
1.一个trigger的核心组件为四个：event，condition，action，context。event是一个json类型的数据，由于triggerflow是用python写的，所以也可以看作一个字典，condition是一个条件判断性质的东西，在knative版的实现中表现为一个函数，trigger通信时传递condition的函数名，但判断时调用condition结合event和context进行判断。action和condition类似，最后也是输入context和event进行运算。context是上下文，包含的信息非常多，包括event、trigger等等环境中的因素，既是condition判断条件的依据，也可以是action运行时的参数来源。
2.整体采用的大多数都是RESTful式的api，存储用的是redis，目前看起来最后函数运行的结果应该也是保存在context中，我目前认为可以将结果写入数据库并提供一个访问token，用户通过token去提取运算结果。
3.目前系统中的通信是依靠python中的queue执行的，由于没有完整运行过，不知道改成GRPC会不会好一些。或者kafka也行？
4.knative中的实现里，triggerflow主要用的是flask作为网络调用的接口，确实serverless的网络间访问应该就是完全依照某种统一的网络接口来访问，例如restful类型，通过传递一个json式的数据传递消息。而平台应该负责保证各个函数的随时启用，
5.函数之间访问链应该以某种形式存在。triggerflow提供的是工作流形式，这个工作流最后会变成一个个trigger，工作流的编排由开发者设计，最后保存到某个介质中，例如数据库。
6.访问时元素挺多的，除了id、workspace等工作必须元素外，还应有auth授权信息，允许自定义的参数列表等等
7.事件源在这里是作为一个事件的发生器，不过在knative版的实现中并没有太多的体现。triggerflow中规定事件源继承自EventSource类，需要实现set_stream,publish_cloudevent,get_json_eventsource三个方法，最重要的就是publish_cloudevent，即向绑定的通道发送消息。我理解里，事件源的事件应该发送到一个类似路由中心的地方，由路由器根据事件中指定的trigger进行分发。
8.workspace相当于一个域，域里面有共同的workspace名，事件源以及全局context
9.事件流可以通过状态机的方式展示，通过当前状态以及输入决定下一个目标，可以作为一种serverless模式下的设计模式
10.trigger就像是要运行的函数带了个头套，方便与其他东西相接，但最终指向一定是函数。
11.一个更加通用的模板是更好的。各种意义上的模板以及各个场景上的模板
大概就这样吧。