【程序员日记】---从业务编排到低代码-Toy模板网

这篇具有很好参考价值的文章主要介绍了【程序员日记】---从业务编排到低代码。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

之前总聊微服务，今天换一个话题---低代码。

低代码这个词也是最近这几年很火的概念，尤其是遇到大环境下行，很多大厂和互联网那个公司也在慢慢在低代码方向发力，当然，对于传统项目交付型的软件公司，低代码也具有相当大的吸引力。

如何理解低代码

用一个通俗易懂的说法，就是少写代码，并且降低开发门槛的方式，可以让平民开发者（可以理解为并不一定具有软件技术素质的人员）也能高效快速的构建应用程序。

如果基于这个思路，是不是大家觉得有一些类比？

当计算机刚起步的时候，大家还用打孔卡片来跑程序的时候，这时候一个牛逼的汇编语言可以说就是那个时代的低代码；再到后来C语言的普及，那对于汇编语言来说，C语言简直就是低代码…..以此类比，在我们这个时代，当面向对象的开发语言成为主流的时候，大家不可避免的在思考，是不是可以通过简单的可视化配置或者逻辑图就能实现编程呢？比如产品经理把产品设计好，时序图画好，自动就可以编程可以跑得程序。

命令式 vs 描述式

对于传统的软件开发，我们需要定义数据结构，定义变量，通过一行行命令式的代码，来精准的控制计算机执行每一步操作。这个过程中，对于开发者要求是比较高的，要有计算机运行的基本知识，要有算法的基本能力，而且时常要从计算机角度触发逻辑思考，包括线程池管理，内存管理等问题。这些，无疑都增加了开发者的门槛，同时也会增加工作量。

那低代码的目标就是减少工作量和对底层逻辑的关系，从此目标出发，我们可以构建一种描述式的编程方式。

所谓描述式的编程，就是把业务需求标准化，配置化，最优方案是可视化的配置的方式实现快速开发，这个过程中，开发人员不用关心计算机底层逻辑，只需要描述好数据模型，业务流程即可。

现在已经有很多成熟的低代码平台，比如Mendix这种，对于业务不复杂的情况，能够实现程序的快速构建。但对于很多程序员来说，还是很不适应这种编码方式。对于大多数程序员来说，一个好的低代码框架，反而是更香的那个面包，对于解决眼前的饥饿能够起到立竿见影的效果。

说一下我们熟悉的一些业务场景，包括工作流引擎，前端页面装修等，这些业务场景已经有了很成熟的低代码框架帮我们解决。比如工作流引擎，当你处理流程审批的业务场景的时候，如果没有工作流引擎，你可能还需要自己用状态机来硬编码你的程序，有了工作流引擎，我们可以实现业务配置化。

而业务编排思想，其实就是从命令式走向描述式的一次探索，所有低代码框架的核心思想就是业务编排能力，通过打造不同的原子，和原子之间的排列组合，从而实现业务能力。

低代码实现路径---业务编排

业务编排思想核心还是业务单元模块化，这个在某种程度跟微服务思想有点不谋而合。通过模块化去解耦复杂业务系统，化繁为简。下面贴一个简单的业务编排架构图：

【程序员日记】---从业务编排到低代码

1. 核心组件说明

a. 流程引擎，规则引擎和决策表。

这些概念在activiti这种框架中也是耳熟能详的，所以可以看出，业务编排也是依靠流程驱动实现的。只不过activiti关心的是橘色任务流转，比如OA审批流这种，而业务编排关心的事一个复杂业务本身中的业务粒度拆分和装配，例如下单流程，价格规则等等。

b. 上下文管理。

这个也是很重要的，在一个复杂的业务编排过程中，每个独立组件之间不可避免会有数据交互，而这些都交给了上下文处理。对于上下文管理，也有两种方式，一种是流程串联中的上下文传输，类似水流中的小纸船，他会在流程中通过业务控制实现上下文的传递，当然这种在实现和理解上都会更复杂一些。

还有一种方式类似工作台，这里可以做一个类比：n个工人按照一定顺序围绕一张工作台进行零件生产，每个工人都可以从工作台上拿去资源生产自己的零件，而每个工人会将自己生产的零件放在工作台上，同时也可以从工作台上领取别的工人做好的零件。而这个工作台就是上下文，所有的资源和零件在这个工作台之上是共享的。这种共享上下文的设计思想会让业务实现和理解变得简单，但它的问题在于组件的安全性和约束性，因为资源共享，所以每个组件都可以对资源进行修改，在软件开发中，有时候失去约束性，会在系统迭代的过程中出现变质，这就类似于面向对象编程中的封装性。

2. 案例讲解

这里举个业务编排的例子，我们以商品详情查看为例：

【程序员日记】---从业务编排到低代码

通过上图可以看出，在商品详情查看这个接口中，包含了商品基本信息查询，库存查询，售后查询，可售性查询等流程，然后最终才得到返回值。

你可以将瀑布流式的代码，转变成以组件为核心概念的代码结构，这种结构的好处是可以任意编排，组件与组件之间是解耦的，组件可以用脚本来定义，组件之间的流转全靠规则来驱动。

可能有的同学会说，这个业务用瀑布是写也问题不大嘛。那我再换一个更复杂一些的业务流程，大家是不是就可以看出业务编排的优势，下面给大家一个商城搜索接口的业务逻辑图：

【程序员日记】---从业务编排到低代码

上面的案例是笔者在采灵通系统开发中真实的一个案例，笔者最开始是采用瀑布方式实现的该搜索关键字处理逻辑。但之后进行了重构，通过引入开源框架liteFlow的业务编排框架，极大的简化的业务复杂度。基本可以实现流程图即代码的程度。具体代码就不贴在此处了，如果大家该兴趣，可以去研究一下liteflow这个业务编排开源框架。

从业务编排晋升为低代码框架

从业务编排晋升为低代码框架，需要改进几个地方，第一个就是流程节点的Node，在业务编排中，Node节点是一个可以自定义的业务模块，可以由程序员自行写业务逻辑。业务编排做到的是把复杂的业务变成简单的业务，但简单的业务也是需要开发的。如果我们把简单的业务也原子化和配置化，那么就可以成为一个入门级的低代码框架了，那么，我们的架构该如何调整呢？

【程序员日记】---从业务编排到低代码

首先我们需要将Node节点晋升为微流程节点，同时需要元数据模型支持。在微流程节点内，我们可以自定义CRUD模块，也可以自定义动作和发布时间，所有的缓存，查询都会定义为一个个的微流程节点，当微流程节点丰富度可以覆盖我们的业务代码需求时，我们就可以是先业务开发的配置化。然后在配合部署管理模块，实现代码的一键发布，这样就实现了一个简单的低代码框架。而这也是所有主流的商用低代码框架的思路。