如果经常看我们的头条号，应该已经关注到远行科技已经在SOA，微服务，容器云和DevOps方面有多年的技术积累和实践案例。在2018年也推出了基于当前主流云原生思想的云原生技术中台整体解决方案。

在整个云原生技术中台解决方案本身是覆盖了开发，运行，治理运维全生命周期管理。对于整体的全过程端到端支撑能力我们推出了DevOps过程能力支撑平台，在运行态推出了PaaS技术服务中台和容器云PaaS平台，而在治理层面即参考ServiceMesh服务网格的思路推出了完整的去中心化微服务治理架构。

而对于低代码开发平台，当前一般将其纳入到APaaS的范畴。对于低代码开发本身也是远行科技整体云原生技术解决方案中覆盖开发态度的一个关键内容。

近年来零代码、低代码行业发展迅速，国内APaaS创业厂商如明道云、伙伴云、轻流、黑帕云等均为模型驱动型厂商，奥哲、华炎魔方以及云厂商代表阿里宜搭等则以可视化IDE模式，传统快速开发平台和BPM厂商如普元，JEPaaS，广州天翎切入APaaS市场。国外软件平台发展强劲，主要厂商如OutSystem、Mendix等在市场上均有较高知名度。

从当前我们整体的云原生技术解决方案看到，在开发态不仅仅是提供一个完整的微服务开发框架和环境，提供各种共性的技术组件能力，更加重要的就是提供一个低代码开发平台来实现通过配置化 少量代码的方式来实现应用的快速开发。

同时低代码开发平台和我们当前的DevOps支撑平台紧密协同，低代码开发完成的应用可以快速的部署和交付到容器云环境。云原生下的低代码开发平台应该更加开放和友好，比如提供相应的代码导出，部署包导出，对于导出的内容可以直接在标准的eclipse开发环境编译构建，可以进行部署，并脱离低代码开发平台本身运行。

下面再对一些关键问题进行整理和说明。

和市面低代码开发平台的区别

注意，对于低代码开发领域当前又细分为两类，一类是类似搭搭，宜搭，氚云这种偏零代码开发的平台，一类是是存少量代码和脚本编写的低代码开发平台，类似JEPaaS，Jeecg-boot这种快速开发平台。

对于零代码开发平台当前很多都是由IDE和界面直接从前驱动开发和配置，而对于低代码开发平台一般则是基于模型驱动的思路来进行功能模块开发。

也就是我们的低代码开发平台是完全基于微服务架构的低代码开发平台。同时和业界标准的云原生技术支撑设施能够完全协同和融合。

对于低代码开发平台的构建不仅仅是采用微服务开发框架，更加重要的是符合当前主流的中台和微服务架构思想。因此远行科技的低代码开发平台不是走零代码开发的思路，而是真正的基于模型驱动和SOA架构思想，允许少量代码开发和融合。

其核心思想是：

• 低代码开发的小应该应该是一个个独立的微服务
• 应用的构建进一步贯彻SOA分层构建的思路，通过服务层解耦
• 低代码开发应该是模型驱动的，这个模型核心是对象和数据模型

对于SOA分层构建思路，一个重点就是面向对象和API接口方式进行整个应用构建。

在低代码开发时代，我个人更加推荐这种基于对象服务化的分层开发模式。这个本身也是更加贴近我当前中台和微服务的构建思路。即你首先去构建你的对象并发布你的服务，然后再考虑如何基于这些发布的服务类构建上层的应用。即我们的开发过程横向拆分为两端。而中间基于服务进行松耦合连接。

即：微服务 服务 前端应用。

为何叫基于低代码的PaaS自服务平台

如果大家看过我前面关于传统企业IT架构转型，企业私有云PaaS平台构建方面的文章就明白，对于企业整体的IT架构规划来说，这个里面有一个重点就是底层的技术支撑平台建设。这个技术支撑平台包括了诸多的内容，如下：

• 容器云的底层资源池和资源调度中心
• 消息，缓存，文件等各种技术服务组件
• 门户 4A 流程引擎的基础共性平台
• 共性平台和技术服务组件的API能力开放和集成
• 微服务开发框架和环境
• 微服务治理和监控运维平台

在前面我一直在强调，低代码开发最终完成的就是一个个的微服务应用，这个微服务本身需要有底层平台能力，后端的管控治理能力做支撑。

低代码开发平台不仅仅是一个开发平台，更加重要的是通过平台在开发的时候如何调用平台可复用的已有技术和业务服务能力，通过开发平台完成的微服务后续的运行管理，运维监控，治理等。

而我们的低代码开发平台则是基于当前我们已有的强调PaaS平台和技术服务平台之上的，只有这种模式构建的应用才可能做到独立自治，后续可以灵活弹性扩展并满足高性能和高并发的业务需求。

没有银弹，是低代码不是零代码

注意，我们做的是低代码开发平台而不是零代码。

