低代码开发平台对云原生整体解决方案的关键补充

　　今天准备再谈下对低代码开发平台的扩展思考，最近2到3年，低代码开发平台可以算作一个小热点，不论是传统的BPM厂家，还是原来的快速开发平台厂家，包括还有一些中台建设厂家都逐步推出自己的低代码开发平台。
　　对于低代码开发平台的分析，我在前面专门写过一篇文章可以参考
　　从快速开发平台到低代码开发平台
　　从这篇文章大家可以对低代码平台有个初步的了解。如果简单地总结低代码开发平台，可以理解为一切皆是可配置，可建模的。而本书建模的关键又在于对业务领域和现实世界的大量实践和抽象。因此这篇文章我准备再谈下低代码平台的一些核心要素，以及低代码开发平台和云原生整体解决方案架构之间的关系。低代码开发平台概述
　　对于低代码开发平台，百度词条有一个基础定义，如下：
　　低代码开发平台（LCDP）是无需编码（0代码）或通过少量代码就可以快速生成应用程序的开发平台。通过可视化进行应用程序开发的方法（参考可视编程语言），使具有不同经验水平的开发人员可以通过图形化的用户界面，使用拖拽组件和模型驱动的逻辑来创建网页和移动应用程序。低代码开发平台在完成业务逻辑、功能构建后，即可一键交付应用并进行更新。
　　如果再对这个定义里面的关键内容做下提取，其核心包括：无须编码或少量编码可视化和可配置化，通过组装或配置构建应用
　　在这两点之外，还有一个关于过程支撑层面的，即整个开发完成的应用上线或交付过程应该足够简单和自动化，包括上面提到的可以实现配置立即生效，实现一键交付等。
　　低代码开发平台的核心要素
　　当前有很多提供低代码开发平台的服务商，各家的方案或整体架构虽然有差异，但是本质的内容基本还是一致，即一切皆是可配置，可建模的。
　　可以设想下开发一个简单功能的过程，基本也就是数据库表设计，前端界面设计，编写逻辑层代码和接口实现业务规则，挂接流程引擎实现流程，配置功能和数据权限等。
　　所以任何一个低代码开发平台都需要围绕这个核心去抽象和建模，找出共性的和业务无关的东西进行技术沉淀，即我们常说的。完全标准的东西直接标准化
　　非标准但是同样场景的东西，通过抽象差异来实现参数化配置
　　大家可以看到，实际我们LCDP平台的构建基本就是围绕上面思路展开。那么一个LCDP平台的核心要素究竟是啥，具体我重新画了一张图来说明。
　　即LCDP平台的核心包括了上图中的数据建模，表单建模，流程建模，权限建模，报表建模和规则建模几个关键部分的内容，通过这些建模组件，包括这些组件之间本身的协同来完成一个完整业务系统和功能的构建。
　　对于上图中的内容我不准备太详细说明，这里只谈里面的一些关键点。
　　数据建模这里一般有三种做法。其一是从后到前，即直接进行类似数据库的设计，然后朝前生成对象和数据访问接口等；其二是前到后，即直接进行表单设计，通过表单属性定义来生成后端数据库表；其三是对象建模，先生成对象，然后对象朝前服务于前端界面，朝后生成数据库表。而这里建议是对象建模双向生成和服务思路，这样基本更满足OO和领域建模思想。
　　你可以很容易实现大量可复用的前端UI界面组件，类似组合框，Grid表格，树列表等，也很容易实现UI控件和数据建模对象的绑定。但是表单建模的难点不在这里，而是在于规则能否提取可配置，和规则引擎的集成，和流程引擎集成，表单中基于事件驱动的多控件协同。这些内容在写代码实现并不复杂，但是要做到完全灵活可配置不容易。
　　原来谈到快速开发感觉从单表支撑到多表支撑，从多表到复杂关系和关联表支撑不容易，现在看多表支撑仅仅是基础的基础，没有难度。真正的难度仍然在规则配置的灵活，在事件协同和控制逻辑的灵活。
　　流程建模不能是简单的HWF人工工作流引擎，而应该增加自动化业务流集成能力，同时自动化的业务活动节点本身还可以调用规则引擎接口实现复杂的规则处理。其次，流程和权限本身是相对紧耦合的内容，在流程建模中还必须实现和权限模型的紧密协同和集成。
　　也就是说权限集成能力，规则集成能力，自动化业务流集成能力才是流程建模的重点。
　　因为即使一个复杂业务规则无法通过规则引擎，通过可配置方式实现，我们还可以开发一个独立的微服务来实现业务规则并提供API接口，这个时候只需要在流程引擎中增加一个自动化业务编排节点，并配置来调用这个API接口即可。
　　权限模型，基础仍然是RBAC，核心是资源定义，因为对于细化到按钮级的操作，数据分域分组全部都可以作为资源的抽象展现形式。数据权限往往是最难进行定义和配置的内容，因为数据权限既可能涉及到纵向字段级别的细粒度定义，也会涉及到横向不同的组织单元的细粒度定义。
　　上图中我将规则引擎和报表引擎作为能力扩展项，没有这两个能力也不影响一个基本的表单实现并挂接流程运转起来。
　　规则建模是最难的，大家也可以观察到规则引擎这么多年的发展仍然很难完全实现灵活可配置化。好的快速开发平台往往提供了规则实现的自定义脚本，但是你真正用后会发现越来越是个大坑，这种脚本大量编写，导致后期极其难以维护。
　　规则本身和上层实现松耦合，定义好的规则本身应该可以灵活的应用到上述的表单建模，流程建模，报表建模过程中。
　　报表建模没有任何难点，仅仅是实现工作量的事情，因此也可以将报表建模看做是表单建模的一个能力扩展。报表建模需要考虑更多的导出，打印，可视化美观展现等。从单业务系统到组织级扩展
　　对于低代码开发平台，在引入的时候一定要考虑是仅仅开发一个业务系统，还是要作为组织级的共性基础技术平台，即后续所有的业务系统都需要基于低代码开发平台进行开发。
　　当平台上升到组织级的时候，你会发现和前面讲过的企业内部的信息化建设，应该参考类似私有云PaaS平台的平台应用构建模式。
　　这个平台既包括了技术平台，也包括了共性能力的业务平台。
　　那么一个企业在前期，能够真正积累落地的共性基础业务平台只有4A平台，即我们常说的实现人才，组织的统一管理和归口，同时基于4A来构建统一门户，实现统一认证和单点登录。
　　那么基于低代码开发平台开发的应用实际应该是整个架构里面的一个小应用。
　　大家可以看下当前主流的低代码开发平台提供的整体架构，整体思路和我前面描述一致。即平台要提升为组织级的平台，必须开始考虑共性业务平台的建设，顶层统一门户的建设。
　　实际上再看上面图，会发现跟我前面谈微服务的时候谈到的基于平台应用方式来构建整体的微服务架构完全一致。也就是说对于中间的应用我们完全可以拆分为更小粒度的微服务来构建。
　　那么低代码开发平台本身就需要将自己两方面能力做分离：其一是分离其中的平台层或技术中台能力。其二是将应用构建模式分离为松耦合的微服务，并基于API集成
　　但是实际上大部分的低代码开发平台无法做到这两点。或者说当前的低代码开发平台不是基于微服务架构思想来进行构建的，或者连OO思想也算不上。也正是这个原因，很多低代码开发平台只能够实现简单的单表，多表的CRUD功能。低代码开发平台和云原生
　　在我前面的文章里面，给出过一个新的云原生解决方案平台整体架构如下：
　　在这个云原生技术平台架构中，整体的底层是容器云平台和DevOps过程支撑平台。在上面基于整个软件生命周期分为了开发态，运行态和运维态。开发态重点是开发框架和环境，低代码开发平台运行态重点是容器云平台运维态重点是运维监控平台，服务链监控
　　也就是说对于开发态，在我原来沟通的时候重点是开发框架和环境，而现在将其提升为低代码开发平台。即低代码开发平台本身也是基于微服务架构对当前主流微服务开发框架的进一步封装和整合，这些封装和整合就包括了前面谈到的共性技术组件和业务组件的抽取，代码开发的可配置化和可编排化，统一的门户集成和报表展现等。
　　为何低代码开发平台是整个云原生方案的关键补充？
　　对于云原生方案在前面已经谈过多次，核心要素是微服务，DevOps和持续集成，容器云，服务网格等。所有这些技术的目的都是为了实现应用能够朝远端的快速，无缝迁移和集成。
　　那么对于软件产品送拿到需求到最终交付上线，实际上受到两个方面的效率影响，一个是开发效率，一个是软件生命周期的集成和交付效率。而对于DevOps可以理解为解决了整个软件开发过程中集成和交付的效率问题，但是没有解决开发效率问题。
　　那么开发效率本身的解决本身又包括两个途径：其一是开发人员本身技能提升，效率提升其二是软件开发共性资产库积累，低代码开发平台工具的使用等
　　因此可以看到将低代码开发平台用好确实是可以提升软件开发效率。很多开发人员可能会抵触低代码开发平台，但是低代码开发平台本身也有两类。
　　一类是完全符合主流的分层开发框架，代码和逻辑也完全开放，一类是自己进行黑盒封装并定制化自己的规则和脚本等。对于第一类平台实际上足够开放，你最终的应用也完全可以脱离低代码开发平台运行，实际需要慎重的则是第二类平台。
　　其次，对于一个好的经过大量实践验证的低代码平台，对于简单业务功能场景功能的实现绝对是完胜一般水平的开发人员，你也不用担心平台自动化实现出来的功能有大量低级bug的问题。在我很早就说过，如果一个开发人员的工作本身就是大量重复，那么最终发展趋势是一定会被低代码开发平台或AI发展所取代。
　　低代码开发和云原生平台协同
　　经过前面分析后可以看到。
　　可以构建一个低代码开发平台，通过该平台来进一步解决开发效率提升问题。同时代代码开发平台本身也进行代码的自动化开发和持续集成，持续部署和交付动作。
　　云原生下的低代码开发平台应该更加开放和友好，比如提供相应的代码导出，部署包导出，对于导出的内容可以直接在标准的eclipse开发环境编译构建，可以进行部署，并脱离低代码开发平台本身运行。将技术平台提升为低代码开发平台
　　在前面我分享我们自己产品进行微服务架构改造和演进的时候就谈到，为了更好地支撑上层各个微服务模块的开发和集成，构建了一个基于微服务底层架构的开发技术平台。
　　这个技术平台是在SpingCLoud的基础上进行了各自业务组件，技术组件的扩展，同时整合了共性的类似消息，4A，流程引擎等能力，通过该平台可以更好的支撑上层功能应用的开发。
　　整个技术平台的统一可以参考下面两张图：
　　统一技术平台
　　统一技术栈
　　由于前期公司技术平台本身已经实现了公共流程平台4A，因此在构建新技术平台的时候重点是对于原来这块共性能力进行改造和集成。同时技术平台对微服务开源框架和工具进行整合，实现在整个项目建设和实施中最常用的一些关键能力自动化，这些包括：最基本的单据维护功能可配置共性基础组件封装和可复用自定义查询功能全自动化自定义报表功能的配置和实现
　　在上面这些基本都实现了，接着的重点就是将整个技术平台提升为一个完整意义上的低代码开发平台。平台的核心要素实际上我在前面已经说明，那么重点自然就在于表单建模和可视化设计实现，同时实现表单建模和流程，权限，数据建模之间的协同和集成。
　　对于自定义表单实现参考界面如下：
　　我们希望做到和实现的就是：
　　表单数据模板：可在表单基础上配置，应用查询条件、列表字段排序、列表的操作按钮、表单操作按钮等，一键生成到系统菜单，快速实现应用零代码开发。
　　表单设计流程引擎：表单挂接到流程节点，变成流程表单，可根据每个节点的业务情况再次配置表单权限、表单前后置事件，根据每个节点进行打印模块配置。
　　表单设计代码生成器：通过表单器配置表单布局、权限、数据视图等基本要素后，结合代码生成器生成前端、微服务接口、持久层等各个层次代码，只需手动特殊业务代码即可，节省80以上代码开发时间。
　　在前期我们不做规则引擎，原因我在前面已经分析和说明过。那么对于复杂功能的实现就不可能通过表单设计器全部自动化来完成。
　　对于这种情况，我们还是沿用传统的代码生成的方式，即将复杂功能实现过程中的核心基础能力全部按微服务框架分层模式全部生成出来，你可以将生成出来的代码导入到你的开发环境。导入后就是完全可以编译通过的版本。
　　你只需要基于这个来扩展你需要增加的规则和逻辑即可。
　　当然对于简单功能的实现和部署交付，完全做到零代码，一键进行部署。但是我们同样提供部署包和源代码导出的能力，也就是最终导出的内容完全可以脱离我低代码平台进行运行。
　　符合当前中台和微服务架构思想
　　在整个平台构建的时候我们使用SpringCloud作为微服务分布式系统，并且FTMP还基于SpringBoot进行了通用性模块的封装，例如鉴权服务、调度服务、消息服务等等；前端使用VUE作为开发组件进行二次封装和改造并自研了前端组件库，使之更适合企业级应用系统的使用体验。
　　对于低代码开发平台的构建不仅仅是采用微服务开发框架，更加重要的是符合当前主流的中台和微服务架构思想。简单来说就是：平台开发各个小应用本身是可以做到完全自治和相互间解耦应用的构建进一步贯彻SOA分层构建思路
　　对于SOA分层构建思路，一个重点就是面向对象和API接口方式进行整个应用构建。
　　简单来说就是对于表单建模和数据建模之间要通过对象建模接口建模来实现解耦。
　　首先是进行一个完整的对象定义，对象本身朝下可以生成数据库表，朝上可以发布API接口服务。而对于表单建模不再直接和数据库表关联，而是直接引用对应的API接口服务，在这种情况下对应API接口服务本身也会启用强服务契约模式进行定义和设计。
　　当有了独立的接口层的时候，可以看到要实现上层功能组合或组装将变得更加容易和方便，即我们可以提供一个类似传统BPEL流程或服务编排的工具，可视化来进行上层业务的接口组装和编排。
　　当然你也可以只使用数据建模对象接口建模功能，来实现中台基础能力或API能力开放平台，而对应上层前端应用自己开发，这些场景和模式也可以做到完全支持。
　　以上则是我们构建低代码开发平台的关键思路，一个完全基于标准的微服务架构和SOA分层思路构建的完全开放的低代码开发平台。
　　在低代码开发时代，我个人更加推荐这种基于对象服务化的分层开发模式。这个本身也是更加贴近我当前中台和微服务的构建思路。即你首先去构建你的对象并发布你的服务，然后再考虑如何基于这些发布的服务类构建上层的应用。即我们的开发过程横向拆分为两端。而中间基于服务进行松耦合连接。
　　即：微服务服务前端应用。
　　不是简单的我们传统应用拆分小了，而且我们的前端应用模块，后端能力模块也全部微服务化，形成我们当前说的平台中台前端应用的分层模式。
　　这种模式如果再和我们当前的DevOps和容器化技术结合，那么整个开发完成的应用就更加容易持续发布和交付，也更加容易在后续继续弹性资源扩展和调度。