相关推荐

• Oinone 7天入门到精通

  5.2 CDM之工程模式

  两种工程模式介绍 oinone推荐的两种工程模式都保留互联网特性，如跟业务无关的基础平台还是采用平台化思路建设。二种侧重点差异如下 第一种：比较适合企业采用多供应商联合开发场景，先以业务区分，各个业务线有独立的领域平台，最大限度保持不同业务线的独立性，有利于各个业务线独立发展（目前oinone上层星空系列产品采用这种工程模式，因为我们期望的时候帮助企业构建软件生态，必然要考虑不同供应商联合开发场景） 第二种：比较接近传统互联网架构，先按平台领域区分，如商品领域：商品平台做总工程，但里面按业务区分模块分子工程来保持业务相互独立，相对于第一种把领域的代码放一起，带来好处强化大家思考模型通用性。但不适用于跨公司主体间配合。 图5-2-1 Oinone-CDM的两种工程模式 注意事项： oinone兼容传统互联网架构 不管哪种模式，都需要解决CDM的维护问题 CDM维护的常见问题： Q：CDM层缺少模型怎么办？ A：CDM层模型是逐步完善和丰富的。如果是特定业务自己需要的模型，这类模型无通用性。则加到自己的工程中；如果是通用的，则架构组确定是否需要纳入到CDM。 Q：CDM层已有的模型缺少字段怎么办？ A：CDM层模型的字段也是逐步完善和丰富的，通用的字段在架构组确定后也会被吸收进来 Q：CDM层不同业务线相互影响怎么办？ A：扩展字段最好带上自有前缀标志，如果觉得通用则提交架构组走模型缺少字段加入 Q：CDM层某模型新增加了的字段，但原先业务线已经加了相同含义字段 A：业务线可以把自己的字段related到CDM增加的新字段，并做数据迁移

  史, 昂

  2024年5月23日

  1.5K000
