低代码开发平台需要解决的核心问题服务编排和规则引擎

　　今天再谈下对低代码开发平台的一些思考。
　　在前些日子，ThoughtWorks 中国区 CTO 徐昊在接受采访的时候谈到，低代码不是一个新概念，现在也不是低代码第一次引发业界讨论，以降低程序员门槛为目的的低代码从底层逻辑上就是不通的，这类低代码不是风口，而是行业毒瘤。
　　这个在当时引起了广泛的讨论和争议，当然反击声音最大的肯定是各种低代码开发厂商，这本身也可能极大的影响到这些厂商本身的商业利益和发展融资。
　　实际上对于徐昊整个采访一直在强调，以降低程序员门槛为目的的低代码是最没用的。从某种程度上来讲，这类低代码产品最终会演变成程序员的工作，甚至引发新一类程序员的出现，而它本身则从低代码退化成为真正的代码。
　　在10多年前我们就做过类似的快速开发平台，里面有完整的界面建模，对象建模，流程建模，规则建模，组织权限建模等能力。但是应用到后期发现的一个关键问题就是对于规则引擎部分，通过脚本代码实现的规则越来越复杂和庞大，而且极难维护。也就是说很很多业务需求或复杂规则的实现很难抽象出统一标准规则或模型，你必须用脚本代码去实现，但是对于复杂规则脚本却变得越来越庞大。
　　在《人月神话》这本书里面提出一个重要的观点就是没有银弹，只有焦油坑。当时提出这个观点的背景仍然是大型工程类复杂软件系统的开发和实现。对于这类系统可以看到的重点已经不是后续的编码工作，而是整个系统分析和设计过程。                                人月神话 40周年中文纪念版 布鲁克斯著 软件开发人员软件项                        ￥88                                                                购买
　　在我前面一篇对没有银弹的论述文章里面也谈到，整个从需求到软件开发实现的过程实际上可以分为几个关键环节，即：现实世界-》业务建模-》系统建模-》开发实现。
　　也就是说低代码开发平台并不能省略掉业务建模和系统建模这个动作，而这个建模本身又需要一些业务+技术的双背景往往才能够更好去承担该任务。
　　简单来说，随便一个人，给你一个低代码开发平台，你就能够实现一个完整的业务系统，这个本身就不现实。那么是否就说低代码开发平台本身没有价值？
　　要回答这个问题，还是要将低代码开发平台分为两大类。一类是零代码偏配置的平台，一类是真正低代码面向开发人员的平台。
　　零代码偏配置的平台
　　对于零代码偏配置类低代码平台，整体来看，可以看到三类发展和演进方向。
　　其一是将传统企业工作中日常的表单流程实现电子化，自动化，流程化。这里表单流本身更多是表单CRUD逻辑，配置权限和流程审批，没有复杂的类似ERP系统一样的后端业务规则需要实现。因此低代码平台一般能够胜任。
　　其二是基于垂直行业应用下扩展低代码开发能力，比如项目管理应用，CRM应用，包括复杂的ERP系统等。在这种场景下底层核心业务模型和对象模型是稳定的，不能轻易出现变化，外部人员更多是基于低代码开发能力进行快速外围能力扩展。
　　其三是SaaS平台类应用的外围生态构建，最典型的就是类似钉钉这种SaaS应用，其本身就是面对类似OA，HR等日常协同类应用，流程表单多而规则并不复杂。因此提供一个低代码平台能力更加方便用户进行能力扩展，SaaS平台唯一需要考虑的就是底层组织引擎本身的稳定性，统一注册接入的接口标准和集成等。
　　真正低代码面向开发人员的平台
　　当前我们谈平台+应用构建模式，谈中台和能力开放，谈云原生平台和ServerLess架构。而这些都体现出一个关键特征，即：
　　应用开发应该是分层的，前后端分离的。
　　后端提供的是各种可复用的API接口服务能力，这些能力既包括了类似消息，缓存等技术服务能力，也包括了类似人员，组织，规则处理等业务服务服务能力。
　　前端应用的开发更多的应该是基于后端的API服务能力灵活地进行组装和编排来完成。基于这个思路你会发现前端实际包括了两个关键事情。其一是低代码平台常说的界面建模能力其二是接口服务本身的组装，服务编排能力
　　而对于后端来说核心则是提供各种API接口服务。这些接口本身本身也分为了两类，一类是在进行对象建模完成后将简单对象或复合数据对象发布为API接口服务。其二是提供规则引擎来实现各种规则能力并发布为API接口服务。
　　对象直接发布为API接口很容易实现。
　　而真正困难或难以自动化的就是规则引擎实现，并将规则发布为API接口服务的过程。前面已经谈到对于复杂业务规则或逻辑的实现，即使采用规则引擎，那么也存在大量手工编写的规则实现脚本代码，由于是脚本代码，这些规则越写越复杂，越是难以维护。
　　当我重新思考这个问题的时候，发现面向开发的低代码平台，核心是规则引擎和服务编排，同时在引入这两个关键组件时候，你也要意识到对于复杂规则实现，复杂的编排，最好的方式仍然是写代码来实现，最终将其暴露为API接口服务。
　　也就是说这类规则服务或领域服务能力本身还是可以代码实现的，是可以维护的。
　　就规则引擎和服务编排来讲。
　　个人理解前期在自动化的实现中，重点不是规则引擎，而是可视化的服务编排能力实现。当前已经有不少的微服务架构下的微服务API编排开源组件实现，但是前面我文章也分析过并不是特别的灵活和可配置。
　　对于服务编排场景的详细阐述，可以参考下面这篇文章。
　　从ESB服务组合编排到NetflixConductor微服务编排
　　一个可视化服务编排，重点在哪里？
　　我们可以对这个问题简单思考，比如前端在进行界面设计建模的时候，最喜欢的就是各种界面组件，控件，按钮，能够直接挂接到一个统一的组合服务API上面，而不是说前端人员在界面设计的时候还需要去搞清楚点击安排究竟要调用几个API接口，而且调用过程中还需要遵循什么样的规则逻辑。
　　在前后端分离的场景下，前端并不关心复杂的后端逻辑。
　　从这个道理上来讲，微服务编排需要考虑的就是将多个细粒度的原子服务或API接口，统一组合或组装为一个大的API接口服务的能力。
　　这种服务组装或组合本身只包括两大类。
　　第一类是偏静态的数据组合，组装和拆分。比如你点按钮要获取数据，原来是要查询两次API接口，现在我给你组合下，调用一个大API组合服务，一次给你返回所有数据。或者说类似单据保存过程，你原来是需要调用两个API接口分别保存头和明细，现在我给你组合下，你一次把完整数据对象送过来，我一次给你保存完。这些是属于典型的传统基于领域对象的领域服务API接口实现的。
　　第二类是偏动态的自动化业务流程处理，类似在传统SOA架构里面说的BPEL自动化业务流程处理。这种业务流都是系统后端自动完成，不需要人工干预，比如点击按钮要自动产生一个待办工单，比如提交报账前要首先调用预算API接口进行预算检查，比如在单据保存成功后自动化去启动流程API接口等。这类服务组装或编排往往体现出一张接口服务串行调用的典型特征，即前一个API接口输出会成为一个接口的输入。
　　那么第二类服务编排究竟应该是基于服务的同步事务处理，还是基于消息事件的异步编排就变成一个关键点。如果是同步你需要考虑补偿或回退机制，如果是异步消息，你需要保证消息最终一致性等。
　　当前我没看到任何一个轻量级的基于微服务API接口的可视化服务编排工具，如果有相关的可以推荐给我进行分析和研究。同时我也再次提出基于微服务API的轻量，灵活，可视化服务编排工具，往往是一个重要的低代码平台发展趋势。