5.6 商业支撑之商品域

相关推荐

• Oinone 7天入门到精通

  4.2.2 框架之MessageHub

  一、MessageHub 请求出现异常时，提供”点对点“的通讯能力 二、何时使用 错误提示是用户体验中特别重要的组成部分，大部分的错误体现在整页级别，字段级别，按钮级别。友好的错误提示应该是怎么样的呢？我们假设他是这样的 与用户操作精密契合 当字段输入异常时，错误展示在错误框底部 按钮触发服务时异常，错误展示在按钮底部 区分不同的类型 错误 成功 警告 提示 调试 简洁易懂的错误信息 在oinone平台中，我们怎么做到友好的错误提示呢？接下来介绍我们的MessageHub，它为自定义错误提示提供无限的可能。 三、如何使用 订阅 import { useMessageHub, ILevel } from "@kunlun/dependencies" const messageHub = useMessageHub('当前视图的唯一标识'); /* 订阅错误信息 */ messageHub.subscribe((errorResult) => { console.log(errorResult) }) /* 订阅成功信息 */ messageHub.subscribe((errorResult) => { console.log(errorResult) }, ILevel.SUCCESS) 图4-2-2-1 订阅的示例代码 销毁 /** * 在适当的时机销毁它 * 如果页面逻辑运行时都不需要销毁，在页面destroyed是一定要销毁，重要！！！ */ messageHub.unsubscribe() 图4-2-2-2 销毁的示例代码 四、实战 让我们把3.5.7.5【自定义视图-表单】一文中的自定义表单进行改造，加入我们的messageHub，模拟在表单提交时，后端报错信息在字段下方给予提示。 Step1 （后端）重写PetType的创建函数 重写PetType的创建函数，在创建逻辑中通过MessageHub返回错误信息，返回错误信息的同时要设置paths信息方便前端处理 @Action.Advanced(name = FunctionConstants.create, managed = true) @Action(displayName = "确定", summary = "创建", bindingType = ViewTypeEnum.FORM) @Function(name = FunctionConstants.create) @Function.fun(FunctionConstants.create) public PetType create(PetType data){ List<Object> paths = new ArrayList<>(); paths.add("demo.PetType"); paths.add("kind"); PamirsSession.getMessageHub().msg(new Message().msg("kind error").setPath(paths).setLevel(InformationLevelEnum.ERROR).setErrorType(ErrorTypeEnum.BIZ_ERROR)); List<Object> paths2 = new ArrayList<>(); paths2.add("demo.PetType"); paths2.add("name"); PamirsSession.getMessageHub().msg(new Message().msg("name error").setPath(paths2).setLevel(InformationLevelEnum.ERROR).setErrorType(ErrorTypeEnum.BIZ_ERROR)); // data.create(); return data; } 图4-2-2-3 （后端）重写PetType的创建函数 Step 2 修改PetForm.vue <template> <div class="petFormWrapper"> <form :model="formState" @finish="onFinish"> <a-form-item label="品种种类" id="name" name="kind" :rules="[{ required: true, message: '请输入品种种类!', trigger: 'focus' }]"> <a-input v-model:value="formState.kind" @input="(e) => onNameChange(e, 'kind')" /> <span style="color: red">{{ getServiceError('kind') }}</span> </a-form-item> <a-form-item label="品种名" id="name" name="name" :rules="[{ required: true, message: '请输入品种名!', trigger: 'focus' }]"> <a-input v-model:value="formState.name" @input="(e) => onNameChange(e, 'name')" /> <span style="color: red">{{ getServiceError('name') }}</span> </a-form-item> </form> </div> </template>- <script lang="ts"> import { defineComponent, reactive…

  史, 昂

  2024年5月23日

  1.8K000
• Oinone 7天入门到精通

  2.2 互联网架构作为最佳实践为何失效

  如果把互联网架构比作社会主义，Oinone就是也要做有中国特色的社会主义，才能符合国情。 随着业务和生态的发展，企业对效率、性能、体验和智能化等方面的要求越来越高，但很多企业的系统面临着严重的系统架构落后和系统间割裂等问题，这些问题导致原有系统在业务发展下面临着效率和性能的双重挑战。与此同时，互联网平台的技术水平远远领先于传统企业系统，但是是否可以直接将互联网架构照搬到企业数字化转型中呢？显然，这是不合适的，因为互联网架构在企业数字化转型中面临着许多水土不服的问题。本章节将结合互联网中台架构的发展，分析这些问题的原因。 借鉴互联网中台理念 我们要先看互联网架构的发展，是如何一步步到今天提的中台架构概念的，每一步又解决了什么具体问题，我们以阿里架构变迁史为例来看下（如下图2-2所示）： 图2-2 阿里架构变迁史 在2009年，淘宝上线了五彩石项目，这标志着淘宝从单体应用向服务化应用的时代迈出了一步。那么，淘宝为什么要开发五彩石项目呢？因为当时淘宝面临两个非常严峻的问题，一个是性能问题，数据库连接不足，数据库成为了瓶颈；另一个是效率问题，当时淘宝有百余个研发人员，但核心系统只有一套测试、预发、线上环境，导致研发需求排队等待。在开始五彩石项目之前，淘宝还做了千岛湖项目，用来验证服务化架构的可行性，将用户中心独立出来。随后，淘宝开启了五彩石项目，目标是通过增加人力来提升效率，通过增加机器来提升性能。 随着淘宝的业务发展，他们又面临了一个问题：各个服务之间有很多重复的建设，效率低下。为了解决这个问题，淘宝开始从服务化转向平台化，并创立了“共享业务事业部”，将重复建设的公共业务分配给这个事业部，以避免成本浪费。这些公共业务包括商品平台、交易平台和结算平台等。平台化的目标是规避服务化没有规划导致的重复建设问题。 但是随着业务的快速发展，淘宝变成了一个拥有几十个事业部的巨型企业，而这带来了新的问题：效率问题。例如，如果需要在一个业务线上做出改动，需要与十几个平台进行沟通，这是非常低效的。同时，对于一个平台来说，需要面对来自不同事业部的需求，这需要平台研发人员具备理解和抽象所有业务线需求的能力，这让平台研发人员感觉回到了单体应用时代，所有的需求都要排队，即使增加人力也无法提高效率。这个问题主要表现在交易平台上。 为了解决这个问题，淘宝提出了中台的概念，中台是在一套规范下建立的，让具有专业技能的团队自主决策业务系统发展的平台。中台的目标是弱化平台的业务特性，提供通用能力。简而言之，就是将“共享业务”中的“业务”两个字去掉，只提供通用能力的平台 我们将每个阶段的核心目标总结为一句话： 从单体到服务：通过增加人员和机器来提高效率和性能； 从服务化到平台化：解决服务化阶段因缺乏规划而导致的重复建设问题； 平台化到中台化：在一套规范下，让各业务团队自行决定业务系统发展，适用于多个业务线或多个场景应用的独立发展。 类似地，在企业数字化转型过程中，也面临着类似的问题： 随着企业业务在线化，对系统性能和稳定性提出了更高的要求，但由于内部系统之间的割裂，导致很多重复建设。因此，我们需要进行服务化和平台化； 没有一个供应商能够解决企业所有的商业场景问题，所以需要多个供应商共同参与。我们可以将供应商类比为各业务线，在一套规范下让供应商或业务线自行决定业务系统的发展。 然而，阿里的中台架构方案并不能直接照搬到企业中。因为阿里的中台架构采用了平台共建模式，即让业务线基于平台设计的规范共同开发。这本质上还是平台主导模式，对企业来说历史包袱较大。在企业中，让不同背景的研发一起共建交易或商品平台是非常复杂的事情。平台化已经足够复杂，再加上共建会导致企业架构的负载过重，这对企业来说就不再是赋能，而是“内耗”。 互联网中台架构在企业实践中遇到的问题 在1.3《Oinone的生态思考》一文中，《与中台的渊源》部分提到，在阿里云为企业提供数字化项目时，客户经常会对以下三个问题提出质疑，这些问题非常突出： 1我们听说你们具备敏捷响应能力，但为什么改动需求如此缓慢？不仅所需时间更长，而且成本更高？ 2我们听说你们有能力中心，但为什么当我们引入新供应商或开发新场景时，前期建立的能力中心无法支持我们？ 3我们听说你们的性能很好，但为什么我们需要投入更多的物理资源来支持项目？ 在探讨互联网架构的适用性时，我想提出以下两个问题： 1企业应用程序的性能问题是否与互联网平台公司遇到的性能问题相同？ 2企业应用程序的开发效率问题是否与互联网平台公司遇到的效率问题相同？ 通过比较企业和互联网之间的差异，我们可以了解水土不服的核心原因。 企业 互联网 企业IT组织能力无法与数字化转型的速度匹配，缺乏足够的人才支持。为了提高开发效率，企业需要寻找工具和技术来降低开发难度，同时提高个人开发效率 互联网企业拥有众多优秀的人才，需要解决团队协作和知识共享的问题，即协同开发的效率。 企业无法制定并主导技术规范，这导致了能力复用的不足。为了提高效率和减少开发成本，企业需要建立统一的技术规范和标准，以便能力复用和组织协同。 互联网企业可以自定义技术规范，因此能力复用更易于保障。 企业往往当前业务量相对小，期望数字化建设能打动业务发展，对业务发展的预期比较高，所以企业的诉求是即满足当下成本效应又能兼顾未来对发展预期 互联网企业起步时的系统目标负载就高，通常会忽略资源起步门槛的问题，当然也可以通过自动扩容、云计算等方式来解决初期的负载问题。 表2-1从企业与互联网的对比，看水土不服的核心原因 我们可以看到企业和互联网架构在很多方面存在着不同的需求和问题。因此，在提供数字化服务时，Oinone需要注意与企业的组织能力进行匹配，并根据企业自身的特性来提供在线化的服务能力。这就像在社会主义制度下需要有中国特色一样，Oinone也需要有适合中国企业的特色。

  史, 昂

  2024年5月23日

  2.2K000
• Oinone 7天入门到精通

  1.4 Oinone对软件特性的思考

  我在个人的微信公众号上《浅谈企业IT架构的十年困局》一文中写了“企业或者软件公司在工程领域都关注哪些特征，而这些特征又应与具体研发人员的个体能力无关”的相关内容。收到很多业内人士的留言，也引起了很多同行的共鸣，所以今天在这里也打算针对这个话题，跟大家再做个深入的探讨。 一、首先为什么强调要跟研发个体能力无关 我们先来看一个故事： 轮扁是春秋时期齐国的木工，齐桓公召其入宫打造物件。有一天，齐桓公在堂上看书，轮扁在堂下用椎、凿等工具做车轮。 齐桓公看书看到得意处，不由得读出声来。轮扁听到读书声，想了想，放下手里的工具，走上堂来，在齐桓公面前几步远的地方停下，恭恭敬敬地说：“请恕臣斗胆问一下，君王读的是什么书？”齐桓公没想到这个老木匠会走上堂来，倒有点意外。不过看在他年纪大的份上，倒也不去斥责他，就回答说：“寡人读的是圣人写的书。”轮扁问：“圣人还在吗？”齐桓公说：“已经死了。”轮扁说：“这样看起来，君王所读的，不过是古人的糟粕而已！”齐桓公勃然大怒，说：“寡人读书，你一个做车轮的怎么敢议论？你说，这书上怎么会是古人的糟粕？说出道理便罢，说不出道理便难逃一死！” 轮扁不慌不忙地说：“臣是根据臣所从事的活计而明白这个道理的。砍削轮子，榫头做得宽了则松滑而不牢固，做得太紧就必然涩滞而安不进去，臣制作的榫头松紧适宜，是因为心里怎样想的手便怎样去做。然而尽管所需要的分寸度数心里都明白，要把它用言辞表达出来却实在不可能，全靠自己手与心的配合。所以，臣无法将其中的奥秘传授给儿子，臣的儿子也无法从臣这里学到其中的奥秘。因此，臣如今七十多岁了，还只好亲手去干制作轮子的活。这样看来，古人之道的精华都已随着古人死去而无法传世，那么君王所读的，不就是古人的糟粕了吗？” 这就是著名的成语故事——轮扁斫轮，出自《庄子·天道》。庄子通过轮扁的言论，深刻地揭示了高妙之技的难以言传。 而当我们转换视角，在企业数字化转型领域，无论是软件公司还是甲方IT团队，核心上是应用级开发需求，更多的精力应该放在业务场景理解、需求把控以及业务系统实现上。但往往在一个项目进入研发之前，会花很大力气在技术架构设计、技术栈选型、通用能力对接、扩展点设计这些跟业务场景无关的技术事项上，且需要高级别的架构师来主导。大部分情况下，架构师会选开源框架来实现，慢慢沉淀为企业的研发标准体系，所以底层架构的能力往往依赖架构师个人能力。不禁发现他们与轮扁有着异曲同工之处。架构师所积累的个人经验和技术能力，往往难以通过简单的手把手教学、技术评审会完全传递给团队中的其他成员。即使有所传授，其效率也可能仅达到50%，并且随着团队成员数量的增加，这种效率还可能持续递减。因此，我们需要更多地依赖于技术手段，将架构师的经验和能力固化下来，形成一套可复制、可推广的标准技术产品。这样，每个团队成员都能够通过学习和运用这些技术，达到至少70%的传递效率，从而确保团队整体技术水平的稳步提升。这也正是开篇所强调的，企业或软件公司在工程领域所关注的特征，应当与具体研发人员的个体能力相剥离，而更多地依赖于标准化、系统化的技术手段，来确保团队整体的高效运作。 二、软件公司在工程化领域都关注哪些特征 接下来，我将从技术角度深入剖析设计初衷和技术实现原理，以展现技术公司应当“被标准化的特征”究竟长什么样。 先做个名称解释，下文中涉及“标品”、“升级”、“扩展逻辑”，这是站在软件公司角度出发描述的，如果是企业内部可以把标品理解为特定业务应用平台，升级则是业务应用平台的正常规划迭代，扩展逻辑理解为脱离平台发展的临时性需求。 1. 可逆计算 可逆计算，在应用上的特征图 场景：调查发现企业研发至少有40%的精力在跟各条业务线的团队在评审项目需求，判断需求是否合理。而且业务线对需求完善时间要求紧，每天盯着研发进度，经常问“这个需求什么时候支持，我们等着用”。导致产研部门的研发抱怨产品节奏乱，无法按照自身节奏进行迭代，被项目推着走，没有时间思考，人手不足，加班多，工作压力大…… 价值：该特性很好的规避了研发因为时间紧迫，写的一些临时代码腐蚀核心业务系统。它需要做到不论从数据模型、业务逻辑、交互展示都能有扩展能力，并且这些扩展能力与个体研发无关才行。它同时所描述的也是一个具备差量计算能力的软件架构模式，它允许用户通过添加或移除扩展包来定制标准应用，同时保持应用的可逆性和独立性。这种架构模式的核心优势在于其灵活性和可维护性，使得应用的定制和恢复变得简单而高效。 技术原理：它所描述的是一个基于元数据驱动和差量计算的软件架构模式，它允许用户通过添加或移除扩展包来定制标准应用，同时保持应用的可逆性和独立性。这种架构模式的核心优势在于其灵活性和可维护性，通过元数据来驱动应用的构建和变更，使得应用的定制和恢复变得简单而高效 在这种架构中，元数据起到了至关重要的作用。元数据是关于数据的数据，它描述了数据的结构、属性、关系等信息。在软件应用中，元数据可以用来描述应用的组件、功能、配置等信息。通过元数据驱动应用可以根据元数据的描述来动态地构建和配置自身的功能和结构 差量计算则是实现应用可逆性的关键。当添加或移除扩展包时，系统会根据扩展包中的元数据与标准应用的元数据进行差量计算，确定需要添加或移除的功能和组件。这种差量计算可以确保在添加扩展包后，应用能够保持原有的功能和稳定性，同时新增扩展包带来的新功能，而在去除扩展包时，应用能够恢复到原始的标准状态，不会留下任何冗余或冲突的代码和配置。 为了实现这种架构模式，元数据注册表和分布式部署能力是非常重要的。元数据注册表需要能够存储和管理大量的元数据信息，并且提供高效的查询和更新机制。分布式部署能力则能够确保应用在不同的环境中都能够稳定运行，并且能够快速地响应扩展包的添加和移除操作，即差量(扩展包》可独立存在又相互作用。 总的来说，这种基于元数据驱动和差量计算的软件架构模式为应用的定制和恢复提供了强大的支持，使得应用能够根据不同的需求进行灵活的定制和扩展。同时，它也提高了应用的可维护性和可靠性，降低了开发和维护的成本 2. 协同演进 协同演进，在应用上的特征图 场景：它所描述的场景是一个复杂的软件升级过程，其中涉及了标准应用的升级以及用户个性化扩展的保留。通过面向对象的方式扩展标准应用的功能，可以在升级过程中保持用户自定义逻辑的完整性，并同时集成新版本中的新特性。 价值：很多号称产品型的软件公司，在交付客户项目的时候，都是从标品复制一个分支，然后客户个性化直接在这个分支上改。这种模式会带来两个问题： 是当客户数量变大，每个客户的版本都不一致，维护成本很高； 是当标品升级带来的新特性无法复制给客户，导致客户满意度下降甚至流失。协同演进就是要解决这个问题。 技术原理：它需要在第一个差量计算的特性基础上才能得以完成，同时在这种升级能力中，元数据驱动和模型驱动是关键所在。元数据驱动确保了应用能够理解和处理不同版本之间的变化，包括功能的增删改以及结构的调整。模型驱动则提供了描述和管理应用结构、组件和行为的能力，它不仅能够描述模型间的关系，还能够支持面向对象的特性，如继承、重写和重载等。 具体来说，当标准应用从V1升级到V2时，元数据驱动机制会首先识别和分析两个版本之间的差异。对于用户应用1中已经扩展的A功能，由于采用了面向对象的方式进行扩展，因此在升级过程中，A+逻辑作为A功能的重写或重载版本会被保留下来。同时，V2版本中新增的B功能也会被集成到用户应用1中，因为它是作为标准应用的新特性而存在的。 这种升级能力的实现依赖于一个强大的元数据注册表和模型管理能力。元数据注册表需要能够存储和管理不同版本应用的元数据信息，包括功能、组件、结构等。模型管理能力则需要能够解析和应用这些元数据，以生成正确的应用结构和行为。同时，还需要一套高效的升级机制来确保升级过程的平滑和可靠。 总的来说，通过元数据驱动和模型驱动的结合，可以实现标准应用的平滑升级，同时保留用户个性化扩展的完整性。这种能力对于提高软件的可维护性、可扩展性和用户满意度具有重要意义 3. 公民研发和专业研发共同参与 专业研发与公民研发共同参与，在应用上的特征图 场景：它所描述是在应用开发的整个生命周期中，专业研发专注在标品的长期规划与迭代，当出现临时性的需求或者应急性的辅助场景则由非专业人士进行即公民研发方式进行。这种模式下，专业研发可以按照规划有节奏的迭代产品，做更高级的事情，不至于忙于应对临时性的事务没有深度思考，更加避免了因为临时代码堆积导致产品从内部腐化。同时利用独立的扩展逻辑包和无代码方式解决了业务的紧迫感，毕竟业务需求的合理性是很难争论出高低的。它在前两个特性基础上让研发效能进一步得到释放。 价值：它的本质是，在专业研发在以低代码的方式下实现应用，并通过无代码的方式，快速扩展逻辑功能和创建辅助性应用。整个过程无缝衔接，我们给他取个名字专业名称叫：“低无一体”。它大大降低了技术门槛，使得专业和非专业的研发人员都能参与到应用扩展和定制中来。此外，它还提高了业务响应能力，使得企业能够更快速地适应市场变化和客户需求。 技术原理：它的核心要求就是元数据在线，元数据在线能力是指能够实时地、在线地管理和操作元数据，这种能力为企业或组织带来了诸多优势。通过无 代码的方式，用户可以更加灵活地进行应用的个性化扩展，以应对各种应急性需求，从而显著提升业务的响应能力。此外，元数据在线管理还确保核心应用、核心应用扩展以及辅助应用都是基于一套统一的技术体系构建的，这为不同角色的用户（包括专业和非专业的研发人员）提供了多样化的参与方式。同时，元数据在线管理需要符合开闭原则，这确保了系统的稳定性和可扩展性，使得新的功能或需求可以通过添加新的元数据或配置来实现，而非修改现有系统。 这种低代码开发与无代码一体化的优势在于，它大大降低了技术门槛，使得专业和非专业的研发人员都能参与到应用扩展和定制中来。此外，它还提高了业务响应能力，使得企业能够更快速地适应市场变化和客户需求。 总之，从用户应用到业务实施的过程通过元数据在线得到了优化和升级。低代码开发与无代码一体化的优势使得整个过程更加高效、灵活和易于维护，为企业带来了显著的价值和竞争优势。 4. 基于平台级别的AOP能力出现反向集成 反向集成，在应用上的特征图 场景：平台级别的AOP（面向切面编程）能力允许开发者在应用程序的特定点“切入”额外的逻辑，而无需修改原有的业务代码。这种能力特别适用于横向追加平台逻辑，即在多个不同服务或功能点插入通用的处理逻辑，如日志记录、权限检查、审计、多租户、多语言等。过往在微服务架构中，这些能力都需要业务系统各自主动去对接，有了平台级别的AOP能力，则这些通用能力可以反向为所有业务系统增加特性能力，无需业务系统研发感知。这种现象我们称之为“反向集成”，能让业务研发更加专注在业务研发本身，不需要关心与业务无关的通用功能上。 价值：AOP的核心思想是将这些横切关注点（cross-cutting concerns）从业务逻辑中分离出来，使得业务代码更加清晰和专注于其核心功能。在平台级别的AOP中，标准化协议是实现这一能力的关键。平台具备统一的入口和扩展能力是非常重要的，因为它允许开发者在不修改现有代码的情况下添加新功能或修改现有功能的行为。这种能力对于快速响应业务需求变化、减少维护成本和提高代码质量都是非常有益的。 技术原理：标准化协议确保了不同组件之间的通信与语义是统一的，从而使得AOP能够更容易地实施。例如: a前后端通信要标准协议(与端无关): 这意味着无论前端是使用Web、移动应用还是其他类型的客户端，后端服务都应该能够以一种标准的方式与之通信。 bORM层要有标准协议(与数据库无关): 对象关系映射 (ORM)层应该提供一个标准的接口来与数据库进行交互，这样无论底层使用哪种数据库(如MySQL、PostgreSQL、Oracle等)，上层的业务逻辑都不需要改变。 cRPC需要标准协议(与Dubbo和Spring Cloud无关): 远程过程调用 (RPC)应该遵循一种标准协议，以便不同的服务可以无缝地进行通信，而不受特定框架 (如Dubbo、Spring Cloud等)的限制。 d所有逻辑调用统一fun调用: 这意味着平台上的所有功能调用都应该通过一个统一的入口点(如一个函数或方法)进行，这样AOP就可以在这个入口点切入额外的逻辑。 总的来说，平台级别的AOP能力通过标准化协议和统一的调用入口，为开发者提供了一种强大而灵活的方式来管理和扩展平台的逻辑功能。 5. 应用研发与部署无关 应用研发与部署无关，在应用上的特征图 场景：现在研发在选择部署方式的时候往往会选择分布式部署，或者你的客户招标需求里就写着“微服务”，构建一个微服务系统并不是一件容易的事，构建的复杂度远远超过单体系统，开发人员需要付出一定的学习成本去掌握更多的架构知识和框架知识。服务与服务之间通过HTTP协议或者消息传递机制通信，开发者需要选出最佳的通信机制，并解决网络服务较差时带来的风险。另外服务与服务之间相互依赖，如果修改某一个服务，会对另一个服务产生影响，如果掌控不好。会产生不必要的麻烦。由于服务的依赖性，测试也会变得很复杂，比如修改一个比较基础的服务，可能需要重启所有的服务才能完成测试。前段时间有篇很火的文章，《从微服务转为单体架构、成本降低 90%！》，无论是选择何种部署方式，我认为这都应该跟应用研发无关。 价值：应用研发与部署无关的理念确实为现代软件架构带来了显著的优势，它使得研发团队能够专注于业务逻辑和功能实现，而无需担心具体的部署细节。这种分离带来了灵活性、效率以及成本效益的多重提升。应该采用一种同时支持分布式和单体部署、且可以自由切换的架构，我们称之为可分可合。 首先，可分可合的能力使得系统能够灵活应对业务量的变化。在业务量小的时候，可以采用单体部署的方式，简化部署流程，降低初期成本。随着业务量的增长，系统可以平滑地过渡到分布式部署，通过拆分微服务来提高系统的处理能力和扩展性。这种灵活性确保了系统既能满足未来发展的需要，又能兼顾当下的成本效益。 其次，应用级别扩容的能力使得系统性能不再受限。通过增加微服务实例或调整资源配置，系统可以按需进行扩容，从而确保在业务高峰期或突发流量下仍能保持稳定的性能。这种按需扩容的方式不仅提高了系统的可靠性，还降低了运维成本。 技术原理：核心在于逻辑调用的统一执行和智能判断。通过如funEngine这一统一调用引擎，系统能够智能地选择最适合当前业务场景和性能需求的fun调用方式。无论是同步调用、异步调用还是基于消息队列的调用方式，funEngine都能进行智能决策，确保调用的高效性和可靠性。这种统一调用的方式简化了开发过程，降低了开发难度，同时也提高了系统的可维护性和可扩展性。 此外如果作为低代码或者其他研发平台来说。被集成特性也是实现该特性的关键所在。它提供了一套标准化的接口和协议，使得其他系统或应用能够轻松地与其进行集成。这种平台框架化的特性能够作为一个统一的、可扩展的框架来支撑整个系统的运行。 综上所述，具备可分可合的能力、应用级别扩容以及逻辑调用的统一执行和被集成特性，共同构成了应用研发与部署无关这一核心特性。该特性使得软件系统能够灵活地应对业务变化，实现高效、可扩展和可维护的运行，从而满足客户的长期发展需求并兼顾当下的成本效益。

  史, 昂

  2024年5月23日

  2.5K100
• Oinone 7天入门到精通

  4.1.5 模型之持久层配置

  一、批量操作 批量操作包括批量创建与批量更新。批量操作的提交类型系统默认值为batchCommit。 批量提交类型： useAffectRows，循环单次单条脚本提交，返回实际影响行数 useAndJudgeAffectRows，循环单次单条脚本提交，返回实际影响行数，若实际影响行数与输入不一致，抛出异常 collectionCommit，将多个单条更新脚本拼接成一个脚本提交，不能返回实际影响行数 batchCommit，使用单条更新脚本批量提交，不能返回实际影响行数。 全局配置 pamirs: mapper: batch: batchCommit 图4-1-5-1 全局配置 运行时配置 非乐观锁模型系统默认采用batchCommit提交更新操作；乐观锁模型默认采用useAndJudgeAffectRows提交更新操作。也可以使用以下方式在运行时改变批量提交方式。 Spider.getDefaultExtension(BatchApi.class).run(() -> { 更新逻辑 }, 批量提交类型枚举); 图4-1-5-2 运行时配置 运行时校正 如果模型配置了数据库自增主键，而批量新增的批量提交类型为batchCommit，则系统将批量提交类型变更为collectionCommit（如果使用batchCommit，则需要单条提交以获得正确的主键返回值，性能有所损失）。 如果模型配置了乐观锁，而批量更新的批量提交类型为collectionCommit或者batchCommit，则系统将批量提交类型变更为useAndJudgeAffectRows。也可以失效乐观锁，让系统不做批量提交类型变更处理。 二、乐观锁（举例） 在一些会碰到并发修改的数据，往往需要进行并发控制，一般数据库层面有两种一种是悲观锁、一种是乐观锁。oinone对乐观锁进行了良好支持 定义方式 乐观锁的两种定义方式： 通过快捷继承VersionModel，构建带有乐观锁，唯一编码code且主键为id的模型。 可以在字段上使用@Field.Version注解来标识该模型更新数据时使用乐观锁 如果更新的实际影响行数与入参数量不一致，则会抛出异常，错误码为10150024。如果是批量更新数据，为了返回准确的实际影响行数，批量更新由批量提交改为循环单条数据提交更新，性能有所损失。 失效乐观锁 一个模型在某些场景下需要使用乐观锁来更新数据，而另一些场景不需要使用乐观锁来更新数据，则可以使用以下方式在一些场景下失效乐观锁。更多元位指令用法详见4.1.9【函数之元位指令】一文。 PamirsSession.directive().disableOptimisticLocker(); try{ 更新逻辑 } finally { PamirsSession.directive().enableOptimisticLocker(); } 图4-1-5-3 失效乐观锁 不抛乐观锁异常 将批量提交类型设置为useAffectRows即可，这样可改由外层逻辑对返回的实际影响行数进行自主判断。 Spider.getDefaultExtension(BatchApi.class).run(() -> { 更新逻辑，返回实际影响行数 }, BatchCommitTypeEnum.useAffectRows); 图4-1-5-4 将批量提交类型设置为useAffectRows 构建第一个VersionModel Step1 新建PetItemInventroy模型，继承快捷模型VersionModel package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.base.common.VersionModel; import java.math.BigDecimal; @Model.model(PetItemInventroy.MODEL_MODEL) @Model(displayName = "宠物商品库存",summary="宠物商品库存",labelFields = {"itemName"}) public class PetItemInventroy extends VersionModel { public static final String MODEL_MODEL="demo.PetItemInventroy"; @Field(displayName = "商品名称") private String itemName; @Field(displayName = "库存数量") private BigDecimal quantity; } 图4-1-5-5 新建PetItemInventroy模型 Step2 修改DemoMenu，增加访问入口 @UxMenu("商品库存")@UxRoute(PetItemInventroy.MODEL_MODEL) class PetItemInventroyMenu{} 图4-1-5-6 修改DemoMenu Step3 重启看效果 体验一：页面上新增、修改数据库字段中的opt_version会自动加一 图4-1-5-7 示例效果一 图4-1-5-8 示例效果二 图4-1-5-9 示例效果三 图4-1-5-10 示例效果四 体验二：同时打两个页面，依次点击，您会发现一个改成功，一个没有改成功。但页面都没有报错，只是update返回影响行数一个为1，另一个为0而已。 图4-1-5-11 编辑宠物商品库存 图4-1-5-12 宠物商品库存列表 注：增加了乐观锁，我们在写代码的时候一定要注意，单记录更新操作的时候要去判断返回结果（影响行数），不然没改成功，程序是不会抛错的。不像batch接口默认会报错 Step4 预留任务：重写PetItemInventroy的update函数 留个任务，请各位小伙伴自行测试玩玩，这样会更有体感 package pro.shushi.pamirs.demo.core.action; import org.springframework.stereotype.Component; import pro.shushi.pamirs.demo.api.enumeration.DemoExpEnumerate; import pro.shushi.pamirs.demo.api.model.PetItemInventroy; import pro.shushi.pamirs.demo.api.model.PetTalent; import pro.shushi.pamirs.meta.annotation.Function; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.common.exception.PamirsException; import pro.shushi.pamirs.meta.constant.FunctionConstants; import pro.shushi.pamirs.meta.enmu.FunctionOpenEnum; import pro.shushi.pamirs.meta.enmu.FunctionTypeEnum; import java.util.ArrayList; import java.util.List; @Model.model(PetItemInventroy.MODEL_MODEL) @Component public class PetItemInventroyAction { @Function.Advanced(type= FunctionTypeEnum.UPDATE) @Function.fun(FunctionConstants.update) @Function(openLevel = {FunctionOpenEnum.API}) public PetItemInventroy update(PetItemInventroy data){ List<PetItemInventroy> inventroys = new ArrayList<>(); inventroys.add(data); //批量更新会，自动抛错 int i =…

  史, 昂

  2024年5月23日

  1.9K000
• Oinone 7天入门到精通

  3.1.2 环境准备（windows版）

  一、后端基础环境准备 安装JDK1.8 ，高于1.8_221以上（下载地址见书籍【附件一】） 打开Windows环境变量配置页 此电脑 => 右键属性 => 系统高级设置 => 环境变量 配置环境变量 在用户环境变量中新建变量为JAVA_HOME的项,值为JDK安装之后的路径 图3-1-27 新建环境变量JAVA_HOM 编辑变量为Path的项添加一个值%JAVA_HOME%\bin 图3-1-28 添加一个环境变量值%JAVA_HOME%\\bin PowerShell或者CMD中验证，输出类似信息为安装配置成功 图3-1-29 验证JAVA是否安装成功 安装 Apache Maven 3.8+ （下载地址见书籍【附件一】） 删除Maven安装目录下的conf/settings.xml 配置mvn的settings，下载附件settings-open.xml，并重命名为settings.xml,建议直接放在【C:\Users\你的用户名.m2】下面。下载地址见oinone开源社区群公告，也可以联系oinone合作伙伴或服务人员 配置环境变量 在用户环境变量中新建变量为M2_HOME的项,值为Maven安装路径 图3-1-30 新建变量M2_HOME 编辑变量为Path的项添加一个值%M2_HOME%\bin 图3-1-31 添加一个值%M2_HOME%\\bin 验证 图3-1-32 验证Maven是否安装成功 安装 Jetbrains IDEA （下载地址见书籍【附件一】） 插件安装 下载地址 密码: mdji 如果IDEA安装了Lombok插件,请禁用Lombok插件 点击菜单项File => Settings => Plugins 图3-1-33 插件管理页面操作示意 下载插件包 (联系Oinone官方客服) 图3-1-35 操作指引 图3-1-36 操作指引 安装MySQL 8 （下载地址见书籍【附件一】） 解压下载的ZIP安装包, 复制到自定义安装目录 设置环境变量 MYSQL_BASE_DIR 提换成MySQL安装目录路径 把 %MYSQL_BASE_DIR%\bin 加入到系统环境变量中 在PowerShell中可以使用 Get-Command mysqld 命令验证环境变量是否配置成功，执行成功输出mysqld的所在路径 初始化 在命令行中执行 mysqld –initialize-insecure –user=mysql 安装 mysqld -install 启动MySQL服务 mysqld -install 设置root用户密码 alter user \’root\’@\’localhost\’ identified with mysql_native_password by \’oinone\’; flush privileges; 安装DB GUI工具 Datagrip、MySQLWorkbench、DBEaver 选其一 ### 安装Git （下载地址见书籍【附件一】） 安装GraphQL测试工具Insomnia（下载地址见书籍【附件一】） 安装RocketMQ（下载地址见书籍【附件一】） 修改安装目录下bin中对应文件的默认配置 a. runserver.cmd文件内容 -Xms2g -Xmx2g为 -Xms1g -Xmx1g b. runbroker.cmd文件内容 -Xms2g -Xmx2g为 -Xms1g -Xmx1g，以及-XX:G1HeapRegionSize=1m 启动RocketMQ NameServer命令 RocketMQ安装目录\bin\mqnamesrv.cmd start 启动RocketMQ Broker命令 RocketMQ安装目录\bin\mqbroker.cmd -n localhost:9876 停止 RocketMQ命令 mqshutdown.cmd broker mqshutdown.cmd namesrv 安装ElasticSearch 版本 8.4.1（下载地址见书籍【附件一】） （非必须） ES运行时需要JDK18及以上版本JDK运行环境, ES安装包中包含了一个JDK18版本 set JAVA_HOME=ES安装路径\jdk 启动 ES安装路径\bin\elasticsearch.bat 停止 ctrl+c 或者关闭cmd、PowerShell的窗口 安装Redis （下载地址见书籍【附件一】） 解压安装包到安装目录 在PowerShell进入到Redis安装目录 在PowerShell中执行.\redis-server.exe，输出图中类似信息（如下图3-35所示）： 图3-1-37 验证redis是否安装成功 新开PowerShell窗口, 进入到Redis安装目录, 执行 .\redis-cli.exe回车，输入 ping 回车输出 PONG即表示Redis安装成功 图3-1-38 验证redis是否安装成功 Zookeeper安装（下载地址见书籍【附件一】） 解压安装, 在 PowerShell中执行 tar zxvf 安装包路径(tar.gz包) -C Zk安装目录 进入 Zk安装目录\conf\ 复制 zoo_sample.cfg文件为 zoo.cfg 修改zoo.cfg文件的内容 （其中dataDir需要自己设定） tickTime=2000…

  史, 昂

  2024年5月23日

  3.5K003