原文首发：ITPUB，作者：王静
采访对象：「名人堂」LiteFlow 框架作者 张元成
在每个公司的系统中，总有一些拥有复杂业务逻辑的系统，这些系统承载着核心业务逻辑，几乎每个需求都和这些核心业务有关。这些核心业务逻辑冗长，涉及内部逻辑运算、缓存操作、持久化操作、外部资源调取、内部其他系统RPC调用等等。时间一长，项目几经易手，维护的成本得就会越来越高。各种硬代码判断，分支条件越来越多。
代码的抽象，复用率也越来越低，各个模块之间的耦合度很高。一小段逻辑的变动，会影响到其他模块，需要进行完整回归测试来验证。如要灵活改变业务流程的顺序，则要进行代码大改动进行抽象，重新写方法。实时热变更业务流程几乎很难实现。
本期 ITPUB 有幸采访了开源 LiteFlow 框架的作者张元成老师，一起探讨一款轻量，快速的编排规则引擎框架。LiteFlow主要致力于逻辑驱动的编排。可以满足于大部分的生产业务场景。组件编排，帮助解耦业务代码，让每一个业务片段都是一个组件。
· 张元成 ·
问题 1：您好，张老师！很荣幸有机会采访到您，先简单介绍一下您自己！
大家好，我的网络ID叫铂赛东，可能大家对于这个ID更熟悉点。很荣幸受到IPUB社区对我采访的邀请。我是开源框架LiteFlow的作者，个人长期从事基础性架构方面的研究工作，工作中的职责也是如此，写了十几年的代码，其实写过很多框架，LiteFlow可能是被大家熟知的一个。
我的开源经历有5年多，目前2个项目荣获了GVP荣誉，我也是《开源指北》的编写者之一。
我目前所在的组织叫Dromara，是国内优秀的Java开源组织，致力于推动国内开源事业的发展，为广大的开发者提供优秀的解决方案，社区活跃，让参与的每一位开源爱好者，体会到开源的快乐。
问题 2：编排规则引擎 LiteFlow 的分工是怎样的？在开源网站上 LiteFlow 属于微服务框架类前几名，star 已超过4k，怎么想到开源 LiteFlow 呢？
LiteFlow是一个社区驱动型的开源框架，我们90%的issue都来自于社区，也有社区的小伙伴成为了LiteFlow的Committer。
很多项目都是先在公司内部用，用的稳定了后，然后剥离出来开源。但是LiteFlow的模式不是这样的，从一开始设计起，我就确定了LiteFlow将是一个开源框架的目标，从项目规划，设计，规范，开发流程上都完全按照开源的模式在走，第一个版本出来之后，先是运用到公司内部系统上，然后根据表现来完善初代版本。然后后续都是按照社区来驱动的。
很幸运，LiteFlow这个项目兑现了最初的规划，迭代了两年，成为了国内比较知名的规则引擎。
当然在这过程中，我也有过挣扎，曾几度放弃过这个项目。但是社区和使用者其实是会倒逼你的，我就不停的在放弃和前进中徘徊，直到有一天我觉得，LiteFlow的确可以走的更远，这个项目倾注了我太多的时间和精力，既然已经走出了一段距离了，为什么不再多往前一点呢。
开源LiteFlow不是一时兴起，是我2年来一直拥有的信念：我要把他带的更远，开源需要信念和坚持，人生和生活亦是如此。
问题 3：请您介绍一下 LiteFlow 是什么？LiteFlow 设计之初遵循了哪些设计理念/设计原则？
LiteFlow是一个java编排式的规则引擎框架，它不仅能把核心逻辑剥离出来，还能进行业务的编排。是一个融合了规则引擎和编排引擎的框架。
LiteFlow框架设计理念是轻量，使用方便，四两拨千斤。在编排领域，LiteFlow能让你的系统分割成一个个小的组件，然后像搭积木一样拼装成一个完整的业务，同时组件可复用，可实时替换，删减和增加。组件是LiteFlow中最小的编排单位，我们把它想象成积木。LiteFlow提供一套非常简单易学的编排语法，程序员非常容易上手。同时每个“积木“可以用java来定义，也可以用脚本来写。非常灵活。
问题 4：LiteFlow 融合规则引擎和逻辑编排引擎的一款开源框架，什么是规则引擎和逻辑编排引擎？规则引擎与逻辑编排引擎分别解决的是什么问题？
简单来说，规则引擎解决的是系统的灵活问题，主要是把决策逻辑进行剥离，用预定义的语法来表示。使用者在外部改变决策语法，那么整个决策逻辑就发生改变，并且这个过程是要求能实时生效的，不需要系统发布重启的。
逻辑编排引擎解决的是系统的耦合问题，一个系统能够随意编排，就意味着有编排单元，是解耦的，否则上下有强依赖关系，怎么能实现编排呢。有了编排单元加上精妙的编排语法，编排引擎就能做到耦合问题，组件最大程度的解耦，可复用，替换组件即改变业务。
LiteFlow认为这2者之间是息息相关的，所以把这2者进行了巧妙结合。所以解决了系统灵活性，又解决了系统的耦合性，算是在规则引擎领域的一种全新的探索吧。
问题 5：LiteFlow 可以解决哪些问题？什么场景适用于使用 LiteFlow 呢？
LiteFlow在绝大多数的业务中都可以使用，尤其是针对于业务比较复杂的系统，使用LiteFlow简直是个解耦神器。因为LiteFlow的核心理念就是用搭积木的方式来搭出你的业务。使用这样理念设计打造出来的系统具有最大程度的解耦性，复用性和灵活性。如果你的系统维护艰难，历经多任修改，逻辑复杂，改一个地方就怕影响全局，要回归测好久。那么LiteFlow将会是最佳选型。
前面我提到过，LiteFlow不仅是一个规则引擎，还是一个编排引擎。所以不一定你需要规则引擎时才要用到，即使作为一款编排框架，都是很不错的选择，即使很简单的业务也可以使用，没有场景的限制。在规则引擎方面，LiteFlow更是提供了强大的脚本和中间件插件的支持。
问题 6：为什么 LiteFlow 框架可以给业务提供更多的自由度和可玩性？
首先是LiteFlow提供了非常简单易学的EL语法，经过简单学习之后就可以上手，运用语法，可以编排出非常复杂的业务，真正做到像搭积木一样的写代码。
其次LiteFlow的脚本提供了groovy，javascript，qlexpress三种脚本语言的支持，未来还将推出更多的脚本语言种类。使用者可以选择自己熟悉的语法来进行编写业务。用脚本语言完全能代替java来进行书写逻辑，LiteFlow打通了java系统和脚本语言之间的所有屏障，所有的逻辑都用脚本语言来完成也是可以的。
再者就是LiteFlow提供了众多的第三方存储中间件的支持，支持所有的关系型数据库，另外还支持了流行的注册中心，zk，nacos，etcd。把规则和脚本存储到第三方中间件，还支持自定义扩展你的存储接口。改变规则和脚本，无需做任何事情，即可实时平滑刷新你的整个业务。
所以说拥有了实时调整和像搭积木一样写业务的能力，业务的自由度就能得到巨大的提升。
问题 7：LiteFlow 与同类型哪些框架做过测试对比？在相同的场景下具备哪些优势？
业界开源的规则引擎框架其实并不算多，LiteFlow一直对标的就是老牌规则引擎Drools，其实早在十几年前，我刚毕业工作的时候就曾接触到，一直是规则引擎框架的标杆。
LiteFlow和Drools能解决的问题都类似，但是LiteFlow的设计理念会更加现代化一点，支持的脚本语言更多，对中间件的支持也丰富很多，学习成本也少于Drools。在热刷新上，也比Drools简单平滑很多。
最最重要的，LiteFlow的文档和社区都非常本地化，碰到问题了，提issue，或者进群反馈下，就立马能得到解决，我相信这不是国外的开源软件能比拟的。
问题 8：LiteFlow的的流转模式是怎样的？有什么特点？对比其他模式有什么改进？
LiteFlow的流转模式比较特别，因为有了组件化这个概念，所以LiteFlow的流转方式基于工作台模式的。
工作台模式就是所有的组件不需要互相进行交流，传递数据。而是统一的通过工作台这一容器进行存取数据。工作台我们可以简单的理解为上下文，每一个请求会自动分配一个上下文。这种模式最大的好处就是组件之间是解耦的，每个组件只关心自己需要什么资源，产出哪些数据，至于资源是谁给的，产出的数据是给谁的，组件并不需要知道。
LiteFlow的编排流转理念正是基于此开发的。
问题 9：您认为好的开源框架应具备哪些条件？开源编排规则引擎LiteFlow的下一步规划是什么？
我觉得好的开源框架一定要具备社区性，也就是说有多少人用它，很多人用，反过来也就说明了它能解决的问题是被大家认可的。还有就是框架的贡献度，如果一个框架完全由作者一个人长期维护，那除非这个作者具有非凡的毅力和决心，不然很难去完成这件事。很多国内好的框架也正是因为这个原因而最后不维护了。
我就时常反思开源的意义是什么，开源的本质就是让更多人参与进来，一起去完善项目。一个人的力量是有限的，一群人才能走的更远。
LiteFlow的下一步规划是分成技术方向和运营方向的，技术方向我们除了不断迭代解决社区内提出的issue外，我们也会在形态上进行升级，比如更稳定的功能，更规范的代码，更完善的注释，推出界面去管理去监控等等。在运营上，我希望LiteFlow这个项目被越来越多的人使用，希望社区能有更多人参与。我作为作者，也欢迎任何人能参与贡献，并且成为我们的长期贡献者，团队成员。
问题 10：如何看待国内开源生态链，有什么关于开源方向的意见和建议吗？在开源实战中，您印象最深的事情是什么？
我觉得国内开源生态比以前繁荣很多，但是开源一定是一个持续的过程，而且不是说我把代码托管到github，gitee上那就叫开源，那最多只能算你把代码公布了而已。公布代码只是第一步，接下来你还得持续迭代，建设社区，运营你的项目，写出完善的文档，如果有发布包或者依赖，还得发布到公有的仓库。如果你想让更多的人了解到你的开源并想让更多人来参与，那么持续的迭代和运营是必须的，借用我们社区一位大佬的名言，开源不能光埋头写代码，还要抬头看路。抬头看路很重要，知道路的方向比你写万行代码更有价值。方向永远是第一位的，做好了运营，做好了推广并持续迭代，才会有人关注你的项目，然后有人给你提issue，参与贡献，反过来又会倒逼着项目的持续迭代，这就是一个正向的循环过程。
在我的这几年的开源经验里，印象最深的是，有一个好的圈子是最重要的，就是说要寻找一批志同道合的朋友，一起学习，一起激励。正如我现在所处的Dromara组织，它是由国内顶尖的开源组织自发形成的一个组织，大家有各自的开源项目，一起交流技术，探讨国内开源的现状以及一起推动国内开源事业，这让我觉得很有意义，也很乐于去为组织，为开源事业贡献自己的力量。帮助到更多的人。
也希望大家能多多关注中国的开源事业，以及关注下我们的Dromara组织，希望更多热爱开源事业的人加入到我们的队伍中来。
