低代码平台建设经验总结

目录

前言

一、低代码平台简介

1.架构图

2.内容详解

3.基础服务

4.数据层

 5.中间件

6.治理治理涉及的内容

7.建设中/后续计划

总结

---

前言

在某公司做低代码平台开发接近2年，收获了很多，踩了很多坑，现在做个年终总结和经验设计分享。欢迎指正

---

一、低代码平台简介

网上开源的低代码平台大家自行搜索，我们服务和其他公司的不一样，作为互联网公司，我们一方面要支持快速生成业务模块（人人都可以创建项目），另一方面还要接入各种有高流量要求，业务模型独立的业务方。在模型构建，api开放，服务治理等方面要求更高

二、架构设计

1.架构图

2.内容详解

    2.1 请求来源：普通用户的手机app，企微，PC端操作，公司内部上游系统，公司外部合作方上游系统

    2.2 网关：1.针对不同的请求来源进行网关隔离，统一的sso权限认证，进行单点登录设置token

                     2.从网关开始根据请求头/租户进行核心/非核心链路隔离（默认APP请求全部核心，系统间调用通过租户号配置路由）。底层存储，服务都进行隔离

    2.3 模型：

              2.3.1：通用工具：包括多租户限流rateLimit工具，统一异常处理工具，自动幂等注解工具等

              2.3.2：通用前端组件：下拉，树形，表格，部门，人员，js执行器等

              2.3.3：业务模型（小前端）：人员模型，条件矩阵模型，商品创建模型，组织架构模型，客服工单模型，绩效模型,人事OA，行政，财务，资产，供应链等等；

                         解释：这些业务模型是通过基础服务抽象出来的特殊的业务模型，比如条件矩阵模型需要使用流程，动态表单，组织架构，OA的部门功能。我们将其进行了封装提供了服务化的功能，通过api接入即可，也支持引入sdk进行个性化改造。

   2.4保护层

          2.4.1 过载保护: 虽说上游一般都有自己的熔断限流，但是自己的服务也要做熔断限流hystrix（旧项目），sentinal；

         2.4.2 安全认证：网关层会做通用的权限认证，安全认证。但是作为基础服务也要做业务安全认证，比如组件的合法性，请求数据的权限校验，拉取数据量控制，敏感数据加密等等；

        2.4.3 SPI适配器：主要针对需要拉取项目自己开发的场景，比如针对条件矩阵：数据源可以通过spi扩展机制默认是从mysql拉取，可以开发自己的spi注入后从配置中心，内存等拉取；

        2.4.4 日志留存：因为涉及很多敏感数据，以及操作会按照等级留存；

3.基础服务

      3.1流程引擎： 改造/重写activit6.0的源码更轻量级，源码23张表缩减为12张核心表，优化了数据库表结构索引设计，扩展了28张业务配置表 。个性化功能：动态审批人功能，流程快照，循环审批，有序图展示，灵活驳回跳转，同异步父子流程（隔离级别）

      3.2 动态表单引擎：前端：可视化编辑器，组件库。后端数据存储。交互协议格式JSON-schema（借鉴formily）

      3.3 配置管理平台：提供对组件管理，角色权限，流程配置，表单配置，流量配置等；

      3.4 数据报表/数据分析：非实时数据走帆软报表，实时数据走从库；

      3.5 OA人事：不做人事逻辑，封装人事核心数据对外提供服务，全接口缓存，定时刷新

      3.6 矩阵规则引擎：封装业务性质表达式生成SDK，提供前端配置一键生成业务表达式，表达式预编译功能。支持spi自定义数据源

      3.7 消息中心：分为两种消息：1.企微消息。2.MQ通知消息，通过配置中心配置mq主题，当系统流程触发时会自动发送mq消息，消息数据库持久化支持溯源

      3.8 批处理任务：详见另一篇博客批量任务后端如何平滑处理_qq1076472549的博客-CSDN博客上游系统批量提交任务场景下，如果做流量整形，监控，数据一致性，时效性等落地方案https://blog.csdn.net/qq1076472549/article/details/121436196?spm=1001.2014.3001.5501

4.数据层

        4.1 缓存：redis集群（阿里云/腾讯云），核心配置几乎都走redis缓存，本地缓存只缓存一些固定数据

        4.2 事务方面：基于事件库+流程状态机实现软事务，最终一致。在和外部系统对接/异步操作/批处理中使用较多

        4.3 数据库：mysql集群云部署，读写分离，分库分表（插件类似于sharding-jdbc的公司组件）。部分服务在切换TIDB

        4.4 搜索：

               1.toc实时流程数据的查询走mysql从库

               2.T+0查询：订阅binlog走云ES，从腾讯云es的监控显示95%的查询1s以内，复杂聚合5s以内，入流量约5kb/s

               3.T+1查询和数据分析走帆软报表和大数据团队

 5.中间件

         中间件有专门团队维护，引入依赖包，配置，直接接入

6.治理治理涉及的内容

      6.1 服务支撑： 注册中心zk，配置中心Apollo，服务平台

      6.2 治理支撑：流量控制：多租户令牌桶，服务容错，熔断，降级，超时重试sentinal，灰度发布k8s,链路跟踪cat，路由分发（3区/4区运维管控），自动扩容（k8s 服务集群cpu使用率超过阈值自动新增机器）

     6.3 功能支撑 ：监控告警：cat，opm，granfa；消息服务，文件服务，大数据，报表，安全，防爬虫，负载均衡nginx（ip_hash）,ribbon（轮询），devops等等

     6.4 架构治理：codeReview/旧版本代码接口的通知替换/僵尸代码很少被依赖代码的清除/调用深度检测，架构优化迭代

    6.5 开发治理：单元测试，冒烟用例执行，技术分享，能力分层，人员管理等等

还有什么需求迭代管理，进度管理，跨部门协作，发布体系，文档管理就不写了

7.建设中/后续计划

   7.1 在OLAP方面还缺失很多，下一步需要重点规划

   7.2 作为一个基础服务，需要提供更多的沙箱环境，协调测试能力，隔离功能

   7.3 异步数据一致性依旧是很急迫的问题，需要提供更全面的接入方案

   7.4 需要支持内存引擎，支持springReactor接口。因为上游系统不止B端还有C端，异步和内存引擎构建可以显著提升吞吐量

  7.5 未完待续

8.技术栈 

 开发技术：springboot,mybatis,vue，spring reactor，ddd领域建模

 中间件：apollo,xxjob,rabbitmq,redis,nginx,activit6,avaitor,dal,mysql,tidb,大数据

 服务治理：cat，grafana,opm,k8s,sentinel,hystrix

   

总结

 这套架构服务目前已经替换了公司所有的泛微流程，接入了30多个上游服务，核心表数据量千万级，稳定性做到了4个9，持续为公司降本增效，为业务方提供更专业的服务