• Oinone 7天入门到精通

  1.3 Oinone的生态思考

  以“企业级软件生态”的方式去帮助企业建立“一站式的商业智能软件”。 通过观察信息化到数字化的软件行业发展历程（如下图1-3所示），我们可以发现，企业真正需要的是一站式的软件产品。然而，一站式的软件产品往往都是从单个领域的需求满足开始，这在信息化时代和数字化时代都是如此。在信息化时代，以ERP为终点的一站式趋势逐渐形成；而在数字化时代，中台概念的提出则标志着一站式的趋势重新开始。本文将从企业数字化转型所面临的困境出发，探讨Oinone的生态思考。 图1-3 从信息化到数字化软件行业发展历程 1.3.1 与中台的渊源 中台概念的提出标志着企业数字化改造进入了一个新的时代。随着数字化转型不断深入，企业面临着严重的数据割裂、系统隔离等问题。在这样的背景下，“敏捷响应，低成本地快速创新”成为了推动一站式商业智能软件的内在诉求。需要澄清的是，互联网中台架构只是一种企业解决数据割裂、系统隔离，建立一站式商业智能软件的技术概念之一，并不是技术标准。而且这种方式只适用于企业自建模式。在多供应商环境下，则会适得其反，导致建立更复杂的烟囱系统。 阿里于15年提出中台架构概念，抓住了企业数字化转型的核心诉求，即“敏捷响应，低成本快速创新”。然而，阿里作为一家生态公司，在16年时基本上是带着合作伙伴来给企业交付，但由于伙伴对互联网技术的理解和能力的限制，基本上都做得不好，甚至失败。在2017年，阿里成立了原生交付团队，希望能够树立一些标杆案例。我和公司的核心成员也都来自于这个团队。在做完几个客户后，我发现阿里也做不好，但这次做不好的原因不是技术不行或项目上不了线，而是上线以后预期的效果没有达到，其本质是企业的IT组织能力无法驾驭复杂的互联网中台架构。当无法驾驭的时候，所谓的目标“敏捷响应，快速创新”就无从说起了。结果客户会反馈以下三类问题： 不是说敏捷响应吗？为什么改个需求这么慢，不但时间更长，付出的成本也更高了？是因为中台架构需要一定的技术能力和经验才能有效地应用，就像一个只会骑自行车的人给他一辆汽车或者飞机，他也不能驾驭它们，更不用说是手动挡的。 不是说能力中心吗？当引入新供应商或有新场景开发的时候，为什么前期做的能力中心不能支撑了？是因为能力中心是一种面向业务的能力组织方式，它将不同的业务能力抽象出来，以服务的形式对内提供。然而，由于业务场景的差异，不同的业务需要的能力也会不同，因此能力中心需要不断迭代和升级。对于新引入的供应商或新场景开发，需要根据实际情况对能力中心进行定制化和扩展化，但谁来负责呢？新项目的供应商还是客户自己？ 不是说性能好吗？为什么我投入的物理资源更多了？是因为中台架构采用微服务来解决单点瓶颈问题，提高系统性能和可用性，但是在初始阶段，投入的资源可能会更多。每个模块至少需要两个实例来保障高可用性，因此物理资源的投入量可能会比以前更多。 1.3.2 找解决方案 在考虑解决方案之前，我们需要思考企业数字化软件的最终状态将是什么样子。目前有两种主要的方案（如下图1-4所示）： 第一种是以自建研发团队为核心。中国的大型企业已经开始尝试这种模式，看起来似乎是一个时下比较流行的可行性方案。然而，绝大多数企业由于成本、人才团队等原因而难以坚持下去，只能与供应商合作开发。 第二种是以供应商为核心。由于大多数企业无法选择第一种路径，他们必须接受目前分散的情况，并通过系统集成尽可能拉通各个系统。尽管如此，在数字化时代中，真正意义上的一站式商业智能软件供应商还未出现。 图1-4 企业数字化桎梏和囹圄 对企业来说，这两种方案都非常艰难，但在大规模数字化历程中又不得不做出选择。此外，我们还能清晰看到以下几点： "敏捷响应，低成本地快速创新"成为企业推动一站式商业智能软件的内在诉求 目前没有一家软件供应商能满足企业所有外围商业场景，也不可能有这样的供应商 绝大部分企业需要软件供应商，而不是自建 如何突破这种局面也成为中国软件行业发展的一个机遇。因此，我的思考是： 我们的目标不是依托于提升研发人员的能力，而是降低互联网架构的门槛，让更多企业真正拥有“敏捷响应，低成本快速创新”的能力。 我们的目标不是输出中台方法论，而是提供中台建设的技术平台。 我们的目标不是只服务大企业，而是真正赋能不同IT组织能力的企业，让它们都具备持续创新的能力。 今天，许多中台软件公司告诉企业：“中台是持续演进和快速迭代的过程，因此企业需要组建中台架构团队来实现，而他们则通过中台项目落地将中台建设方法论传授给企业。”这句话的前半部分是正确的，因为我们之前提到企业需要具备敏捷响应业务的能力，即应变能力，因为应变是不断变化的。然而，后半部分是不正确的，因为今天的企业已经有能力组建团队，那么这些中台软件公司到底有什么用呢？企业真的缺少方法论吗？在19年，我就提出了自己的看法：没有低代码能力的中台公司都在收取智商税，都在欺诈，因为很多企业根本找不到足够懂互联网架构的人才。明白流氓在哪里了吗？这些流氓公司赚了很多钱，最后责怪企业无法招到人才，这是企业的责任。因此，仍然认为“最好的赋能是降低门槛，而不是让客户提高技术水平”。 最终，我们得出了一个服务模式的想法：构建企业级的软件生态。企业级软件生态的确切定义是：通过开放的方式，让企业本身以及不同的软件供应商共同参与，遵循相同的技术和数据规范，打造一体化、无需集成的各类企业级软件。如果要打造企业级软件生态，我们列出了六个要点（如下图1-5所示）。 图1-5 打造企业级软件生态需要具备的六大能力 我很幸运地有机会通过“企业级软件生态”的方式，为企业建立“一站式的商业支持平台”提供帮助。我们的Oinone平台结合了低代码开发、通用数据模型和业务产品的优势（如下图1-6所示）。 图1-6 Oinone = 低代码开发平台 + 通用数据模型 + 业务产品 我们对Oinone一站式低代码商业支撑平台展开介绍，它大致分为4部分： 以低代码开发平台为基础，输出具备互联网架构下的软件快速开发标准。这可以帮助企业快速构建符合互联网架构标准的应用程序，从而实现快速响应和低成本创新。 以通用数据模型为基础，满足不同软件基于同一套数据标准的扩展能力。这可以确保不同软件系统之间的数据兼容性和互操作性，避免数据孤岛和信息隔离。 在业务产品层面上，企业和伙伴基于相同的技术标准和数据标准共同提供解决方案。这可以帮助企业和伙伴共同开发出符合标准的商业支撑平台，以提高业务效率和创新能力。 最后是无代码设计器，用于满足项目开展中，超出业务标品范围之外的需求，或者针对标品的临时需求。这可以帮助业务人员在不需要专业软件支持的情况下，自主解决业务需求，并支持部门间的协同工作。 1.3.3 生态建设 Oinone致力于打造全球最大的无需集成的商业应用程序及其生态系统，通过开源内核、汇集数千名开发人员和业务专家，为企业提供成本效益、一体化、模块化的解决方案，解决所有商业需求，让不同技术之间的合作变得简单易行，摆脱烦恼的集成问题。 在客户和场景领域，我们严格限定了自身的专注领域。针对超大型头部企业，我们专注于树立标杆，而对于大、中、小型企业，则交由我们的伙伴来支持。小微企业可以通过我们的开源社区版获得覆盖。在企业数字化转型的核心领域中，我们的解决方案涵盖了数字化交易场景、全渠道订单履约场景、数字化采购场景、数字化营销等产品。在其他领域，我们完全交由伙伴来建设。由于我们自身在企业协同商务领域拥有深厚的背景，因此在该领域提供的产品拥有特别的优势。 企业数字化转型核心领域 图1-7 企业数字化转型核心领域

  史, 昂

  2024年5月23日

  2.0K000
