首页 文章 精选 留言 我的

精选列表

搜索[低代码v2.0],共10000篇文章
优秀的个人博客,低调大师

每日一博 | 贴吧低代码高性能规则引擎设计

作者 | 百度智能小程序团队 导读 本文首先引入多利熊业务介绍,引出多利熊业务建设权限系统的痛点,接着分别从权限系统模型、权限系统设计以及多利熊业务业务应用方面详细探讨了具体的方案和设计,最后对权限系统设计思考,对数据维度建设抛砖引玉,让大家一起思考解决方案。 全文5212字,预计阅读时间14分钟。 01 业务介绍 多利熊,是百度旗下的本地生活服务平台。多利熊旨在为用户提供特低价优惠的品质服务,基于百度的AI和双引擎能力,以改变市场格局之势迅速推进,为本地商家提供丰富的营销渠道,决心成为本地生活市场的重塑性力量。 多利熊覆盖餐饮、酒店、景区、休闲娱乐、丽人等众多品类。用户可以花更少的钱享受多利熊甄选的本地生活品质服务。成为多利熊分销达人,自购更省钱,分享直卖可赚取佣金,锁粉政策可让达人长期赚取用户自行下单佣金,发展下游达人组建团队更可赚取团队佣金。 多利熊架构是如何支撑起整个业务生态运转,如下图所示: 如图所示,多利熊整个业务架构分位三层。包括:生态场景层、平台支撑层、基础建设层。 多利熊生态场景:多利熊除了在百度的双引擎、百家号、私域中进行分发外,还扩展到了微信生态圈,建设了多利熊微信小程序,用于在微信生态的分发,通过微信群、微信分享、微信达人引流。除了自建外,也通过合作方式引入第三方服务商、自研商家、本地生活服务平台,从而打造多元化、多类型的本地生活服务生态圈。 多利熊平台支撑:多利熊建设了大量平台,包括:商户平台、运营平台、审核平台、小编平台、分发平台、干预平台、质量平台等等。通过丰富的平台,降低运营成本、提升商家接入效率,从而更好的支撑业务的高速发展,快速迭代。 多利熊基础建设:多利熊的基础建设层,通过集成小程序及百度中台的众多沉淀系统,迅速支撑业务快速迭代。包括:小程序自研的服务化治理方案:天路、天眼、BRCC;小程序沉淀的数据多维度分析报表和稳定性建设监控和治理手段;以及百度丰富的中台系统:交易中台、营销中台、互动中台、审核中台等等。 从图中可以看到,整个多利熊业务架构中,平台角色众多,权限系统面临非常多的挑战。 平台众多,各个平台的账号系统也会存在差异性。权限系统如何支持各平台的隔离设置,保证平台数据的合规性和安全性? 多个平台中存在众多业务角色、角色存在上下级关系,大家需要协同工作。权限系统如何支持高效的配置,保障多角色协同、高效、便利操作? 多个平台基于不同语言开发。权限系统如何保证接入的便捷性? 具体我们是如何建设,解决这些问题的呢?下面将详细介绍下。 02 权限系统介绍 2.1 权限系统模型 RBAC(role-based access control ):基于角色的权限访问控制。 RBAC是一种围绕角色和权限定义的访问控制机制,在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。 RBAC四个核心组成部分: S(Subject):主体,一名使用者或自动代理人 R(Role):角色信息,被定义为一个授权等级的工作职位或职称 SE(Session):会话级别的身份权限表达,S,R或P之间的映射关系 P(Permissions):权限, 一种存取资源的方式 RBAC 定义了三个主要规则: 角色分配:只有当主体选择或分配了角色时,主体才能行使权限 角色授权:主体的活动角色必须为主体授权。使用上面的规则 1,此规则确保用户只能承担他们被授权的角色 权限授权:只有为主体的活动角色授权了权限,主体才能行使权限。对于规则 1 和 2,此规则确保用户只能行使他们被授权的权限 RBAC的四个模型: Flat RBAC:基本的 RBAC 模型,基本的概念是 用户被分配给角色,权限也被分配给角色,用户通过角色获取对应的权限 Hierarchical RBAC:角色被组织成分层结构,其中“较高”层级的角色从的“较低”层级的角色继承所有权限 Constrained RBAC:向角色添加职责分离 (SOD) 的实施 Symmetric RBAC:添加了权限角色审查的要求,类似于 Flat RBAC 中描述的用户角色审查 四种模型的等级和功能描述: Flat RBAC模型结构: Hierarchical RBAC模型结构: Constrained RBAC模型结构: 静态职责分离: 互斥角色:同一个用户在两个互斥角色中只能选择一个 基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的 先决条件约束:用户想要获得高级角色,首先必须拥有低级角色 动态职责分离: 会话和角色之间的约束,可以动态的约束用户拥有的角色,如一个用户可以拥有两个角色,但是运行时只能激活一个角色。 Symmetric RBAC模型结构: 2.2 权限系统设计 RBAC模型如何在我们的实际场景中选型和改造是一件深入思考的事情。首先我们要基于我们的业务场景圈定权限系统核心功能。 我们做的是本地服务tob业务,所以对于商家我们会有商家平台,除了商家的管理平台之外,我们还需要对于o端建设平台进行管理,以及我们开发同学的干预平台等,这些平台都需要权限管控。每个系统都有各自的页面,每个页面都有自己的功能实现,大到页面权限的管控,小到按钮的管控,在未来的业务发展中都是我们权限系统所需要考虑的。所以我们的权限管理相对来说任务也是比较繁重的。 针对我们以上的业务场景和需求形态,我们首先敲定了权限系统的核心职责: 页面菜单权限的管控 功能组权限管控 按钮功能权限管控 支持多业务线 我们基于Flat RBAC设计了如下的RBAC模型: 基于我们设计的RBAC模型,继续细节的考量 支持多业务线接入和业务线业务隔离 需要支持菜单权限、功能组权限、按钮权限的管控 首先考量业务线支持问题,对于这个事情我们使用了单独的表来表达产品线信息,在设计user,role 和 func 表,都需要与业务线信息表关联。 于是我们思考如何支持页面菜单权限、功能组权限和按钮权限的问题。 菜单权限、功能组权限和按钮权限都隶属于功能权限,于是我们使用一张表进行功能权限的表达,和前端页面的树形结构表达相映射,构造一个功能权限树,于是我们最终落地的ER图如下: 业务线 对于不同的系统,各自的用户体系、角色管理、权限管理都是有差异的,需要满足不同的系统的诉求,首先要做的是对各个系统的隔离。 我们设计了业务线信息的表,核心字段如下: 该表主要描述业务线的基础信息内容,用于更好的管理和配置。 业务线隔离的实质是用户表、角色表和权限表都需要指定业务线的prod_id,这样在BRAC模型的三个核心角色里都做到了业务线隔离,每个系统在使用自己的数据的时候都需要指定自己的prod_id。 用户 从业务角度分析来看,商家平台是对外面向商家登录的用户账号体系,对于o端来说,是面向我们运营同学,bd同学使用的场景,使用的内部账号体系,所以,我们这里就有这不同的用户登录体系。 我们面临着多种用户体系形态,所以,我们就兼容不同的用户体系设计,由此我们设计的用户表核心字段如下: prod_id、user_type 和 login_id 组成联合唯一建。 角色 FLAT BRAC模型的角色并没有涉及角色的继承关系,我们现在的业务没有涉及到这么复杂的角色关系,所以我们用最简单的方式来表达角色信息,从而减少对于角色身份的管理和维护。 角色的核心字段如下: prod_id 和 en_name组成联合唯一建。 权限 权限这块是我们思考最多的地方,我们希望可以通过统一的标准将前端页面的功能权限进行约定。 我们去了解前端使用的设计,无论是b端还是o端前端,都是我们自己的前端团队,他们讲使用统一的前端框架和风格进行设计,这样对于我们得权限系统来说就是最好的情况,我们首先需要面对的就是这样风格的权限管控。 首先看下我们b端的前端页面样式如下: 这里左侧为页面菜单栏,右侧为菜单栏对应的页面,里面就是涉及到的各个功能模块。 我们这里要处理的就是: 菜单栏的权限管控:菜单是否展示,菜单层级结构以及菜单设计的页面权限内容 页面权限:页面里涉及到的功能权限 功能组:页面中某些功能模块的功能权限 按钮:按钮的权限 于是我们准备改造权限表为树状结构如图所示: 基于这样的树状结构,我们就可以描述出前端的整个权限管控内容,权限的核心字段如下: 整体的核心设计就是这样,结合我们的微服务框架理念,我们整体的业务交互图如下: 现在我们权限系统已经在支持着多利熊B端平台和O端平台的权限管控,并正在支持小编平台,后续我们将继续服务更多平台的权限管控。 2.3 多利熊业务应用 基于上述权限系统的设计,使得多利熊业务在面对庞大的人员组织架构、复杂的业务系统时,也能够高效、灵活地实现权限的管理。 如下图的商务运营系统应用场景所示,该系统是面向内部多个团队开放的,每个团队都具有不同的职能,甚至团队内部也划分了不同的岗位。 针对该应用场景,系统权限的分配与管理主要包括以下的步骤: 1. 明确系统角色:如上图3.1所示,商务运营系统包括商家、商铺、订单等在内的多个平台。针对每个平台,需要确定好平台内需要哪些角色,不同角色在平台内承担着不同的任务。例如商户入驻系统包括了帮助商户入驻的角色、帮助商户管理成员的角色等。 2. 明确角色权限:针对角色承担的具体任务,其对应的系统可操作权限也是不同的,这就需要每一个角色分配具体的操作权限。例如帮助商户入驻的角色,可以有录入、查询、修改商家信息等接口与按钮的权限。 3. 明确团队架构:如上图3.2所示,审核管理项目需要有商务、运营、客服等多个团队,不同团队下还有相应的岗位来承担不同的任务。例如商务团队包括商务小编、商务管理员、商务负责人等岗位。 4. 为团队成员分配系统角色:为了将系统内的角色权限与团队内的组织架构进行结合,如上图3.3所示,管理人员可以通过角色配置的方式,来为岗位的人员赋予对应平台的权限。例如商务小编只有商品管理的角色,而商务可以同时有商品管理角色、商家入驻角色等,这样就实现了基于角色进行权限管理的实际应用。 03 权限系统思考 有了功能权限,我们进而应该思考另外一块领域,就是数据权限。 数据权限,就是有或者没有对某些数据的访问权限,具体表现形式就是当某用户有操作权限的时候,但不代表其对所有的数据都有查看或者管理权限。数据权限有两种表现形式:一种是行权限,另外一种是列权限。 所谓行权限,就是限制用户对某些行的访问权限,比如:只能对本人、本部门、本组织的数据进行访问;也可以是根据数据的范围进行限制,比如:合同额大小来限制用户对数据的访问。所谓列权限,就是限制用户对某些列的访问权限,比如:某些内容的摘要可以被查阅,但是详细内容就只有VIP用户才能查看。 通过数据权限,可以从物理层级限制用户对数据的行或列进行获取,这种方式比把所有数据拿到之后再根据用户权限来限制某些行或列有诸多好处。以列表数据权限为例,主要通过数据权限控制行数据,让不同的人有不同的查看数据规则;要实现数据权限,最重要的是需要抽象出数据规则。 但是光有数据规则是不够的,我们还需要把数据规则跟资源和用户进行绑定。这样资源就可以关联上了数据规则。 在设计上我们需要一个单独的数据规则管理功能,方便我们录入数据规则,然后在资源管理页面上就可以选择内置的数据规则进行资源与规则的绑定。 那么如何让不同的用户拥有不同的数据规则呢? 在RBAC模型中,用户是通过授予不同的角色来进行资源的管理,同理我们可以让角色在授予权限的时候关联上数据规则,这样最终在系统上就体现为不同的用户拥有不同的数据规则。 基于此,我们可以基本实现RBAC与数据规则的绑定;同时数据权限是一个实现相对比较复杂的功能,除了在RBAC模型基础上进行扩展,是否还有其他更合理的思路,留给大家进行思考。 ——END—— 参考资料: [1]https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf 推荐阅读: 分布式系统关键路径延迟分析实践 百度工程师教你玩转设计模式(装饰器模式) 百度工程师带你体验引擎中的nodejs 揭秘百度智能测试在测试定位领域实践 百度工程师带你探秘C++内存管理(ptmalloc篇) 为什么 OpenCV 计算的视频 FPS 是错的