企业信息化和业务系统远远比一个简单的OA系统复杂，即使是OA系统你也会看到中大型企业的OA系统也无法完全通过零代码模式开发和完成。

这一方面是底层的技术架构，高可用性方面的问题。一个方面是面向集团企业带入的多组织，权限管理，业务规则逻辑等的复杂性引入。

对于复杂业务规则的实现，当前主流做法是引入规则引擎来进行灵活配置，但是如果是复杂业务规则规则引擎也很难配置，而且引入大量难以管理和后期运维的脚本代码。

在前面实际我已经强调了我们的低代码开发实际是前端界面开发设计和后端能力分层，中间通过服务层进行解耦，当前核心仍然是对象模型驱动。

在解耦后，我们的思路是对于前端开发尽量完全做到可视化设计和灵活配置。而对于后端开发则是标准对象模型发布的API接口能力自动化，但是对于复杂规则的实现仍然是自己编写代码然后发布为标准的Http Rest API接口服务，前端设计器能够通过少量的JS代码来调用后端服务能力。

如果这样还是无法满足复杂规则实现。

那么我们的低代码开发平台还支持你将对象建模，界面设计等完成的配置开发内容完全导出为源代码，你在该源代码基础上进行接口扩展，在扩展接口中增加你自己的业务规则和逻辑定义实现。

比如保存按钮，事件触发后就调用表单保存操作对数据进行保存。但是实际上你会看到在保存前你可能需要进行业务规则和逻辑处理，在保存后你可能触发其它关联操作。

//Form.SaveBefore();//Form.Save//Form.SaveAfter();

当前在保存前你还可能调用多个API接口进行多个校验。

为何叫企业级低代码开发平台？

首先我提一个问题给大家，即当前很多做低代码开发平台的厂家，这些厂家是否建设和实施过类似大中型企业负责的业务系统。

实际对于大部分厂家都没有做过，更多的是参考国外低代码开发平台的做法，当前主流的一些SaaS小应用的抽象归纳，形成自己的低代码开发平台。包括前面我谈到的，如果整个平台完全是从界面设计一直驱动到后端对象和数据库表，那么整个前端和后端很难解耦，你会发现当涉及到有多表共同实现的业务规则和逻辑的时候很难实现。

MDA模型驱动思路

真正好的低代码开发平台一定是类似MDA模型驱动的，是基于服务层来实现前端界面设计和后端数据提供之间的解耦。这个类似当前云原生技术实践中的ServerLess无服务器化，即FaaS层和BaaS层分离。BaaS层很多服务能力开始代码开发，但是FaaS层界面设计和服务组合实现低代码和灵活编排。

而对于远行科技自身，我们本是也建设和实施类似财务共享类大型企业业务系统，这个大应用本身又包括了报账，预算，资金，发票等多个微服务应用。而我们的低代码开发平台本身是来源于我们的系统设计和开发实践。

即将完成的低代码开发平台本身就能够满足财务域复杂业务场景的设计和实现，对于业务需求变更的快速配置开发上线等需求。

服务编排能力

前端开发的灵活性不仅仅体现在表单设计，JS简单脚本代码编写，更加重要的是支撑轻量的微服务编排能力，即对于标准的API接口服务，我们可以直接进行服务编排组装，形成组合服务能力API供前端调用。

在传统模式下这种服务组合可能需要手写后端代码来完成并发布为一个API接口，但是现在这块能力可以通过服务编排引擎来完成，进一步提升了前端开发和配置的效率。

企业级应用的多租户，多组织模型

当你面对一个企业级应用开发的时候，那么就必须考虑多组织架构，同时考虑对于开发者的多租户架构。举个简单的场景来说，一个企业本身也可能有多个细分的开发团队，每个开发团队都负责开发不同的微服务应用。

那么各个开发团队之间的租户数据，权限应该做到完全隔离。其次你开发的一个应用需要满足企业负责的多组织架构模型，包括组织，用户，授权模型。

而这些内容需要有一个强调的4A平台和流程引擎平台来进行支撑，同时通过上层的统一的云门户来进行整合，实现所有微服务应用的集中管理，单点登录和统一认证等。

简单来说，理想化的场景是：

一个开发团队首先申请创建一个独立租户，在租户创建完成后开发团队可以维护具体的开发配置人员，同时开发团队可以创建一个或多个微服务应用。

对于每个微服务应用可以规划具体的业务功能菜单和功能权限配置。对于每一个业务功能的实现则是采用表单建模，对象建模，规则建模，流程建模等各个建模功能来完成。完成的业务功能挂接到具体的功能菜单，并进行功能权限和数据权限的授权操作。

在一个功能完全开放完成后可以持续发布和交付到云门户中，即开发完成的微服务应用能够自动增加和集成到云门户的统一入口中，只有一个业务用户授权使用该微应用，同时业务用户登录了云门户，那么就能够快速的进入到微应用中。