wangbing1125的博客

2、业务微服务通过表ID访问Redis获取表信息，检查本地是否已经有表样文件。3、业务微服务组装业务数据，然后调用qlm-utils-report包中的对应函数生成对应报表。5、报表有html、pdf、word、excel等多种格式，具体需要什么格式由业务接口自行确定。1、前端通过业务接口访问业务对应的微服务，访问参数中需包含表ID参数。4、报表如果需永久保存，例如开证明，则存入minio，把地址返回前端。6、前端接收报表文件，进行预览、打印等进一步操作。如无需保存，则直接返回流数据。

企业内部行政机构体系往往和成本机构不一致。行政机构体系来源于人力资源系统，成本机构体系来源于财务系统。人力资源系统、财务系统往往两套体系同时在用。在人力资源系统中，如果用到人力成本核算，就需要用到成本机构。财务系统中除了核算成本，往往也需要知道行政机构。在大集中模式下，人力资源系统推送行政机构给平台，财务系统推送成本机构给平台。两者再从平台获取成本机构或行政机构。一个人的工资分摊、保险分摊可能由不同成本机构承担。在单一产品里，人力资源系统、财务系统只能同时维护两套体系了。工资关系所在成本机构。

这也就是为什么平台强调要把dto层单独拿出来做单独工程，封装成独立jar的原因。这样dto可以共享到很多对方。if (SUCCESS == this.getStatus()) {// 通讯成功。最核心的技术是从SDKHttpResponse解析出真正需要的DTO结构。IO遵循平台内部API规范，接口入参出参和内部用是完全一样的。@Operation(summary = "获取人员信息")} else { // 通讯失败。SDK和服务端通讯引用的是。

基本方式是客户端对body进行HmacSHA256 加密处理，然后将结果存入Content-MD5头中，服务器端收到请求后，做同样处理，然后验证是否一致。但是现实情况是，组织内部已经建立了很多系统，是不能一次性替代的，只能先搭起平台，然后逐步开始替换。其中的核心问题是鉴权。服务器端校验原理，从请求头里获取应用ID，查询后台登记信息，找到对应的AppSecret，对信息进行同样的处理，最后验证签名是否一样。签名计算是鉴权的核心，它可以确保是由AppID对应的客户端发起的，且发起内容在传输过程中没有被篡改。

有了代码管理机制（SVN、Git），现在不用的代码，就不要保留了，坚决从当前工程中删除。否则会淹没了有用信息。企业内部信息化系统经常需要改来改去，很多系统甚至运行了很多年，经手的人换了一波又一波。按平台规定的方案解决类似问题，例如excel的文件导出，就必须按平台提供的模式来处理。一件事件往往有很多中方式来解决，为了维护方便、学习成本低，就必须按规定的模式写。版本冲突是个很头疼的事，往往会出很多莫名其妙的问题，问题是你很难判断谁和谁冲突。一个超大型平台，要对接和兼容很多控件、插件，兼容性的要求大于先进性。

平台不推荐上述之外的语言、组件等。平台卖给甲方后，甲方可能会放开这个限制，这个我们无法控制。学习和维护新的技术需要人力、时间，我们认为是不必要的浪费。开发指南顺序前期写的比较乱。在社区（正在做）会重新整理。AI/大数据/爬虫等：Python。PC前端：Vue+ElmentUI。移动前端：UniApp。四、Python后台。

后台服务一般是链接单库，本业务库的东西通过JPA获取，其他库通过Feign调用其他服务获取。如果涉及到两个库关联查询，采用两步法：先从一个库得到业务对象id列表，然后用列表里的数据去访问另一个库中对象。角色数据、用户数据、待办数据、消息数据、多语言资源、功能菜单数据、模块描述数据等只存在核心库里，所有业务模块共享。例如成本中心数据：由人力资源系统或财务系统产生（两个系统共存时，跟客户协商，由那个部门来维护）如果不够买人力资源系统，则在平台应用里管理，当然信息没有人力资源管理本身提供的多。

人力资源管理系统：Human Resource Management System，HRMS。=============平台将集成如上系统，并持续更新中============仓储管理系统：Warehouse Management System，WMS。财务管理系统：Financial Management System，FMS。知识管理系统：Knowledge Management System，KMS。内容管理系统：Content Management System，CMS。

但是如果独立封装人力资源系统时，就会出现一个问题，平台提供了机构、岗位、人员数据。对应客户关系管理，平台提供的简单人事管理就够了，对应人力资源系统则远远不够。人力资源系统对应的是自己的业务库，两者还是分离的。平台层和人力资源系统各自维护了一套数据，当有人力资源系统时，平台数据来源于人力资源系统（通过esb总线实现数据同步，关闭平台的维护功能），当没有人力资源系统时，平台自己维护数据。在很多客户当前环境中，往往是这样一种架构，上线主数据系统，人力系统做为数据源提供数据，其他系统和主数据系统交互获取数据。

企业里有各种系统，系统和系统直接需要有联动关系，尤其人力资源系统，例如人员入职、调动、离职时需要很多系统联动。企业服务总线是个不错的思路，但是协调统一各个异构系统，难度太大，总之就是思路远大、技术先进、落地困难，自然慢慢偃旗息鼓了。平台的思想就是要大一统，统一了各个模块的技术架构，统一了权限机制，统一了界面，统一交互模式，但是还是没有解决联动机制。企业服务总线概念有了重新考虑和落地的机会，而且由于技术的发展，企业服务总线有了新的技术底座。企业服务总线，看起来高大上的名词，几年前很火爆。

赛事平台可以告一段落了，主要精力投向招聘平台。从更大的方面，很多项目都有共同的地方，平台就是要把这些公共问题解决掉，然后在上面构造不一样的业务场景，通过这个方法来降低开发成本，提高开发效率。和赛事平台不同，招聘平台有明显的流程操作特征。个人提交了简历，单位要有提醒。也就是一个新的项目，仔细分析下，有的功能来源于平台的公共部分，有些部分直接从平台上其他应用来抽取。提醒部分支持站内消息、邮件、短信，这些都是平台的底层功能，直接调用即可。对管理端而已，企业就是他的客户，这部分核心功能可以来自客户关系管理。

2、根据几天下来持续跟踪，这样业务场景，CPU资源、内存资源不是问题，真正的瓶颈在带宽。由于租用的是云服务器，带宽资源也可以临时增加，增加的最小单位是周，正好覆盖比赛周期。所以平常维持10M带宽，一旦比赛可以临时加到30M（只需一周），即获得很好的效果花钱也不动。本来报名设计了暂存和提交两个按钮，可以暂存输入结果，最后再提交。还有类似的情况，例如集体节目报名流程明明写的很清楚，总是报成多个个人节目。尤其微信支付是异步操作（提交申请后，等微信来调你的回调接口来返回信息）会造成信息不同步，甚至有丢失情况。

这类平台粗分一下都是管理端、客户端、个人端，不同业务领域这三端的名字可能不同，从技术角度可以归结成上述3个。所以从架构方面，这类运营平台是一样的，只是功能不同。C这端，过去是单做App，目前是做小程序。小程序有很多种，目前看是微信小程序、钉钉小程序、飞书小程序。平台目前最适合的应用方向就是帮助打造运营平台。在赛事平台的同时，又新接了招聘平台的项目。这个平台的业务方向是人力资源服务公司的，他利用平台给他的客户提供招聘方面的服务。其实对于企业内部的管理平台也可以看做B+C，其中的C不过是内部的员工而已。

开发人员、设计人员很多情况下是从系统出发的，想让业务人员按平台的思路去执行。业务人员则考虑的是软件去适应业务。两者的观点都是对了，过去手工的业务模式上了系统需要优化。业务多年形成的模式尤其合理性，不能强行修改。这个矛盾只能一事一议，开发人员、业务人员一起讨论，很可能会走中间路线，就是业务改些，系统改些，达到一个合理平衡。这才是做系统真正最难的地方。1、日常的合作机构并不区分赛区，等比赛的时候临时建立赛区，将选择的合作机构分到不同赛区。2、不管什么比赛都按既定赛区去执行。2、不同的比赛可以建立不同赛区。

门户系统：几乎没有修改，原样采用了平台的门户系统（当然必要的配置修改是必须的，例如样式、颜色搭配，系统标题等等。这些配置修改都不是代码级别的，只是更改了配置）。能这么短时间上线，除了研发人员的加班加点，主要得益于平台本身的积累。开发效率的提高，除了人员自觉、技术能力强之外，更多的还是要依靠体系。再有就是开发团队对于平台提供开发技术的熟悉，例如excel导出机制等等。微信小程序：从平台的小程序框架开始，免去了注册、支付等开发工作量。内部机构管理、人员管理、权限管理：利用平台基础信息模块完成。

战略没有错，战术错了。未来的发展方向，不代表当前的现状。目前企业存在各种各样的系统，需要整合不假，但是现有系统的替代也不是一时半会的事。这个阶段的任务是突出单品，以单品占领市场，然后以点扩线，以线扩面。基于平台做单品，让单品去打天下，最后多个成功的单品联在一起为平台站台才是正确的方向。目前企业采购的还是一个个单品，整体平台的市场还没有前景。我们平台的口号也是All in One，在一个平台上实现一个企业内部的所有应用，统一的操作模式，统一的权限体系，统一界面，我们也坚信这是未来企业信息化的方向。

4、最要命的是新建1个系统，基本还是从0做起，现在的系统不能提高什么支持。现在都在嚷嚷数字化转型，老实讲，我搞不懂专家讲的那些东西，甚至弄不清信息化、数字化到底有啥区别。整个过程，在下都经历了。foxbase，标准C，VB，Delphi，VC，C#到VUE+JAVA。1、用户是单点登录了，但是授权还是各自系统再做，每个系统都有角色管理、授权管理。2、从主数据取来的数据其实是导到自己库里，用的还是自己那份。有一点大家到是共识，就是现在这种架构不能满足需求了，得改。3、各系统界面五花八门，交互方式争奇斗艳。

一种解决思路是，后台只返回数据本身，复杂的数据结构转换由前端完成。但是平台不选择这个思路，理由是前端做这种转换比较麻烦。平台的理念是开放和不重复造轮子。凡是各领域有优秀的开源组件，平台就集成，平台开发者集中有限的精力、财力在自己擅长的东西上。这里吐槽下datav的设计，各个类型的图数据结构不同。相同的数据，前端切换图样式，不得不再申请下后台接口。大屏部分，平台集成了开源免费的jiaminghi的datav组件。集成的核心手段是封装。后台按结构定义返回对应的dto，前台直接展示，无需转换。

相应前端有两个接口文件:qlm_dictItem.js用于访问核心库 brand_dictItem.j用于访问品牌库。整个平台共享一个redis，不同品牌的相同代码类要缓存在不同的键上。系统处理方式如下：代码类具有部署属性和moduleid，如果部署属性为分布式，则缓存的键上要加moduleid标识。平台级别的代码是存储在核心库中，品牌级别的代码是存储在品牌库中（注意代码类是一样的）。公共服务联核心库，品牌服务联品牌库。底层代码的功能是一样的，只是服务对应的配置不同，访问路径不同。

平台的代码是开放给甲方的；是面向大型和超大型企业的企业级PaaS平台,基于企业级云原生架构和中台思想，结合人工智能、区块链、云计算、大数据、物联网等创新科技及金蝶多年的企业级技术服务沉淀为企业提供多场景、多层次的数字化支撑，帮助企业快速构建强大的数字化平台，是EBC思想最佳的落地实践平台。：是用友采用新一代信息技术，按照云原生、元数据驱动、中台化和数用分离的架构设计， 涵盖平台服务、应用服务、业务服务与数据服务等形态，集工具、能力和资源服务为一体，服务企业与产业商业创新的平台型、生态化的云服务群。

结构早期还有模板类T data，用于传入业务数据，很多系统也是这样的设计。选型曾经花了很多时间，做了很多比较，我认为这是目前最优组合。不选用这套架构的同学们可以转学了，大家不是一条道上的。任何一个平台甚至任何一个前后端分离的系统都需要定义这样一个结构。以上摘自qlm-parent的pom文件。nacos为1.4.2（友情提醒，早期版本的nacos有漏洞CVE-2021-29441）以上结构完全可以做到全行业统一的，这就是千里马联盟的使命之一。​版本选择也是个头痛问题，有关版本的问题可见版本说明。

平台采用分层授权策略。权限体系的核心还是角色模式。通过系统先定义角色，然后给用户绑定角色。一个用户可以拥有多个角色，是多个角色拥有权限的并集。角色除了拥有还有拒绝，拒绝拥有五常才有的一票否决权。平台新建品牌时，新建用户，并赋予品牌商管理员角色。他在品牌商管理平台上建立角色，赋予权限。他的授权范围不能超过他自身。品牌商、平台管理员都可以增加培训机构，并新建一个培训机构管理员，他在合作商管理平台上建立角色，管理自己的用户。服务商（酒店、会展中心、旅行社等），一期暂时不纳入平台管理范围。

赛事中的数据和核心库数据可以不同，例如选手未来可以改名、年龄、服装尺寸都会变，但是赛事中归档的数据就是当时的数据。7、服务机构类似培训机构，有三个来源：品牌商加入、平台端加入、自行注册+平台审核。6、培训机构建立后会分配一个管理员，在培训机构端自行新增自己的下属机构、人员、用户。3、品牌商管理员登录品牌商管理平台，建立品牌商内部机构、人员信息、用户信息并授权。4、品牌商赛事业务人员新建活动，在活动域内建立赛事机构、赛事人员、赛事评委等等。1、核心库机构树上构建如下根节点：品牌商、培训机构、服务机构。

这里特别强调一个原则，平台管理端只是做平台级别的管理工作，是不能进行品牌内部的管理。这个管理要在品牌管理端进行。不要以为平台管理端能完成所有工作。例如性别，整个平台内都是一样的。在平台的系统管理中维护。品牌所有活动都统一的。在品牌端的系统管理中维护。每次活动对应的字典，存储在品牌库中，在活动管理中维护。整个平台，数据字典就分成三个层次了。

新增报名时，家长或老师首先看自己名下有无该选手信息（对照关系也是存储在核心库中），有则从核心库复制一份信息到品牌库，如果无则输入选手信息。输入时，先输入选手身份证号，如果核心库有该选手信息则复制到品牌库，无责输入全部信息。注意选手信息在品牌库中的存储是和活动相关的，即一个活动一份选手信息。因为选手的很多信息是在不同的赛事活动中是变动的，姓名可变、年龄在变、服装尺寸在变。也就是赛事组织机构、培训机构都是独立的实体，因为某次赛事进行组合，组合只记录上下级关系。培训机构可能是集团性质，可以建立自己的组织体系。

上文介绍了品牌隔离的基本原理，就是通过不同的前端和微服务来实现。但是确实很多功能是类似的，所以从编程角度还是有些管理手段的。前端部分：前端部分没有什么特别手段，就是两个独立的项目工程，分别维护。相同的部分复制粘贴完成。不同的部分大胆改就是。品牌独特的东西可以在service工程中独立实现。或继承、或干脆重写都无所谓。公共部分封装在jar里，品牌服务通过maven获取最新组件。

这个方案可以部分解决性能问题，因为报名表的分表，单表的数据量会下来。在过去的架构里这个方案可以通过动态拼SQL解决，但现在的技术架构大部分都是ORM了，这种方案不支持。上图是逻辑结构，实际环境中，前端不是直联后台服务，统一对的是网关，通过前缀来路由到不同微服务。这是最传统的解决方案。注意：品牌相关部分是隔离的，但是选手、家长、老师、裁判、志愿者等公共信息还是集中存储在核心库中。平台建设的首期就有两个品牌入驻，品牌J和品牌K，第三个品牌正在协商中。作为一个统一的·共享平台，首先要解决的是品牌直接的隔离。

平台的一个很重要的市场方向是为企业搭建各类运营平台。运营平台是这类企业的核心系统，例如对银行而言就是柜台系统，对于电商而言就是电子商城。最近签约开始基于平台，为客户搭建一个赛事运营平台，saas模式，客户用这个平台去服务他的客户，平台的使用者包括业务管理人员、系统管理人员、客服、赛事主办机构、培训机构、选手、家长、评委、志愿者、酒店旅行社等接待人员。系统要管理一个选手的参赛全流程：报名，到达接待、服装、化妆、叫号、评分、成绩发布。这样一个超大型系统，对平台的稳定性、可扩展性、权限控制机制要求很高。

微服务之下是微服务的管理。平台选取的是SpringCloud Gateway和Nacos。平台用的很多技术都有详尽介绍，我们不做对应的扫盲培训，请各位自行学习。关于Gateway请看。

很多所谓低代码平台的致命缺陷就是封闭，在平台上学习和实践的东西，离开平台将毫无价值，导致开发人员学习意愿非常低。作为一个资深程序员，我对拖拽生成界面也不认可，我不认为拖拽一个输入控件到界面上，比输入一个省了多少事。一个界面大量的工作不是摆个控件，而是数据的提取、数据的校验、数据存入后台这些逻辑工作，是出现问题调试bug这些工作。监控服务和其他服务不同，不是一个单一的微服务，准确来说是一个体系。​ 千里马平台的核心理念是通过组件的管理的来降低开发工作量和提高稳定性。

平台最早选型工作流引擎几乎没有任何犹豫的选择了JBPM6，道理很简单，技术体系一致：因为平台的持久层选择的是JPA+Hibernate和JBPM6一致。一个平台内的技术体系要保持一致，可以减少学习成本和管理成本。整个平台前台用VUE，后台用JAVA，涉及数据分析、人工智能的用Python，其他禁用。理论上微服务只要符合接口规范，使用什么语言都可以，但是不要忘记一个公司内部使用多套语言维护成本太大。

市面上报表工具不适合平台的主要原因在于数据大多数是编写SQL语句，这种模式的问题在于很难和权限相结合。例如平台希望定义一套报表，同样的表样，A单位可以使用 B单位也可以使用，出来的数据是各自单位的；前面也说过，平台上一部分业务是自定义表结构，例如人力资源系统，该系统里数据元是系统管理的，例如性别字段是字典类型。定义报表时，是无需了解物理表字段的逻辑关系的。平台的报表工具是完全自研的，当然也从BIRT等学习了很多东西。我们不要求这个报表工具能够独立使用，它是平台的一部分，需要和平台紧密整合。

平台里内建了一个数据产生平台。之所以需要这部分主要是为了产生测试和开发用的数据。模拟数据主要使用faker，具体介绍可见。simpy, 具体介绍可见。

内容服务地位比较特殊，它即是平台的组成部分，也是内容管理应用的一部分。只所以这样是具有这样的设计，平台把所有前台模块都看做一个网站，网站都有自己的熟悉，例如是否有独立登录界面、主界面栏目（在嵌入平台模式下，主界面需要不显示自己的头，在独立应用模式下由需要显示），类似这样的定义在内容管理后台设置。平台的整体设计理念是各个应用可以在大集成模式中共存，以整体解决方案推出。也可以封装成单独应用，按单独系统销售，例如人力资源系统、财务系统。新闻、公告、优化链接这些元素的管理也纳入到了内容管理的范畴。

用户的权限模型计算结果是用户登录时计算的，注销时销毁。当用户登录后，后台又同时修改权限定义时，用户的权限不能及时线上更新。所以平台花了很大代价仅仅换来用户无需二次登录到底值不值的是个可探讨的问题。在技术邻域有很多类似的不可能三角，对于这些问题的取舍之道也是平台的价值所在。不管哪个服务认证，其认证结果（表现为jwt）缓存在同一个redis中，用户的权限模型计算结果（角色叠加、规则应用）缓存其中。这是平台的核心服务之一。在一个大型应用平台里，这部分调用非常频繁，其稳定性、反应速度都对平台的影响很大。

字典：整个平台的字典在这里维护。字典类指字典的类别，例如性别字典。字典项目指具体的项目，例如男、女。字典项目有字典ID，就是唯一关键字。数据库里实际存储的是字典ID。字典代码是对外的编码（例如通过excel导入导出时，字典用的是代码，而不是ID。也就是机构ID是系统内部用的，机构编码是系统界面上可以显示出来的编码）。标签：类似字典，只是数据库中直接存储标签值。关于字典和标签的区分可以见之前的文章。资源服务是平台一个核心服务，另一个是用户服务，用户服务下篇介绍。功能：管理整个平台的可用功能配置。

实际运行环境中是一个服务部署包+多个本地配置文件的方式，使用多个配置文件的原因主要在端口不同，从而可以同时启动多个微服务。更进一步，可以使用java版的嵌入数据库，把数据库也打包到这个jar里，形成平台最小的版本。这就是平台的可伸缩性。一个服务从开发角度，分为控制层（controller）、服务层（service）、数据访问层（dao）、实体层（entity），具体都是jar包，通过搭建maven私服来管理。前端模块不是直连服务的，前端模块统一对springgate网关，网关也是注册在nacos中的服务。

目前机房设备管理、监控、云管理平台是个行当、应用平台管理是个行当、组件管理和自动化部署是个行当，千里马平台则致力于构建一个统一的开发运维一体化平台，目前还没有这个实力，先从应用平台出发，然后在切入其他邻域。运维监控模块关注各个服务器、服务器上的应用、数据库状态、数据库链接池状态、Minio状态等，有些是自研的例如服务器监控；整个千里马平台目前还只是应用层面的，未来会向下延伸一层，构造硬件资源管理层。也就是把服务器资源、文件存储资源统一管理系统，构成云管理层，把各种外部设备接入管理进来，实现万物互联。

为"local"时，说明基础数据和本微服务对应的业务库是同一个（单独封装的应用一般用这个模式，例如一个独立的客户关系管理系统），这时直接通过JPA获取数据。为"server"时（分布式架构，一个平台上多个应用的模式），这时实际是通过feign调用获取数据。参数总体上分两种私有的（本微服务自己的）和共享的（所有微服务）。私有记录在配置文件中，共享的记录在数据库中。本组件管理的是私有的，把配置转为常量类的静态属性。以一个属性为例（《千里马平台设计说明-获取基础数据》也描述过这个案例）。

配置组件集成了平台所需的各类公用配置，包括druid、swagger、redis等等的配置。一些专用组件的配置不在这个组件里，例如minio的配置。minio的配置是封装在单独的组件内的。