今天再写一篇文章，谈下最近进行低代码开发平台产品架构设计和研发实践过程中的一些关键点的思考。在前面写过的关于低代码开发平台的文章中，基本已经将平台本身的核心架构和建模思路表达清楚，在这里不再重复叙述。
前两天我准备华南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进行数据逻辑隔离。或者在一个大的数据库中企业不同的Schema来进行隔离。
那么如何选择?
简单来说就是开发大的应用一定是要独立部署资源完全隔离，但是如果你是开发的一个小应用那么完全可以采用多租户架构思路一个大数据库并进行数据逻辑隔离即可。
最后，低代码平台本身还会用到流程引擎，类似消息，缓存各种技术服务能力。那么这些技术服务能力本身也需要是多租户架构，做到数据隔离。这个租户不是在组织或开发团队层面，而是需要到具体的一个个业务系统层面。每个业务系统才是最底层最细化的租户。
技术平台和服务集成
技术平台和技术服务能力提供，技术服务的集成是企业级低代码开发平台的另外一个关键点。这点可以再参考下云原生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应用则需要在门户里面进行授权处理。
只有授权后的用户在登录门户后的快捷菜单才能够看到该应用。剩余的具体功能菜单授权则是通过进入到具体的应用系统里面的系统管理功能来完成。
对于应用里面的系统管理功能也是4A的一个关键内容。那么这个系统管理也需要考虑多种租户架构，各个应用系统里面的系统管理基础数据和配置要做到完全隔离。
低代码开发平台关注的是具体业务功能，对于常用的组织，人员，用户这些信息统一都应该作为门户的底层基础数据能力提供给低代码开发完成的应用。而不是在低代码开发平台完成的应用中还单独搞一套基础系统管理功能。
原文链接：https://mp.weixin.qq.com/s/I5_cL0b0377VMUwnKsHaSw
