伙伴云客服论坛»论坛 S区 S零代码 查看内容

1 评论

0 收藏

分享

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

之前总聊微效劳,今天换一个话题---低代码
低代码这个词也是最近这几年很火的概念,尤其是遇到大环境下行,很多大厂和互联网那个公司也在渐渐在低代码方向发力,当然,对于传统项目交付型的软件公司,低代码也具有相当大的吸引力。
如何理解低代码

用一个通俗易懂的说法,就是少写代码,并且降低开发门槛的方式,可以让平民开发者(可以理解为并不一定具有软件技术素质的人员)也能高效快速的构建应用程序。
假设基于这个思路,是不是大家觉得有一些类比?
当计算机刚起步的时候,大家还用打孔卡片来跑程序的时候,这时候一个牛逼的汇编语言可以说就是那个时代的低代码;再到后来C语言的普及,那对于汇编语言来说,C语言几乎就是低代码…..以此类比,在我们这个时代,当面向对象的开发语言成为主流的时候,大家不可防止的在考虑,是不是可以通过简单的可视化配置或者逻辑图就能实现编程呢?比如产品经理把产品设计好,时序图画好,自动就可以编程可以跑得程序。
命令式 vs 描绘式

对于传统的软件开发,我们需要定义数据构造,定义变量,通过一行行命令式的代码,来精准的控制计算机执行每一步操作。这个过程中,对于开发者要求是比较高的,要有计算机运行的根本知识,要有算法的根本才干,而且时常要从计算机角度触发逻辑考虑,包括线程池管理,内存管理等问题。这些,无疑都增加了开发者的门槛,同时也会增加工作量。
那低代码的目的就是减少工作量和对底层逻辑的关系,从此目的动身,我们可以构建一种描绘式的编程方式。
所谓描绘式的编程,就是把业务需求规范化,配置化,最优方案是可视化的配置的方式实现快速开发,这个过程中,开发人员不用关心计算机底层逻辑,只需要描绘好数据模型,业务流程即可。
如今已经有很多成熟的低代码平台,比如Mendix这种,对于业务不复杂的情况,可以实现程序的快速构建。但对于很多程序员来说,还是很不适应这种编码方式。对于大多数程序员来说,一个好的低代码框架,反而是更香的那个面包,对于处置眼前的饥饿可以起到立竿见影的效果。
说一下我们熟悉的一些业务场景,包括 工作流引擎,前端页面装修等,这些业务场景已经有了很成熟的低代码框架帮我们处置。比如工作流引擎,当你处置流程审批的业务场景的时候,假设没有工作流引擎,你可能还需要自己用状态机来硬编码你的程序,有了工作流引擎,我们可以实现业务配置化。
而业务编排思想,其实就是从命令式走向描绘式的一次探究,所有低代码框架的核心思想就是业务编排才干,通过打造不同的原子,和原子之间的排列组合,从而实现业务才干。
低代码实现途径---业务编排

业务编排思想核心还是业务单元模块化,这个在某种水平跟微效劳思想有点不约而同。通过模块化去解耦复杂业务系统,化繁为简。下面贴一个简单的业务编排架构图:

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

1. 核心组件说明

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

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

这个也是很重要的,在一个复杂的业务编排过程中,每个独立组件之间不可防止会有数据交互,而这些都交给了上下文处置。对于上下文管理,也有两种方式,一种是流程串联中的上下文传输,类似水流中的小纸船,他会在流程中通过业务控制实现上下文的传送,当然这种在实现和理解上都会更复杂一些。
还有一种方式类似工作台,这里可以做一个类比:n个工人依照一定顺序围绕一张工作台停止零件消费,每个工人都可以从工作台上拿去资源消费自己的零件,而每个工人会将自己消费的零件放在工作台上,同时也可以从工作台上领取别的工人做好的零件。而这个工作台就是上下文, 所有的资源和零件在这个工作台之上是共享的。这种共享上下文的设计思想会让业务实现和理解变得简单,但它的问题在于组件的安全性和约束性,因为资源共享,所以每个组件都可以对资源停止修改,在软件开发中,有时候失去约束性,会在系统迭代的过程中呈现蜕变,这就类似于面向对象编程中的封装性。
2. 案例讲解

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

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

通过上图可以看出,在商品详情查看这个接口中,包含了商品根本信息查询,库存查询,售后查询,可售性查询等流程,然后最终才得到返回值。
你可以将瀑布流式的代码,转变成以组件为核心概念的代码构造,这种构造的好处是可以任意编排,组件与组件之间是解耦的,组件可以用脚原本定义,组件之间的流转全靠规则来驱动。
可能有的同学会说,这个业务用瀑布是写也问题不大嘛。那我再换一个更复杂一些的业务流程,大家是不是就可以看出业务编排的优势,下面给大家一个商城搜索接口的业务逻辑图:

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

上面的案例是笔者在采灵通系统开发中真实的一个案例,笔者最开端是采用瀑布方式实现的该搜索关键字处置逻辑。但之后停止了重构,通过引入开源框架liteFlow的业务编排框架,极大的简化的业务复杂度。根本可以实现流程图即代码的水平。详细代码就不贴在此处了,假设大家该兴趣,可以去研究一下liteflow这个业务编排开源框架。
从业务编排晋升为低代码框架

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

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


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

业务编排是实现低代码的途径之一,但不是唯一途径。尤其是当我看到ChartGPT4.0出来之后,人工智能,可以通过一个网页草图自动生成html代码时,我觉得,这可能才是低代码的最终归宿吧。
作者:京东物流 赵勇萍
内容来源:京东云开发者社区

回复

举报 使用道具

相关帖子
全部回复 (1)
查看全部
转发了

举报 回复 支持 反对 使用道具

本版积分规则 高级模式
B Color Image Link Quote Code Smilies

据为己有
注册会员
主题 17
回复 20
粉丝 0
|网站地图
快速回复 返回顶部 返回列表