平台介绍
千里马开发运维一体化平台的发展历程,功能简介,特点等
大道不孤,众行致远
微信号:qlmtuiguang
展开
-
平台介绍-搭建赛事运营平台(9)
门户系统:几乎没有修改,原样采用了平台的门户系统(当然必要的配置修改是必须的,例如样式、颜色搭配,系统标题等等。这些配置修改都不是代码级别的,只是更改了配置)。能这么短时间上线,除了研发人员的加班加点,主要得益于平台本身的积累。开发效率的提高,除了人员自觉、技术能力强之外,更多的还是要依靠体系。再有就是开发团队对于平台提供开发技术的熟悉,例如excel导出机制等等。微信小程序:从平台的小程序框架开始,免去了注册、支付等开发工作量。内部机构管理、人员管理、权限管理:利用平台基础信息模块完成。原创 2024-05-04 22:17:44 · 128 阅读 · 0 评论 -
平台介绍-All in One
战略没有错,战术错了。未来的发展方向,不代表当前的现状。目前企业存在各种各样的系统,需要整合不假,但是现有系统的替代也不是一时半会的事。这个阶段的任务是突出单品,以单品占领市场,然后以点扩线,以线扩面。基于平台做单品,让单品去打天下,最后多个成功的单品联在一起为平台站台才是正确的方向。目前企业采购的还是一个个单品,整体平台的市场还没有前景。我们平台的口号也是All in One,在一个平台上实现一个企业内部的所有应用,统一的操作模式,统一的权限体系,统一界面,我们也坚信这是未来企业信息化的方向。原创 2024-05-05 08:01:22 · 194 阅读 · 0 评论 -
从技术开始-企业内部信息化架构演变
4、最要命的是新建1个系统,基本还是从0做起,现在的系统不能提高什么支持。现在都在嚷嚷数字化转型,老实讲,我搞不懂专家讲的那些东西,甚至弄不清信息化、数字化到底有啥区别。整个过程,在下都经历了。foxbase,标准C,VB,Delphi,VC,C#到VUE+JAVA。1、用户是单点登录了,但是授权还是各自系统再做,每个系统都有角色管理、授权管理。2、从主数据取来的数据其实是导到自己库里,用的还是自己那份。有一点大家到是共识,就是现在这种架构不能满足需求了,得改。3、各系统界面五花八门,交互方式争奇斗艳。原创 2024-01-27 23:06:10 · 317 阅读 · 0 评论 -
平台介绍-大屏组件
一种解决思路是,后台只返回数据本身,复杂的数据结构转换由前端完成。但是平台不选择这个思路,理由是前端做这种转换比较麻烦。平台的理念是开放和不重复造轮子。凡是各领域有优秀的开源组件,平台就集成,平台开发者集中有限的精力、财力在自己擅长的东西上。这里吐槽下datav的设计,各个类型的图数据结构不同。相同的数据,前端切换图样式,不得不再申请下后台接口。大屏部分,平台集成了开源免费的jiaminghi的datav组件。集成的核心手段是封装。后台按结构定义返回对应的dto,前台直接展示,无需转换。原创 2024-04-03 06:11:19 · 207 阅读 · 0 评论 -
平台介绍-搭建赛事运营平台(8)
相应前端有两个接口文件:qlm_dictItem.js用于访问核心库 brand_dictItem.j用于访问品牌库。整个平台共享一个redis,不同品牌的相同代码类要缓存在不同的键上。系统处理方式如下:代码类具有部署属性和moduleid,如果部署属性为分布式,则缓存的键上要加moduleid标识。平台级别的代码是存储在核心库中,品牌级别的代码是存储在品牌库中(注意代码类是一样的)。公共服务联核心库,品牌服务联品牌库。底层代码的功能是一样的,只是服务对应的配置不同,访问路径不同。原创 2024-03-30 19:32:58 · 343 阅读 · 0 评论 -
千里马平台介绍(3)
平台的代码是开放给甲方的;是面向大型和超大型企业的企业级PaaS平台,基于企业级云原生架构和中台思想,结合人工智能、区块链、云计算、大数据、物联网等创新科技及金蝶多年的企业级技术服务沉淀为企业提供多场景、多层次的数字化支撑,帮助企业快速构建强大的数字化平台,是EBC思想最佳的落地实践平台。:是用友采用新一代信息技术,按照云原生、元数据驱动、中台化和数用分离的架构设计, 涵盖平台服务、应用服务、业务服务与数据服务等形态,集工具、能力和资源服务为一体,服务企业与产业商业创新的平台型、生态化的云服务群。原创 2024-01-31 19:27:19 · 234 阅读 · 0 评论 -
千里马平台介绍(2)
结构早期还有模板类T data,用于传入业务数据,很多系统也是这样的设计。选型曾经花了很多时间,做了很多比较,我认为这是目前最优组合。不选用这套架构的同学们可以转学了,大家不是一条道上的。任何一个平台甚至任何一个前后端分离的系统都需要定义这样一个结构。以上摘自qlm-parent的pom文件。nacos为1.4.2(友情提醒,早期版本的nacos有漏洞CVE-2021-29441)以上结构完全可以做到全行业统一的,这就是千里马联盟的使命之一。版本选择也是个头痛问题,有关版本的问题可见版本说明。原创 2024-01-31 12:50:27 · 223 阅读 · 0 评论 -
平台介绍-搭建赛事运营平台(7)
平台采用分层授权策略。权限体系的核心还是角色模式。通过系统先定义角色,然后给用户绑定角色。一个用户可以拥有多个角色,是多个角色拥有权限的并集。角色除了拥有还有拒绝,拒绝拥有五常才有的一票否决权。平台新建品牌时,新建用户,并赋予品牌商管理员角色。他在品牌商管理平台上建立角色,赋予权限。他的授权范围不能超过他自身。品牌商、平台管理员都可以增加培训机构,并新建一个培训机构管理员,他在合作商管理平台上建立角色,管理自己的用户。服务商(酒店、会展中心、旅行社等),一期暂时不纳入平台管理范围。原创 2024-03-29 06:01:25 · 192 阅读 · 0 评论 -
平台介绍-搭建赛事运营平台(6)
赛事中的数据和核心库数据可以不同,例如选手未来可以改名、年龄、服装尺寸都会变,但是赛事中归档的数据就是当时的数据。7、服务机构类似培训机构,有三个来源:品牌商加入、平台端加入、自行注册+平台审核。6、培训机构建立后会分配一个管理员,在培训机构端自行新增自己的下属机构、人员、用户。3、品牌商管理员登录品牌商管理平台,建立品牌商内部机构、人员信息、用户信息并授权。4、品牌商赛事业务人员新建活动,在活动域内建立赛事机构、赛事人员、赛事评委等等。1、核心库机构树上构建如下根节点:品牌商、培训机构、服务机构。原创 2024-03-28 06:56:32 · 854 阅读 · 0 评论 -
平台介绍-搭建赛事运营平台(5)
这里特别强调一个原则,平台管理端只是做平台级别的管理工作,是不能进行品牌内部的管理。这个管理要在品牌管理端进行。不要以为平台管理端能完成所有工作。例如性别,整个平台内都是一样的。在平台的系统管理中维护。品牌所有活动都统一的。在品牌端的系统管理中维护。每次活动对应的字典,存储在品牌库中,在活动管理中维护。整个平台,数据字典就分成三个层次了。原创 2024-03-27 00:12:25 · 145 阅读 · 0 评论 -
平台介绍-搭建赛事运营平台(4)
新增报名时,家长或老师首先看自己名下有无该选手信息(对照关系也是存储在核心库中),有则从核心库复制一份信息到品牌库,如果无则输入选手信息。输入时,先输入选手身份证号,如果核心库有该选手信息则复制到品牌库,无责输入全部信息。注意选手信息在品牌库中的存储是和活动相关的,即一个活动一份选手信息。因为选手的很多信息是在不同的赛事活动中是变动的,姓名可变、年龄在变、服装尺寸在变。也就是赛事组织机构、培训机构都是独立的实体,因为某次赛事进行组合,组合只记录上下级关系。培训机构可能是集团性质,可以建立自己的组织体系。原创 2024-03-27 00:11:59 · 574 阅读 · 0 评论 -
平台介绍-搭建赛事运营平台(3)
上文介绍了品牌隔离的基本原理,就是通过不同的前端和微服务来实现。但是确实很多功能是类似的,所以从编程角度还是有些管理手段的。前端部分:前端部分没有什么特别手段,就是两个独立的项目工程,分别维护。相同的部分复制粘贴完成。不同的部分大胆改就是。品牌独特的东西可以在service工程中独立实现。或继承、或干脆重写都无所谓。公共部分封装在jar里,品牌服务通过maven获取最新组件。原创 2024-03-26 06:45:15 · 378 阅读 · 0 评论 -
平台介绍-搭建赛事运营平台(2)
这个方案可以部分解决性能问题,因为报名表的分表,单表的数据量会下来。在过去的架构里这个方案可以通过动态拼SQL解决,但现在的技术架构大部分都是ORM了,这种方案不支持。上图是逻辑结构,实际环境中,前端不是直联后台服务,统一对的是网关,通过前缀来路由到不同微服务。这是最传统的解决方案。注意:品牌相关部分是隔离的,但是选手、家长、老师、裁判、志愿者等公共信息还是集中存储在核心库中。平台建设的首期就有两个品牌入驻,品牌J和品牌K,第三个品牌正在协商中。作为一个统一的·共享平台,首先要解决的是品牌直接的隔离。原创 2024-03-26 06:25:17 · 332 阅读 · 0 评论 -
平台介绍-搭建赛事运营平台(1)
平台的一个很重要的市场方向是为企业搭建各类运营平台。运营平台是这类企业的核心系统,例如对银行而言就是柜台系统,对于电商而言就是电子商城。最近签约开始基于平台,为客户搭建一个赛事运营平台,saas模式,客户用这个平台去服务他的客户,平台的使用者包括业务管理人员、系统管理人员、客服、赛事主办机构、培训机构、选手、家长、评委、志愿者、酒店旅行社等接待人员。系统要管理一个选手的参赛全流程:报名,到达接待、服装、化妆、叫号、评分、成绩发布。这样一个超大型系统,对平台的稳定性、可扩展性、权限控制机制要求很高。原创 2024-03-25 06:45:40 · 290 阅读 · 0 评论 -
平台组成-网关和Nacos
微服务之下是微服务的管理。平台选取的是SpringCloud Gateway和Nacos。平台用的很多技术都有详尽介绍,我们不做对应的扫盲培训,请各位自行学习。关于Gateway请看。原创 2024-02-25 08:48:27 · 203 阅读 · 0 评论 -
平台组成-监控服务
很多所谓低代码平台的致命缺陷就是封闭,在平台上学习和实践的东西,离开平台将毫无价值,导致开发人员学习意愿非常低。作为一个资深程序员,我对拖拽生成界面也不认可,我不认为拖拽一个输入控件到界面上,比输入一个省了多少事。一个界面大量的工作不是摆个控件,而是数据的提取、数据的校验、数据存入后台这些逻辑工作,是出现问题调试bug这些工作。监控服务和其他服务不同,不是一个单一的微服务,准确来说是一个体系。 千里马平台的核心理念是通过组件的管理的来降低开发工作量和提高稳定性。原创 2024-02-25 08:36:38 · 158 阅读 · 0 评论 -
平台组成-工作流
平台最早选型工作流引擎几乎没有任何犹豫的选择了JBPM6,道理很简单,技术体系一致:因为平台的持久层选择的是JPA+Hibernate和JBPM6一致。一个平台内的技术体系要保持一致,可以减少学习成本和管理成本。整个平台前台用VUE,后台用JAVA,涉及数据分析、人工智能的用Python,其他禁用。理论上微服务只要符合接口规范,使用什么语言都可以,但是不要忘记一个公司内部使用多套语言维护成本太大。原创 2024-02-28 00:03:47 · 370 阅读 · 0 评论 -
平台组成-报表工具
市面上报表工具不适合平台的主要原因在于数据大多数是编写SQL语句,这种模式的问题在于很难和权限相结合。例如平台希望定义一套报表,同样的表样,A单位可以使用 B单位也可以使用,出来的数据是各自单位的;前面也说过,平台上一部分业务是自定义表结构,例如人力资源系统,该系统里数据元是系统管理的,例如性别字段是字典类型。定义报表时,是无需了解物理表字段的逻辑关系的。平台的报表工具是完全自研的,当然也从BIRT等学习了很多东西。我们不要求这个报表工具能够独立使用,它是平台的一部分,需要和平台紧密整合。原创 2024-02-28 00:43:06 · 184 阅读 · 0 评论 -
平台组成-仿真数据平台
平台里内建了一个数据产生平台。之所以需要这部分主要是为了产生测试和开发用的数据。模拟数据主要使用faker,具体介绍可见。simpy, 具体介绍可见。原创 2024-03-01 00:28:36 · 558 阅读 · 0 评论 -
平台组成-内容服务
内容服务地位比较特殊,它即是平台的组成部分,也是内容管理应用的一部分。只所以这样是具有这样的设计,平台把所有前台模块都看做一个网站,网站都有自己的熟悉,例如是否有独立登录界面、主界面栏目(在嵌入平台模式下,主界面需要不显示自己的头,在独立应用模式下由需要显示),类似这样的定义在内容管理后台设置。平台的整体设计理念是各个应用可以在大集成模式中共存,以整体解决方案推出。也可以封装成单独应用,按单独系统销售,例如人力资源系统、财务系统。新闻、公告、优化链接这些元素的管理也纳入到了内容管理的范畴。原创 2024-02-24 08:58:54 · 184 阅读 · 0 评论 -
平台组成-用户服务
用户的权限模型计算结果是用户登录时计算的,注销时销毁。当用户登录后,后台又同时修改权限定义时,用户的权限不能及时线上更新。所以平台花了很大代价仅仅换来用户无需二次登录到底值不值的是个可探讨的问题。在技术邻域有很多类似的不可能三角,对于这些问题的取舍之道也是平台的价值所在。不管哪个服务认证,其认证结果(表现为jwt)缓存在同一个redis中,用户的权限模型计算结果(角色叠加、规则应用)缓存其中。这是平台的核心服务之一。在一个大型应用平台里,这部分调用非常频繁,其稳定性、反应速度都对平台的影响很大。原创 2024-02-22 10:40:21 · 458 阅读 · 0 评论 -
平台组成-资源服务
字典:整个平台的字典在这里维护。字典类指字典的类别,例如性别字典。字典项目指具体的项目,例如男、女。字典项目有字典ID,就是唯一关键字。数据库里实际存储的是字典ID。字典代码是对外的编码(例如通过excel导入导出时,字典用的是代码,而不是ID。也就是机构ID是系统内部用的,机构编码是系统界面上可以显示出来的编码)。标签:类似字典,只是数据库中直接存储标签值。关于字典和标签的区分可以见之前的文章。资源服务是平台一个核心服务,另一个是用户服务,用户服务下篇介绍。功能:管理整个平台的可用功能配置。原创 2024-02-21 17:40:23 · 207 阅读 · 0 评论 -
平台组成-门户服务
实际运行环境中是一个服务部署包+多个本地配置文件的方式,使用多个配置文件的原因主要在端口不同,从而可以同时启动多个微服务。更进一步,可以使用java版的嵌入数据库,把数据库也打包到这个jar里,形成平台最小的版本。这就是平台的可伸缩性。一个服务从开发角度,分为控制层(controller)、服务层(service)、数据访问层(dao)、实体层(entity),具体都是jar包,通过搭建maven私服来管理。前端模块不是直连服务的,前端模块统一对springgate网关,网关也是注册在nacos中的服务。原创 2024-02-21 17:24:39 · 351 阅读 · 0 评论 -
平台组成-运维监控模块
目前机房设备管理、监控、云管理平台是个行当、应用平台管理是个行当、组件管理和自动化部署是个行当,千里马平台则致力于构建一个统一的开发运维一体化平台,目前还没有这个实力,先从应用平台出发,然后在切入其他邻域。运维监控模块关注各个服务器、服务器上的应用、数据库状态、数据库链接池状态、Minio状态等,有些是自研的例如服务器监控;整个千里马平台目前还只是应用层面的,未来会向下延伸一层,构造硬件资源管理层。也就是把服务器资源、文件存储资源统一管理系统,构成云管理层,把各种外部设备接入管理进来,实现万物互联。原创 2024-02-20 16:44:35 · 387 阅读 · 0 评论 -
后台组件-常量定义
为"local"时,说明基础数据和本微服务对应的业务库是同一个(单独封装的应用一般用这个模式,例如一个独立的客户关系管理系统),这时直接通过JPA获取数据。为"server"时(分布式架构,一个平台上多个应用的模式),这时实际是通过feign调用获取数据。参数总体上分两种私有的(本微服务自己的)和共享的(所有微服务)。私有记录在配置文件中,共享的记录在数据库中。本组件管理的是私有的,把配置转为常量类的静态属性。以一个属性为例(《千里马平台设计说明-获取基础数据》也描述过这个案例)。原创 2024-03-02 18:17:26 · 210 阅读 · 0 评论 -
后台组件-配置
配置组件集成了平台所需的各类公用配置,包括druid、swagger、redis等等的配置。一些专用组件的配置不在这个组件里,例如minio的配置。minio的配置是封装在单独的组件内的。原创 2024-03-04 00:32:49 · 112 阅读 · 0 评论 -
后台组件-DTO
DTO组件是个组件族。前端和Controller层的交互是通过DTO传递数据,同样Controller层和Service层传递参数也是DTO。DTO族按业务分为序列组件,例如。实现上这部分也完全可以定义为行业标准,这样数据交换将会大统一。可惜只是个理想而已,搞统一太难了。又如qlm-dto-job 有关作业的传输结构。原创 2024-03-06 11:26:04 · 743 阅读 · 0 评论 -
后台组件-语言包
平台提供多语言支持,以上为语言包,提供后台多语言支持。原创 2024-03-06 22:55:42 · 356 阅读 · 0 评论 -
联系信息的存储
其实集中存储有集中的好处,例如可以统一进行加密处理;只能说万事都不可能尽善尽美,留一丝遗憾吧。另外也说明平台还有很多地方需要完善,人员准备也不充分。急于推广盈利可以理解,但是步子大了还是容易扯蛋,打好基础再说吧。基本信息是分布存储的,例如人力资源系统存储内部人员信息,供应商系统存储供应商人员信息。联系信息是这些对象的属性,不应分离。之前说过平台的用户信息是集中存储的。和用户相关的联系信息,包括手机号、电子信箱等等如何存储?是否和用户信息一样集中存储?经过几次反复,最终决定还是分布存储。原创 2024-02-17 11:16:14 · 200 阅读 · 0 评论 -
用户数据来源
平台要求每一个子系统都可以单独来运行(由不同公司开发、可以单独销售、目标在自己业务领域进入行业前三),又可以所有子系统组合在一起,完成一个大型组织的所有业务。1、人力资源板块:人力资源系统、党组管理、绩效管理、职称评审、培训、考试、招聘、知识管理、人才盘点、专家管理、证照管理。2、通过人员管理增加的(人员管理是组织的自有人员,来源于人力资源系统)。5、自行注册的(如招聘管理的应聘人员、网站的用户等等)。3、行政管理板块:OA、会议管理、任务管理、档案管理。6、通过专家管理增加的(专家账号、用于评审等)。原创 2024-02-17 11:15:29 · 209 阅读 · 0 评论 -
固定表结构与可自定义表结构
可自定义的表结构使用于灵活的数据对象,例如平台的人力资源管理中员工信息。各个企业不同不说,就是同一个企业也不断变更,要允许可以自己修改表结构。对象的编辑界面也不是固定的,需要根据表结构+权限动态的生成,编程难度较大。固定表结构适合于比较固定的信息对象,例如在平台的客户关系管理模块中,尽管各个行业有所差异,但是大同小异,可以固化表结构,使用实体来映射表。对象的编辑界面也是固定的,比较简单。元数据采用分布式存储,人力资源系统存机构、岗位、员工的元数据;整个平台的表结构分为两种:固定的和可自定义的。原创 2024-02-17 21:35:41 · 230 阅读 · 0 评论 -
moduleID的使用
整个平台上有很多相同的功能,但是需要不同的内容。例如各个模块自己的首页上有滚动新闻、有友好链接等等。为了公用这些功能,平台引入了moduleID的解决方案。同理各个模块后台都有相应的设置功能,用的是相同的功能,只是传入不同模块号实现数据的隔离。前端页面请求滚动新闻时,会传入该参数。这样会返回该模块所需的数据。原创 2024-02-09 09:44:10 · 354 阅读 · 0 评论 -
即大而全又小而美
一般认为大而全和小而美是对立的两种方向,但是在千里马平台中,两种要结合起来。从整体上讲,千里马平台要的是大而全,一个组织只需要一套系统,千里马平台+应用搞定所有需求。所有应用采用同种技术路线,界面风格一致,权限体系等统一管理。新增需求时,可以利用现有功能进行组合,极大地降低开发成本,提高上线效率。 但是针对某一具体应用,则要求是小而美。一个公司什么都做,什么都做不好,每一个领域都由一个专业公司来负责。每个应用可以脱离大平台,自己独立运行。必要时,又可以基于大平台整合在一起。原创 2024-02-09 09:42:54 · 228 阅读 · 0 评论 -
代码字段与标签
在平台里描述对象的属性可以使用代码和标签,其中代码又分为单选代码和多选代码。代码实现时界面上显示的是描述,数据实际存储的是代码。例如01001代表男(注意描述是支持多语言环境的,在中文环境下为男,英文环境下为male),多选代码指可以同时选择多个代码。代码是在系统管理中的字典管理中维护的。标签是另一种描述方式。标签直接使用描述,没有对应的代码。标签可以由用户自己扩充,而不是由管理员统一管理(当然为了便于维护,管理员可以关闭自定义标签功能)。原创 2024-02-17 21:36:41 · 107 阅读 · 0 评论 -
多数据源支持
平台的技术体系是JPA+Hibernate,单数据源时很简单,根本不需要了解太多底层,事实上很多程序都不清楚底层是如何运作的。各个微服务之间实际上不相互调用,需要取数据时,直接从对应表里拿数据,从而导致有大量的重复代码(公用的表对应的实体类、数据访问层、甚至服务层)。平台倡导分布数据库,最简单的分库逻辑是按业务领域,例如人力资源系统一个库,客户关系管理一个库(举个例子而已,在平台正式的系统中,人力资源系统又细分为核心库、绩效管理库、薪资管理库等)。例如涉及到数据同步、数据传输的应用,就需要多数据源。原创 2024-02-17 21:37:43 · 973 阅读 · 0 评论 -
平台组成-门户系统
早期设计时,曾经想过把门户样式剥离出来,通过定义文件来实现样式不同,但是实现起来比较复杂。而且平台的商业模式是提供源代码,这样客户可以选择不同样式模板对应的代码,然后根据自己的情况定制个性化门户系统。从功能上讲,可以区分为内部门户和外部门户。手机端以往是独立的App,现在的趋势是微信、钉钉或飞书的小应用。应用可以是千里马平台上的应用,也可以是其他平台基础上的应用(需要实现单点登录规范)。门户系统本身不具有业务功能,仅仅是展示平台,各种应用都以某种形式展现在门户里,通过单点登录技术,从门户中访问。原创 2024-02-18 07:26:00 · 213 阅读 · 0 评论 -
平台组成-系统管理
系统管理是整个平台共用的一个模块,是独立部署的。因为前后端分离,所谓的模块一般指独立部署的一个前台包。后台是平行的一大堆微服务。就是定义有那些功能,核心是这个功能对应的链接。一个功能可以分配给多个模块。功能节点可以区分为目录、界面、界面上按钮3个层次。就是定义整个平台有那些模块,例如系统管理、用户管理,一个模块拥有一个唯一的moduleID(前面讲过这个概念).就是定义门户里的一个窗口。窗口具有形状、尺寸、包含具体功能等属性。功能可以来源于不同模块。原创 2024-02-18 15:49:46 · 248 阅读 · 0 评论 -
平台组成-用户管理
他不可以不需要本人的账号密码,用他自己身份登录,登录后界面上出现身份切换选择项,可以切换为授权人身份。即能访问的机构范围,在不同的模块机构的定义不同,可以是行政机构、党团组织、成本单位等等。平台的权限体系,可以阅读之前的文章《千里马平台设计说明-用户权限体系》 1、不可以跨层授权,只能直接授权。用户管理是整个平台共享的模块,包括用户的开通、属性修改、角色管理、授权管理等功能。 2、排除权限优先赋予权限。原创 2024-02-19 17:28:00 · 1227 阅读 · 0 评论 -
平台组成-内容管理
例如友好链接,门户系统界面上友好链接可以和招聘系统界面上友好链接不同(点击门户系统内的招聘图标会进入招聘系统主界面,招聘系统主界面上可以有智联等链接,门户系统则不需要)。这些都是由统一的内容管理系统进行管理的。只是单独封装为应用时,屏蔽了很多东西,从使用者的角度看就是一个纯纯的网站管理系统。内容管理可以封装为独立应用,单独部署,即为内容管理系统,可用于网站建设。平台的内容管理安装网站群的思路进行设计,每一个模块都可以设想为一个网站,这样页面的元素由内容管理系统来进行管理。新闻、公告等纳入内容管理模块。原创 2024-02-19 17:42:01 · 200 阅读 · 0 评论 -
概念澄清说明
平台应用和平台上的应用是两个不同的概念,平台应用是平台自身的功能,例如用户管理应用,购买了平台就自然拥有,是打包销售的,不可分割,不可取舍。平台上的应用是平台之外的,购买时需要单独付费的,而且有可能第三方公司开发的,和平台厂商可以不一致。后台用微服务来实现,例如门户服务,就是一个独立运行的后台程序,有唯一的端口,在nacos里有对应的配置文件。平台作为开发运维一体化平台,还包括开发资源,主要包括各种前端组件(vue),后台组件(java python包),文档资源。这些构成了完整的平台交付物。原创 2024-02-20 16:33:09 · 102 阅读 · 0 评论