• Oinone 7天入门到精通

  4.4 Oinone的分布式体验进阶

  在分布式开发中，每个人基本只负责自己相关的模块开发。所以每个研发就都需要一个环境，比如一般公司会有（N个）项目环境、1个日常环境、1个预发环境、1个线上环境。在整项目环境的时候就特别麻烦，oinone的好处是在于每个研发可以通过boot工程把需要涉及的模块都启动在一个jvm中进行开发，并不依赖任何环境，在项目开发中，特别方便。但当公司系统膨胀到一定规模，大到很多人都不知道有哪些模块，或者公司出于安全策略考虑，或者因为启动速度的原因（毕竟模块多了启动的速度也会降下来）。本文就给大家介绍oinone与经典分布式组织模式的兼容性 一、模块启动的最小集 我们来改造SecondModule模块，让该模块的用户权限相关都远程走DemoModule Step1 修改SecondModule的启动工程application-dev.yml文件 除了base、second_core两个模块保留，其他模块都去除了。 pamirs: boot: init: true sync: true modules: – base – second_core 图4-4-1 SecondModule的application-dev.yml仅配置两个模块 Step2 去除boot工程的依赖 去除SecondModule启动工程的pom依赖 <!– <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-resource-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-user-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-auth-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-message-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-international</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-business-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-apps-core</artifactId> </dependency> –> 图4-4-2 去除boot工程多余的依赖 Step3 重启SecondModule 这【远程模型】和【远程代理】均能访问正常 图4-4-3 远程模型和远程代理菜单均能访问正常 Step4 SecondModule增加对模块依赖 我们让SecondModule增加用户和权限模块的依赖，期待效果是：SecondModule会对用户和权限的访问都会走Dome应用，因为Demo模块的启动工程中包含了user、auth模块。 修改pamirs-second-api的pom文件增加对user和auth的api包依赖 <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-user-api</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-auth-api</artifactId> </dependency> 图4-4-4 修改pamirs-second-api的pom文件 修改SecondModule类，增加依赖定义 @Module( dependencies = {ModuleConstants.MODULE_BASE, AuthModule.MODULE_MODULE, UserModule.MODULE_MODULE} ) 图4-4-5 配置SecondModule的依赖 Step5 修改RemoteTestModel模型 为RemoteTestModel模型增加user字段 @Field.many2one @Field(displayName = "用户") private PamirsUser user; 图4-4-6 为RemoteTestModel模型增加user字段 Step6 重启系统看效果 mvn install pamirs-second工程，因为需要让pamirs-demo工程能依赖到最新的pamirs-second-api包 重启pamirs-second和pamirs-demo 两个页面都正常 图4-4-7 示例效果一 图4-4-8 示例效果二 二、PmetaOnline的NEVER指令（开发时环境共享） 我们在4.1.2【模块之启动指令】一文中介绍过 “-PmetaOnline指令”，该参数用于设置元数据在线的方式，如果不使用该参数，则profile属性的默认值请参考服务启动可选项。-PmetaOnline参数可选项为： NEVER – 不持久化元数据，会将pamirs.boot.options中的updateModule、reloadMeta和updateMeta属性设置为false MODULE – 只注册模块信息，会将pamirs.boot.options中的updateModule属性设置为true，reloadMeta和updateMeta属性设置为false ALL – 注册持久化所有元数据，会将pamirs.boot.options中的updateModule、reloadMeta和updateMeta属性设置为true oinone的默认模式下元数据都是注册持久化到DB的，但当我们在分布式场景下新开发模块或者对已有模块进行本地化开发时，做为开发阶段我们肯定是希望复用原有环境，但不对原有环境照成影响。那么-PmetaOnline就很有意义。让我们还没有经过开发自测的代码产生的元数据仅限于开发本地环境，而不是直接影响整个大的项目环境 PmetaOnline指令设置为NEVER（举例） Step1 为DemoCore新增一个DevModel模型 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; @Model.model(DevModel.MODEL_MODEL) @Model(displayName = "开发阶段模型",summary="开发阶段模型，当PmetaOnline指令设置为NEVER时，本地正常启动但元数据不落库",labelFields={"name"}) public class DevModel extends AbstractDemoCodeModel{ public static final String MODEL_MODEL="demo.DevModel"; @Field(displayName = "名称") private String name; } 图4-4-9 为DemoCore新增一个DevModel模型 Step2 为DevModel模型配置菜单 @UxMenu("开发模型")@UxRoute(DevModel.MODEL_MODEL) class DevModelProxyMenu{} 图4-4-10 为DevModel模型配置菜单 Step3 启动Demo应用时指定-PmetaOnline 图4-4-11 启动Demo应用时指定-PmetaOnline Step4 重启系统看效果 查看元数据 图4-4-12 DB查看元数据变化 菜单与页面能正常操作 图4-4-13 开发模型菜单可正常操作 图4-4-14 开发模型详情页面可正常操作 Step5 Never模式需注意的事项 业务库需设定为本地开发库，这样才不会影响公共环境，因为对库表结构的修改还是会正常进行的 如果不小心影响了公共环境，需要对公共环境进行重启恢复 系统新产生的元数据（如：例子中的【开发模式】菜单）不受权限管控 三、分布式开发约定 设计约定 跨模块的存储模型间继承，在部署时需要跟依赖模块配置相同数据源。这个涉及模块规划问题，比如业务上的user扩展模块，需要跟user模块一起部署。…

  史, 昂

  2024年5月23日

  1.3K000