优秀的个人博客,低调大师

HYC 0.02 版本发布,基于 springcloud + antd 的低代码研发工具

更新内容: [新增] 产品管理,添加涉及接口、涉及模型、涉及仓库、涉及数据库、涉及字典功能。 [新增] 新增产品初始化脚本功能,运行完成系统涉及基础脚本运行。 [新增] 产品升级,添加在线升级脚本管理功能,包含升级文件,文件编译、一键发布等功能 [新增] 产品编译功能,监控每次升级任务编译记录。 [新增] 产品运行功能,查看系统运行时系统各组件记录。 [新增] 产品历史功能,每次升级备份脚本记录。 [新增] 页面设计-新增默认编译功能。 [新增] 接口设计-新增默认编译功能。 https://gitee.com/beijixiongwanjia/haiyuan-cloud-web https://gitee.com/beijixiongwanjia/haiyuan-cloud-server 如果觉得还不错,STAR 一下吧

优秀的个人博客,低调大师

jeecmsX1.3 发布,低代码自定义生成表格

用户不需要懂设计与编程,完全通过可视化拖拽的方式所见即所得的创建任何自己想要的表单,这是jeecmsX1.3 所追求的。 1、无需设计和编程,可视化拖拽式创建:可以根据不同的节日、场景及业务需要调整表单背景、页眉、字体大小、颜色、组件大小间距等属性,并且能实时预览所配置的效果,整个过程不需要设计师和开发人员参与,轻松创建想要的表单。 2、一次创建可同时应用到PC、手机和平板端:表单只需编辑一次,即可同时在PC、手机和平板端生效并且获得很好的现象效果。 3、反馈结果实时呈现,能够自由导出数据:在管理系统中可通过图表或表格的方式实时查看表单的反馈结果,支持反馈结果的管理和导出,支持对表单填写人员的来源及趋势跟踪统计。 反馈结果统计 来源以及趋势分析 后端技术 SpringBoot2 快速开发框架 SpringMVC 5.0 Spring5.0 SpringSecurity 安全组件 JPA(Hibernate实现) Spring-Data-JPA 持久层组件 QueryDSL 持久层扩展 Ehcache、Redis 缓存组件 Lucene7.4、Elasticsearch6.8 索引组件 Flowable6.4.2 工作流引擎 Hanlp1.7(中文分词组件) Quartz 2.3.0 定时任务 Druid1.1.6连接池 geoip2 2.12.0 IP库 Slf4j 日志 Kaptcha 2.3.2 验证码 FreeMarker 模板渲染 JWT 0.9 TOKEN组件 Fastjson 1.2.58 JSON组件 Easypoi 3.2.0 导出组件 Zxing 3.2.0 二维码组件 sharding-sphere 3.0 数据库中间件组件 spring-session-data-redis session redis支持 前端技术 脚手架 vue-cli 3 前端框架 vue 2.6.10 路由 vue-router 3.0.3 数据存储 vuex 3.0.1 国际化 vue-i18n 8.11.2 UI组件库 element-ui 2.11.1 HTTP请求 axios 0.18.0 源码下载地址:http://www.jeecms.com/download.htm 前台演示地址:http://demo.jeecms.com 后台体验地址:http://demo.jeecms.com/jeecms/index.html

优秀的个人博客,低调大师

低代码搭建平台码良更新,正式支持 pc 模式

本次更新 进过3个月的迭代,正式支持 pc 模式 增加了方便做 pc 页面的容器组件 更加方便地对元素进行居中 码良是一个在线生成 H5 页面并提供页面管理和页面编辑的平台,用于快速制作 H5 页面。用户无需掌握复杂的编程技术,通过简单拖拽、少量配置即可制作精美的页面,可用于营销场景下的页面制作。同时,也为开发者提供了完备的编程接入能力,通过脚本和组件的形式获得强大的组件行为和交互控制能力。码良是一个完全开源免费的项目。 官网地址:https://godspen.ymm56.com/

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册