共计 2586 个字符，预计需要花费 7 分钟才能阅读完成。
之前总聊微服务，明天换一个话题 — 低代码。
低代码这个词也是最近这几年很火的概念，尤其是遇到大环境上行，很多大厂和互联网那个公司也在缓缓在低代码方向发力，当然，对于传统我的项目交付型的软件公司，低代码也具备相当大的吸引力。
如何了解低代码
用一个通俗易懂的说法，就是少写代码，并且升高开发门槛的形式，能够让平民开发者（能够了解为并不一定具备软件技术素质的人员）也能高效疾速的构建应用程序。
如果基于这个思路，是不是大家感觉有一些类比？
当计算机刚起步的时候，大家还用打孔卡片来跑程序的时候，这时候一个牛逼的汇编语言能够说就是那个时代的低代码；再到起初 C 语言的遍及，那对于汇编语言来说，C 语言几乎就是低代码….. 以此类比，在咱们这个时代，当面向对象的开发语言成为支流的时候，大家不可避免的在思考，是不是能够通过简略的可视化配置或者逻辑图就能实现编程呢？比方产品经理把产品设计好，时序图画好，主动就能够编程能够跑得程序。
命令式 vs 形容式
对于传统的软件开发，咱们须要定义数据结构，定义变量，通过一行行命令式的代码，来精准的管制计算机执行每一步操作。这个过程中，对于开发者要求是比拟高的，要有计算机运行的基本知识，要有算法的根本能力，而且时常要从计算机角度触发逻辑思考，包含线程池治理，内存治理等问题。这些，无疑都减少了开发者的门槛，同时也会减少工作量。
那低代码的指标就是缩小工作量和对底层逻辑的关系，从此指标登程，咱们能够构建一种形容式的编程形式。
所谓形容式的编程，就是把业务需要标准化，配置化，最优计划是可视化的配置的形式实现疾速开发，这个过程中，开发人员不必关怀计算机底层逻辑，只须要形容好数据模型，业务流程即可。
当初曾经有很多成熟的低代码平台，比方 Mendix 这种，对于业务不简单的状况，可能实现程序的疾速构建。但对于很多程序员来说，还是很不适应这种编码方式。对于大多数程序员来说，一个好的低代码框架，反而是更香的那个面包，对于解决眼前的饥饿可能起到空谷传声的成果。
说一下咱们相熟的一些业务场景，包含 工作流引擎，前端页面装修等，这些业务场景曾经有了很成熟的低代码框架帮咱们解决。比方工作流引擎，当你解决流程审批的业务场景的时候，如果没有工作流引擎，你可能还须要本人用状态机来硬编码你的程序，有了工作流引擎，咱们能够实现业务配置化。
而业务编排思维，其实就是从命令式走向形容式的一次摸索，所有低代码框架的核心思想就是业务编排能力，通过打造不同的原子，和原子之间的排列组合，从而实现业务能力。
低代码实现门路 — 业务编排
业务编排思维外围还是业务单元模块化，这个在某种程度跟微服务思维有点不约而同。通过模块化去解耦简单业务零碎，化繁为简。上面贴一个简略的业务编排架构图：
1. 外围组件阐明
a. 流程引擎，规定引擎和决策表。
这些概念在 activiti 这种框架中也是耳熟能详的，所以能够看出，业务编排也是依附流程驱动实现的。只不过 activiti 关怀的是橘色工作流转，比方 OA 审批流这种，而业务编排关怀的事一个简单业务自身中的业务粒度拆分和拆卸，例如下单流程，价格规定等等。
b. 上下文治理。
这个也是很重要的，在一个简单的业务编排过程中，每个独立组件之间不可避免会有数据交互，而这些都交给了上下文解决。对于上下文治理，也有两种形式，一种是流程串联中的上下文传输，相似水流中的小纸船，他会在流程中通过业务管制实现上下文的传递，当然这种在实现和了解上都会更简单一些。
还有一种形式相似工作台，这里能够做一个类比：n 个工人依照肯定程序围绕一张工作台进行整机生产，每个工人都能够从工作台上拿去资源生产本人的整机，而每个工人会将本人生产的整机放在工作台上，同时也能够从工作台上支付别的工人做好的整机。而这个工作台就是上下文，所有的资源和整机在这个工作台之上是共享的。这种共享上下文的设计思维会让业务实现和了解变得简略，但它的问题在于组件的安全性和约束性，因为资源共享，所以每个组件都能够对资源进行批改，在软件开发中，有时候失去约束性，会在零碎迭代的过程中呈现变质，这就相似于面向对象编程中的封装性。
2. 案例解说
这里举个业务编排的例子，咱们以商品详情查看为例：
通过上图能够看出，在商品详情查看这个接口中，蕴含了商品根本信息查问，库存查问，售后查问，可售性查问等流程，而后最终才失去返回值。
你能够将瀑布流式的代码，转变成以组件为外围概念的代码构造，这种构造的益处是能够任意编排，组件与组件之间是解耦的，组件能够用脚本来定义，组件之间的流转全靠规定来驱动。
可能有的同学会说，这个业务用瀑布是写也问题不大嘛。那我再换一个更简单一些的业务流程，大家是不是就能够看出业务编排的劣势，上面给大家一个商城搜寻接口的业务逻辑图：
下面的案例是笔者在采灵通零碎开发中实在的一个案例，笔者最开始是采纳瀑布形式实现的该搜寻关键字解决逻辑。但之后进行了重构，通过引入开源框架 liteFlow 的业务编排框架，极大的简化的业务复杂度。根本能够实现流程图即代码的水平。具体代码就不贴在此处了，如果大家该趣味，能够去钻研一下 liteflow 这个业务编排开源框架。
从业务编排晋升为低代码框架
从业务编排晋升为低代码框架，须要改良几个中央，第一个就是流程节点的 Node，在业务编排中，Node 节点是一个能够自定义的业务模块，能够由程序员自行写业务逻辑。业务编排做到的是把简单的业务变成简略的业务，但简略的业务也是须要开发的。如果咱们把简略的业务也原子化和配置化，那么就能够成为一个入门级的低代码框架了，那么，咱们的架构该如何调整呢？
首先咱们须要将 Node 节点晋升为微流程节点，同时须要元数据模型反对。在微流程节点内，咱们能够自定义 CRUD 模块，也能够自定义动作和公布工夫，所有的缓存，查问都会定义为一个个的微流程节点，当微流程节点丰盛度能够笼罩咱们的业务代码需要时，咱们就能够是先业务开发的配置化。而后在配合部署治理模块，实现代码的一键公布，这样就实现了一个简略的低代码框架。而这也是所有支流的商用低代码框架的思路。
总结
业务编排是实现低代码的门路之一，但不是惟一门路。尤其是当我看到 ChartGPT4.0 进去之后，人工智能，能够通过一个网页草图主动生成 html 代码时，我感觉，这可能才是低代码的最终归宿吧。
作者：京东物流 赵勇萍
内容起源：京东云开发者社区
