云原生和微服务架构下-企业级低代码平台的选型思考（低代码云开发）
Hello大家好，我是人月聊IT。
今天我准备跟大家分享一下，在云原生和微服务架构下企业级低代码平台的选型思考。因为在2023年我跟很多客户和朋友沟通的比较多，大家都在谈论企业怎么样选择一个适合的低代码开发平台？
一个企业的需求如果仅仅是你现在有一个小的新应用要开发，或者是说你的一个部门小团队想去选择一个低代码开发平台，那这个事情就相对来说比较简单。但是如果是你企业整个it部门，你在做整个企业的IT应用架构规划，希望引入一个平台级的低代码开发平台工具，希望以后企业新的应用和组件模块都基于这个平台去做开发，那这个时候你要考虑的问题就会多得多。
所以说我今天想讲的重心也仍然是对于企业级的低代码开发平台，我们再去选型的时候，究竟应该考虑哪一些关键的因素？
业界对低代码开发厂商有一个标准的能力评估体系，他把它分为了8个方面，其中对于开发工具、数据模型、流程模型、业务场景适配，更多的是在讲它的功能性需求。对于生态体系和开放性服务能力，后续运维和安全学习成本应用性，更多的是在讲它的非功能性需求。从这8个方面的评估体系我们可以看到对于低代码平台整个技术架构的先进性，没有专门作为一个评估的维度。
业界对低代码产品的选型思考分为两个方面：第一个就是产品选型的关键指标，除了刚才讲到的基础功能以外，它也更加强调产品的易用性、扩展性、安全、技术架构的先进性、生态的开放性，同时他给出了一个产品选型的矩阵。
上面图是低代码开发平台选型2022年的一个白皮书的数据，所以在这个地方也就明确提出了低代码开发平台，它包括了低代码和零代码两类，因此我们在选型的时候一定要考虑你究竟是面向技术开发者还是面向没有任何技术背景开发经验的业务人员。因为这种两种不同的类型对我们去选择低代码开发平台的时候影响相当的大，所以结合业界低代码产品的能力评估，选型的思考，我把整个低代码开发平台分为4类，就是面向目标用户群体不一样。
第一类就是完全面向业务用户，没有任何技术背景。第二类是有技术部门的人员，这类人员虽然有技术背景但是没有开发经验。第三类就是开发人员，但是有基础的编码经验，比如说就是刚毕业或者是1~2年的经验，还有一类就是我已经有熟练的开发经验的开发人员。对于这4类我们再去做低代码开发平台选型的时候，相应的一些关键能力要求都不一样。
第一类：面向业务用户
对于第一类面向业务用户的，我们更多的希望就是拖拖拽拽表单加流程，实现完全的即开即用零代码开发。对于这种一般都是以SaaS类的低代码轻应用为主，所以我们经常看到的类似于搭搭云，易搭云都是这种类型。
第二类：有技术背景无开发经验
第二类就是对于技术部门有技术背景但是没有开发经验的人员，对于这种场景它更加强调了流程引擎和表单的配置能力。当然这种场景它不能叫完全的零代码，它仍然会有少量的脚本代码的编写，包括和外部接口集成的能力。所以这一类的典型厂家，比如我们看到的明道云，得帆，用友，金蝶等就属于这种类型。
第三类：面向有基础编程经验的开发人员
对于这类场景基本上能够解决绝大部分的复杂业务场景和场景的集成。这种场景需要开发人员有基础的编码的经验，对于低代码平台，它本身也是需要你提供一个面向开发的独立开发环境，有强大的二次开发能力和外部集成能力。对于这种对于国外西门子的Mendix，或者是对于国内早期的普元的EOS平台，基本上就是走的这个路线。
第四类：面向熟练开发经验的人员
对于第四种就是完全面向有熟练编码经验的开发人员。对于这种类型我们有时候他不能严格意义上叫低代码开发平台，更多的就是叫快速开发平台，或者是提供一个已经成型的开发框架或者是开发环境，对于这种类似于开源的jeecgboot，JNPF，若依等快速开发平台，基本上就是属于这种类型。
所以综合以上的分析，我们可以看到企业级的低代码平台在选型的时候，它的关键能力的要求究竟应该是什么样的？
企业级低代码平台关键能力要求
首先说明一下企业级低代码开发平台一定不是零代码开发平台，它是需要一个有足够的开放性、扩展性，能够快速的灵活对定制，又能够满足复杂业务场景实现的这么一种低代码开发平台。所以我把它分成三大能力的要求。
第一类就是基础能力要求，这一块就是包括我们通常说的流程引擎的能力、组织权限的能力、可视化的表单配置、对象建模、数据建模、表单类的需求、规则引擎的能力。
第二类就是云原生架构要求。在当前云原生架构下面，我们更加的强调第一代码开发平台相应的上云的能力的要求，所以我把它分了几个关键的点，第一个就是低代码开发平台，它本身应该是微服务架构，同时开发完的应用也要是微服务架构也要符合当前主流的前后端分离。第二个就是他需要支持容器云部署，支持水平扩展。第三个是他最好能够支持项目源代码的导出，部署包的导出，方便我们通过低代码开发平台开发完成的应用，能够脱离低代码开发平台运行。第四个就是支持低代码开发项目中过程中多项目多应用的协同，包括支持和当前主流的DevOps持续集成过程的协同。
第三类是非功能性需求要求。在这个里面最最重要的它就必须要支持多租户、多组织多项目的模式，能够去做好租户资源权限数据的隔离。第二个叫扩展性，它需要支持自定义开发代码扩展和二次开发，定制开发组件。第三个是开放性，他支持API接口的暴露和外部的集成，同时也支持调用外部已有的API接口服务的能力。最后一个就是后续的运维性，低代码开发平台开发完的应用，也能够纳入企业已有的统一的it运维监控体系中去。
所以低代码开发平台它的整个的参考架构是怎么样呢？就拿远行我们自己的低代码开发平台来说，该平台是基于主流的微服务架构打造基于对象驱动的核心思想，实现对象建模、数据建模、权限建模、流程建模、规则建模，表单建模核心的建模能力，同时可以快速发布到云原生的微服务运行环境。
所以从我这个架构图大家也可以看得比较清楚，我把它分为了除了你需要提供一个云原生的技术平台的这个底座以外，你第一代码整个开发它分为了低代码的开发环境和低代码的运行环境。
低代码开发平台开发完以后，通过DevOps持续集成和发布到运行环境，发布到运行环境的就是一个个低代码开发出来的微服务应用，它本身可以支持容器云部署，它本身也是前后端分离的，它本身也会纳入到整个微服务治理和it运维监控体系里面去。
低代码平台基于微服务技术架构体系的一个参考，这一个内容大家都比较熟悉了，就是说你我低代码开发平台开发的应用，你怎么样跟当前主流的微服务开发框架，微服务的治理框架进行相应的融合。
对于低代码开发平台开发技术栈的一些思考，类似于它的配置中心的选择、服务的管理、服务的通信、基础的消息缓存认证、校验权限服务的能力，包括一些我们说的丰富的组件库组件服务的能力，比如说报表服务、文件服务、搜索服务，下面一个就是我们的一个数据中心，它是不是支持结构化的数据，非结构化的数据，包括多数据库的支撑能力。
低代码平台支持多组织和多租户
好了，再回到低代码开发平台，我刚才谈到的里面有一个很重要的叫非功能性需求就是低代码开发平台必须要支持多租户和多组织。当你想把某一个低代码开发平台发展为企业级的低代码开发平台的时候，你会看到我们可能有内部的开发者，外围的开发商、合作伙伴都可能需要用我这个平台进行相应的应用组件模块的开发，所以说每一个开发者，每一个合作伙伴，他就是一个大的租户，但是某一个开发厂商可能还需要开发多应用，所以说租户下面又有应用，应用下面还划分了进一步的微服务模块。所以说从这个多租户多应用应用下面的微服务模块，你怎么样去管理这种相应的多租户的组织架构，包括资源数据的隔离，你必须要考虑清楚。
那么低代码开发完的应用，它有可能还需要支持多组织架构，就是说你要去考虑多组织架构下面的组织的分级的授权，组织和组织之间的数据权限的隔离，这些东西你必须都要考虑到。
低代码平台对象建模和数据建模能力
对象建模和数据建模是低代码开发平台的一个核心基础能力。从上边这个图我们可以看得到，对象建模式往往是整个低代码开发平台最核心的内容，它向下支持数据库建模和数据表的生成能力，向上支撑表单和报表的配置能力。向外支持核心的API接口对外服务能力的暴露。
但是我们现在看到当前大部分的低代码开发平台，其实它没有对象建模的能力，更多的是表单驱动或者是非对象驱动，在这种场景下就容易导致底层数据库表形成大量的数据孤岛，而且数据没有办法横向关联集成，所以你会发现你虽然用了低代码开发平台，但是又是建了一个个烟囱式的小低代码应用出来，这个不是我们期望看到的。
所以我一直强调对象建模是低代码面向复杂业务实现的一个关键的能力。
低代码平台的表单建模
表单建模其实在这一块各种低代码开发平台相对来说能力都相当强，包括可视化的表单设计，报表的配置，可扩展性，其他的需求。所以在这个地方我只想强调一个关键点，就是在整个表单建模里面，我们更加强调面向企业级面向行业应用的时候，它的一些行业的基础组件库，具备行业属性的这一些公共的组件库的这么一个积累。
低代码平台的流程建模
对于工作流流程权限，这个也是低代码开发平台应该具备的一些基础能力，涉及到流程的设计、流程的监控、权限的建模，其他的一些需求。
在这个地方我只想强调一个关键点，就是整个流程建模里面，我们一定要去注意流程表单的设计，表单和流程引擎的全联动，包括在流程处理中任何一个活动节点的时候，我基于流程的动态权限的配置和设计。这个我看了很多低代码开发平台，对于这一块的能力相对来说是比较弱的。
低代码平台的规则建模
对于规则建模来讲，其实当前大部分的低代码开发平台没有完善的规则引擎能力，因为我在10多年前就在使用相应的一些规则引擎，所以类似于原来主流的jRule，Drools这一些开源的规则引擎，它其实仍然也是偏重，有技术复杂度和使用难度。这些规则引擎也不是说有引入到一个完整的低代码开发平台的一个必要性，所以我的理解较好的规则实现。主要的参考方式主要有以下三类。
第一类就是对于界面事件处理的JS脚本，我一直认为这一块就是没必要去做特别的规则引擎化，更多的你可以在自定义的JS脚本里面实现扩展规则，这一些扩展规则就包括了数据的校验、接口的调用，简单业务逻辑的处理。
第二个就是API接口服务的编排，也就是说将对象建模的能力发布为API以后，我还提供一个API的接口编排工具来实现组合规则，这个地方是有相应的可视化的工具来实现的。第三个就是叫我把它叫做自开发规则。就是当前的低代码开发平台，它是不适合实现复杂的业务规则，那么我就可以通过自己编写代码去实现这些规则，最终再将这些规则暴露为API接口，注册和接入到低代码开发平台。
低代码平台的外部集成能力
接下来就是外部的集成的能力，我们讲的外部集成主要有三类，第一个就是单点登录和页面集成，他需要支持单店登录统一认证。第二个就是接口集成，他需要支持接口集成的能力，一个是低代码平台通过暴露API接口给外部使用，第二个是调用外部的API接口集成。第三个是数据集成，底层它需要支持常见的基于ETL的数据集成能力，能够实现数据的采集、数据的转化、数据的清洗、数据的装载等基础功能。
当然对于企业级低代码开发平台，你必须要去考虑的二次开发和自定义代码的扩展能力，他需要支持平台表单对象、数据、流程、组件层级的代码扩展能力，应该覆盖应用的组件布局页面功能逻辑的代码扩展，使用户可以通过代码扩展和定制相关的组件。
所以说低代码开发平台不应该是一个封闭的平台。当低代码开发平台提供的组件库不够的时候，我们在前端二次开发的时候，我还可以自己很方便的去扩展自己的前端UI的组件库。而对于后端一样的，我们要去支持后端的二次开发和扩展，包括我可以自己编写代码，自己发布为API并接入到低代码开发平台，包括对于接口二次开发的扩展，集成能力的二次开发的扩展，都是你去做一个企业级低代码开发平台必须要考虑的内容。
云原生技术架构满足度
最后一个就是对于我们整个低代码开发平台的技术架构的先进性和云原生架构的满足度方面的内容，我把它分成了几方面的。
第一个就是对于开发态的它的技术架构的要求，这里面的关键能力就包括了，你必须要去采用主流的微服务开发框架，你使用的各种微服务技术组件应该符合当前主流的选型的要求。类似于服务的注册发现，微服务网关、服务的限流熔断，服务链路监控等。同时整个低代码应用应该是一个前后端分离的一个架构，你应该采用主流的前端框架。
同时低代码平台需要独立可扩展的技术组件能力，类似于消息安全缓存等。
第五个就是对于API接口的设计开发，应该采用主流的Http RestAPI接口来实现，同时这一些接口还能够纳入到API网关进行统一的接口管控和治理。
第六个就是低代码开发平台开发完成的应用，支持源代码导出独立部署，最终的低代码开发完成应用能够脱离低代码开发平台运行。
对于运行态，我们又把它分为了几个关键的能力。第一个就是他应该支持容器化部署，也支持虚拟化部署，同时对于部署架构需要可以扩展。对于部署架构的可扩展一方面是低代码平台自身组件能力可扩展，一个就是低代码开发平台开发完成的应用可以做分布式集群化的扩展。同时低代码平台开发完的应用应该能够纳入企业整体的云原生运维监控体系，从资源到应用到接口服务都应该能够纳入整体的监控体系。
对于过程态主要又有几个方面。第一个就是低代码开发平台开发需要支持和企业已有的DevOps过程实践，同时低代码平台的输入需要和前端的需求管理系统，敏捷研发管理平台进行协同。其次就是低代码平台开发完成的应用，能够持续集成和敏捷交付到我们的生产环境。而对于其他需求就包括了外部集成的支持，二次开发的一些支持，多租户架构的一些相应的支持能力，这一些都是在当前云原生架构下面，你如果需要去搭建一个企业级的低代码开发平台必须要支撑的一些关键能力。
好了，今天的简单的分享就到这个地方，希望对大家有所启发。
