本文转载自微信公众号《谈IT》，作者何明禄。转载本文请联系悦潮IT公众号。今天再写一篇文章，谈谈近期低代码开发平台产品架构设计和研发实践中的一些重点。在之前关于低代码开发平台的文章中，平台本身的核心架构和建模思路已经基本表述清楚，这里不再赘述。前两天在准备华南CIO大会数字化转型云原生的主题演讲材料，其中一份材料涉及到低代码开发平台。在这个PPT页面中，我们继续强调，我们实际上做的是面向企业的低代码开发平台，而不是零代码开发平台，尤其是在规则引擎技术没有实质性突破的情况下，没有灵丹妙药软件开发，规则复杂还是需要自己开发。也就是说，整个平台更多的是基于类似Mendix的架构设计思路。云原生有一个核心的技术实践，就是ServerLess无服务器架构。该架构将应用程序的开发分为两层：BaaS后端即服务和FaaS功能即服务。一个核心思想是在BaaS中积累足够好的服务有时候，你的开发应用不仅仅是写前端的函数或者脚本，组装后端BaaS提供的API服务接口能力。这个思路本身就是低代码开发，是云原生实践下推荐的低代码开发思路。其次，任何应用系统都应该考虑解耦，微服务，包括与底层技术平台的云化，那么低代码开发平台本身也应该是微服务架构，遵循分层架构的基本原则。低代码平台本身应该是分布式和可扩展的，这也是开发高可用和高性能应用程序的基础。如果企业只是想快速开发一个类似填写周报、考勤记录这样的简单应用，那么目前主流的低代码SaaS服务平台基本可以满足需求，并且可以做到完全零代码。但是如果要开发一个类似于企业内部的业务系统，这个系统可能是几万人用的，秒级并发几千，就算是简单的OA系统也不是一般的低代码平台能做到的处理。所以如果你正在构建一个低代码开发平台，不要只关注可视化表单设计、可视化流程设计和拖放配置。尽管这些很重要，但它们并不是企业级低代码平台的重点。底层技术架构本身的高可靠性和可扩展性是关键点。第三，企业自身存在遗留的IT系统。低代码开发平台此时如何切入？如何保证低代码开发平台开发的应用能够很好的与现有的IT业务系统进行集成和融合？目前很多低代码开发平台都没有考虑到这个问题，更多的开发是独立的信息孤岛，无法与现有的其他业务系统很好的对接，形成融合协作。如果继续按照这种思路开发和配置应用程序，那么后续开发的应用程序的集成和控制将是一个很大的问题。我今天所做的关于低代码开发平台架构的设计与实践的思考，就是基于以上前提。在今天的思考中，我会重点关注以下几个方面。多租户架构技术服务平台与集成基于API的规则定制门户与应用集成低代码平台多租户架构低代码平台中的多租户需要从两个层面来讨论，首先是多租户-低代码平台自身架构设计的租户问题，其次是低代码平台开发的应用多租户问题。先说第一个问题。低代码开发平台本身的多租户问题其实更复杂。如果是SaaS层面的低代码，需要考虑甲方企业和企业内部开发团队两个多租户的数据隔离。即使是企业内部的私有云部署，也需要考虑企业是否有子公司。不同的子组织，开发团队应该只能看到自己开发设计的应用，看不到其他应用。这类似于张三和李四开发了两个应用系统，SRM和CRM。如果张三说要开发SRM，那么李四设计的CRM系统中的对象、接口、流程模型张三应该是看不到的，张三也不能随意使用CRM系统的数据对象。如果张三需要CRM系统中的客户数据，也需要使用开放的API接口调用。也就是说，对于SRM和CRM这两个系统，数据不仅在开发阶段对开发者是隔离的，对于开发出来并最终上线的应用也是数据隔离的。下面说说第二个问题开发之后的应用隔离。对于自主研发的CRM和SRM应用，如何部署和交付？一种方法是完全独占部署资源。两个应用程序都使用独立的数据库实例和独立的应用程序中间件容器。它们是单独和相互部署的。它也是完全独立、自治和解耦的。另一种思路是，类似于SaaS的多租户架构设计，开发的应用最终都存储在一个大型数据库中，数据在逻辑上通过类似Org_ID的组织ID或租户ID进行隔离。或者隔离大型数据库中企业的不同Schemas。那么如何选择呢？简单来说，大型应用的开发必须独立部署，资源完全隔离，但如果是开发小型应用，则可以采用多租户架构思想和大型数据库，逻辑上隔离数据。最后，低代码平台本身也使用流程引擎，类似于消息，缓存各种技术服务能力。那么这些技术服务能力本身也需要是一个多租户架构来实现数据隔离。这个租户不在组织或开发团队层面，而是需要到具体的业务系统层面。每个业务系统都是最底层、最细化的租户。技术平台与服务融合提供技术平台与技术服务能力，技术服务融合是企业级低代码开发平台的又一重点。对于这一点，可以参考云原生ServerLess的思想，即技术能力的提供不应该在应用系统内部提供，而应该单独剥离下沉到云端的BaaS层能力平台，并作为独立服务提供。只有独立提供技术服务，最终低代码开发的应用才具有高扩展性。低代码开发的应用更多的是业务场景、业务规则和逻辑的实现，不需要关心底层技术平台的细节。比如低代码平台本身也需要使用缓存能力。那么这个缓存就应该使用云平台提供的缓存服务。即使缓存服务存在性能瓶颈，考虑如何扩展的也是云平台，而不是低代码平台本身。有两种类型的技术平台和服务。公共流程引擎、4A平台各类技术服务：包括消息、缓存、文件、日志等上述平台及技术服务。如果是搭建企业级的低代码开发平台，那么这些平台服务能力也必须是独立的，下沉到企业内部的私有云PaaS平台以服务化的方式提供，同时需要满足上面提到的多租户架构要求。你是什??么意思？低代码开发平台的运行，即使是测试环境，也离不开上述平台或技术服务能力。即低代码开发平台开发的功能最终发布后，需要调用上述平台提供的API接口服务才能成功运行。低代码开发平台最终从测试环境交付迁移到生产环境，这些服务能力接口也需要进行切换，调用生产环境的BaaS层服务能力。因此，要搭建一个企业级的低代码平台，首先要做的就是搭建一个内部的云原生技术平台或者内部的私有云PaaS服务平台。这是构建低代码平台的基础。否则，你最终通过低代码平台开发出来的应用很难成为企业级应用。还是那句话，低代码平台只是把我们传统的业务系统开发流程尽可能自动化配置，但是整个自动化流程还是需要遵循现在微服务架构，分层，平台+应用的构建思路。基于API的规则定制和集成上面已经提到了。我们所做的是低代码而不是零代码。类似于国外Mendix低代码开发平台的思路。代码开发。否则，你会写很多脚本代码，这些脚本以后维护起来会比较困难。10多年前，我亲自主持过一个类似CS架构的快速开发平台产品。那时基本的对象、流程、界面设计都可以灵活配置。复杂的规则逻辑也提供了脚本编辑器来完成。但是我最后发现的问题是，脚本编辑器里面写的脚本越来越多，后期很难维护。因此，对于复杂规则的实现，还是需要自己编写代码来实现。开发者开发API并暴露给低代码平台进行对象建模后，对象最终会生成后台数据库对象和数据表，必须是开发者可见的。然后开发者可以基于这些数据库对象开发自己的接口API服务。对于接口的开发，接口服务的最终部署和运行需要独立管理，即需要提供一个类似于API全生命周期管理的平台。该平台可以进行API接口的设计、开发、部署和运营管理。开发者开发的API接口最终部署到本平台，同时通过API网关或能力开放平台对外开放能力接口。低代码开发平台在设计前端接口时，可以灵活调用这些可复用的API接口服务能力，完成复杂的逻辑处理。即通过简单的前端脚本代码完成前端接口与API接口服务的集成协同。多种API接口的组合编排我在之前的文章中已经提到，一个好的低代码开发平台应该提供一个可视化的微服务API接口编排工具，用于服务的组合编排。举一个简单的例子，当你提交采购订单时，你需要进行预算控制。平台层本身提供预算控制API接口服务，但需要输入项目代码。因此，必须先根据采购订单号查询物料编码，然后再调用预算控制服务。根据采购订单号查询商品编码本身就是另外一个API接口。那么就需要对这两个API接口服务进行组装编排。该场景下，可以使用前端可视化服务编排工具完成界面的组装编排。不必自己编写代码来完成。门户与应用集成最后，让我们谈谈门户集成。先说场景和期望的目标吧。对于一个企业来说，往往会构建多个IT系统。多个系统搭建完成后，一般会搭建一个EIP统一入口，实现统一认证和单点。用户登录门户后，除了能看到场景通知、公告和待办事项信息。该门户还提供了一个重要的功能，即：所有连接的IT系统的快速入口连接。通过这个快捷连接，可以快速单点登录到特定的业务系统，比如CRM系统、SRM系统等，那么低代码开发平台就需要与门户集成。简单来说，通过低代码开发平台开发的应用，在最终发布应用并完成相关应用授权配置后，可以自动体现在门户的应用快捷入口中。比如CRM系统已经开发上线，我授权张三使用。那么张三登录门户后应该可以看到CRM系统的连接，点击连接后也可以进入CRM系统。门户授权和应用系统功能授权门户授权和应用系统功能菜单和数据授权是两个概念。门户授权要解决的问题是某个用户是否可以使用某个系统，比如张三是否可以使用CRM系统，而CRM系统中的授权要解决的问题是CRM系统中有哪些功能菜单CRM系统张三可以用。因此，当开发人员在低代码平台上创建CRM应用程序时。第一个关键步骤是在门户中自动注册CRM应用，CRM也自动完成与门户的单点集成。如果现有应用程序连接到门户，您将看到门户管理员在门户中手动注册和配置应用程序。开发者自己可以自动授权使用这个应用，但是其他可以使用CRM应用的用户需要在门户中进行授权。只有授权用户才能在登录门户后在快捷菜单中看到该应用程序。其余具体功能菜单授权通过进入具体应用系统中的系统管理功能完成。应用中的系统管理功能也是4A的重点内容。那么这个系统管理还需要考虑多租户架构，各个应用系统中系统管理的基础数据和配置必须完全隔离。低代码开发平台专注于特定的业务功能。将常用的组织、人员、用户信息作为门户的底层基础数据能力，提供低代码开发的应用。而不是在应用程序中单独设置一套基本的系统管理功能，由低代码开发平台完成。