• 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日

  1.8K100
• Oinone 7天入门到精通

  1.5 Oinone与行业对比

  随着企业数字化转型的推进，软件公司获得了许多机会。尽管竞争日趋激烈，但由于需求旺盛，各种模式仍在不断涌现。因此，当前市场上存在各种各样的数字化转型解决方案，围绕企业的各个方面展开。每种解决方案都有其优点和缺点。本文将从定位、技术和产品等方面简单比较，帮助您从不同的视角了解Oinone的差异。 1.4.1 整体视角对比 一、与对标公司Odoo的对比 Odoo Oinone 定位 一站式全业务链管理平台：赋能企业信息化升级 一站式低代码商业支撑平台：赋能企业数字化升级 需求变化 关注单一企业的管理、流程、效率的提升 关注企业价值链的网络竞争，围绕外部协同、运营、数据、商业展开 技术更替 关注稳定、安全、功能丰富度 除了稳定、安全、功能丰富度以外，更强调需求响应速度、用户体验、系统承载极限与弹性扩展、智能化 表1-1 Oinone与对标公司Odoo的对比 二、与国内低代码或无代码公司对比 低代码或无代码公司 Oinone 定位 低代码开发工具：提供各类系统模版，基于模版快速搭建和个性化配置。但系统模版无法再升级 平台型SaaS：提供各类系统产品，产品安装后客户可以根据需求进行个性化调整，同时产品永远在线可升级 场景差异 只能支持企业内部人员使用，以完成部门级边缘系统为主，一般多为没有专业软件厂商支撑和强临时性特性 从内外部协同的商业场景出发，关注企业核心业务场景，适应【企业业务在线化后，所有的业务变化与创新都需要通过系统来触达上下游】的时代背景，以敏捷响应业务的变化与创新为目标 技术代差 单表支撑100万数据已是业内天花板 支撑单模型数据过亿，无单点瓶颈。封装互联网架构并且做到单体与分布式的灵活部署，为不同大小公司提供不同技术支撑 表1-2 Oinone与国内低代码/无代码公司对比 1.4.2 从技术角度对比 我们不会与其他无代码平台进行比较，因为它们不能解决业务复杂性的问题。相反，我们将重点介绍三种不同的低代码平台模式（如下图1-8所示）。 第一种模式是最基础的低代码平台，也被称为代码生成器。它通过预定义应用程序模板和必要的配置生成代码，简化了工程搭建并提供了一些基础逻辑。虽然在信息化时代内部流程标准化方面较为适合，但在数字化时代外部协同业务在线的情况下就不那么合适了。因为这种模式不能减少研发难度和提高效率，也无法体现敏捷迭代快速创新的优势。 第二种模式是经典的低代码平台，以元数据为基础，以模型为驱动。当无法满足需要时，通过特定方式将代码以插件的形式注入平台，作为低代码平台的内置逻辑，供设计器使用。它的优点在于降低了研发门槛，当无法满足需求时才需要编写代码。它可以实现企业内部的复杂流程和复杂逻辑，但其性能和工程管理存在局限性。性能问题使其不适合处理互联网化的在线业务，而工程管理问题则使其不适合处理快速变化的业务。这也是许多研发人员反对低代码的核心原因之一，因为研发人员变成了辅助角色，而软件工程是一门需要技术能力的学科，让没有技术能力的人主导是违反常理的。对于软件产品公司来说，产品需要迭代规划，需要多人协作，需要工程化管理。 第三种模式是oinone提出的基于互联网架构的低代码平台，它采用低无一体的设计。首先，oinone屏蔽了互联网架构带来的复杂性。其次，同样以元数据为基础，以模型为驱动，但是元数据的生成方式有两种：一种是使用无代码设计器（与经典低代码相同），另一种是通过代码来描述元数据。通过使用代码来描述元数据，可以无缝地与代码衔接，并在不改变研发习惯的情况下降低门槛、提高效率，并进行工程化管理。 最后总结来说：低无一体不仅仅是指两种模式的结合，还包括两种模式的融合应用方式。具体来说，这种融合应用方式可以分为两种情况： 当开发核心产品时，主要采用低代码开发，无代码设计器作为辅助。这种方式可以提高开发效率和代码质量，同时保证产品的快速迭代和升级。 当需要满足个性化或非产品支持的需求时，主要采用无代码设计器，低代码作为辅助。这种方式可以快速地满足客户需求，并且避免对产品的核心代码产生影响。 简单来说，低代码模式适用于产品的迭代升级，而无代码设计器则适用于满足个性化和非产品支撑的额外需求。低代码和无代码模式在整个软件生命周期中都有各自的价值，在不同场景下可以相互融合，发挥最大的优势。 图1-8 代码生成器、低代码平台与Oinone的优缺点对比 1.4.3 从产品角度对比 产品上的对比，从客户、场景满足度、再次销售三个方面来做简易的对比 一、Oinone vs 数字化软件服务商 客户 满足度 销售 Oinone 一站式商业智能软件，更高性价比、用户体验客户范围：5000万~5亿、5亿～100亿、标杆：100亿～1000亿、1000亿以上 满足企业核心业务需求，并联合伙伴一起满足企业所有需求，无需集成提供统一工作台、数据接口、底层协议，无论基于Oinone的开源框架还是增加其他应用都有很好的扩展性 支持OP+SaaS两种模式，收费方式不同：OP按买断方式进行，SaaS按效果付费跟账号数无关新的模块进行二次销售 数字化软件服务商 针对成熟的大型企业需投入巨大资源和成本客户范围：100亿～1000亿、1000亿以上 满足企业部分需求，无法输出技术标准，无法解决多供应商一起开发的问题，只能通过集成实现对接 OP模式进行销售，通过设置权限来进行来实现二次销售或无法进行二次销售 表1-3 Oinone vs 数字化软件服务商 二、Oinone vs 低代码或无代码行业 客户 满足度 销售 Oinone 一站式商业智能软件客户范围：5000万~5亿、5亿～100亿、标杆：100亿～1000亿、1000亿以上 从外部商业场景出发，强业务场景驱动，符合企业从信息化管理到业务创新的数字化转变的趋势。提供统一工作台、数据接口、底层协议，无论基于oinone的开源框架还是增加其他应用都有很好的扩展性 支持OP+SaaS两种模式，收费方式不同：OP按买断方式进行，SaaS按效果付费跟账号数无关新的模块进行二次销售 低代码或无代码公司 针对小微企业内部信息化管理诉求，以表单流程为主客户范围：5亿以下 满足企业部门级信息化的适应性需求，无法满足企业核心业务管理与业务创新诉求 按应用模块进行收费，新的模块进行二次销售 表1-4 Oinone vs 低代码或无代码行业 三、Oinone vs 国外对标公司Odoo 客户 满足度 销售 Oinone 一站式商业智能软件客户范围：5000万~5亿、5亿～100亿、标杆：100亿～1000亿、1000亿以上 从外部商业场景出发，强业务场景驱动，符合企业从信息化管理到业务创新的数字化转变的趋势。基线产品覆盖：采购、营销、服务、销售、交易等企业商业领域。主要涉及行业：零售品牌。其他领域或行业靠合作伙伴共建方式进行 支持OP+SaaS两种模式，收费方式不同：OP按买断方式进行，SaaS按效果付费跟账号数无关新的模块进行二次销售 Odoo 一站式企业管理软件客户范围：5000万~5亿、5亿～100亿、标杆：100亿～1000亿、1000亿以上 从企业内部管理需求出发，逐渐拥有互联网相关应用组件，但还是属于强内部管理、弱外部场景。基线产品覆盖：业务财务一体化、人财务、进销存。主要涉及行业：建造业。其他领域或行业靠合作伙伴共建方式进行 支持OP+SaaS两种模式，收费方式相同：按用户数+应用模块进行收费新的模块进行二次销售 表1-5 Oinone vs 国外对标公司Odoo

  史, 昂

  2024年5月23日

  1.9K200