相关推荐

• Oinone 7天入门到精通

  3.5.7.3 自定义布局

  布局是什么 在系统中，布局决定了母版内的页面元素，一个页面可以由多个组件进行组装，布局可以根据视图类型来替换。 默认布局范围: 图3-5-7-36 默认布局范围 作用场景 系统内置了多个布局组件，这些组件适用于全局、某个应用或某个页面，提供了灵活的布局定制选项。这些组件根据不同类型的视图进行了默认的组装，这也是选择了视图类型后，页面能够呈现的原因。当然，这些默认的组装是可以被覆盖、新增和添加新组件的。 使用registerLayout进行自定义布局 开发者在使用这些布局组件时，应该遵循公司的规范进行统一的调整。自定义布局组件的使用可通过 registerLayout 实现。registerLayout 的第一个参数是代表布局的 XML，第二个参数是不同的选项维度，默认包含以下维度： viewType: 视图类型 module: 视图模型所在模块 moduleName: 视图模型所在模块名称 model: 视图模型编码 modelName: 视图模型名称 viewName: 视图名称 actionName: 动作名称 inline: 是否内嵌视图(子视图特有) ttype: 模型字段类型(子视图特有) relatedTtype: 关联模型字段类型(子视图特有) field: 字段(子视图特有) 需要注意的是，动作可以是A模块下的a模型，这个动作可以打开B模块下的b模型的视图，module、moduleName、model、modelName应该填b模型对应的值，只不过大部分场景我们都是本模型的动作打开本模型的视图，所以这些场景拿动作所在模型填这些值也可以这些纬度也可以通过查看TS的定义查看 全局 在系统中，我们可以通过指定视图类型来决定某一类视图的全局布局。以表格为例，当第二个入参为 { viewType: ViewType.Table } 时，代表了替换了系统内所有表格的布局样式。 示例工程目录 以下是需关注的工程目录示例，main.ts更新导入./layout，layout/index.ts更新导出./tableLayout： 图3-5-7-37 全局纬度注册布局工程目录示例 示例代码 import {registerLayout, ViewType} from '@kunlun/dependencies' /** * 把系统内所有表格类型视图的全局动作放入搜索区域 * * 移动actionBar布局至外层 * <element widget="actionBar" slot="actionBar" slotSupport="action"> * <xslot name="actions" slotSupport="action" /> * </element> * */ const registerGlobalTableLayout = () => { return registerLayout(`<view type="TABLE"> <element widget="actionBar" slot="actionBar" slotSupport="action"> <xslot name="actions" slotSupport="action" /> </element> <pack widget="group"> <view type="SEARCH"> <element widget="search" slot="search" slotSupport="field" /> </view> </pack> <pack widget="group" slot="tableGroup"> <element widget="table" slot="table" slotSupport="field"> <element widget="expandColumn" slot="expandRow" /> <xslot name="fields" slotSupport="field" /> <element widget="rowActions" slot="rowActions" slotSupport="action" /> </element> </pack> </view>`, { viewType: ViewType.Table }) } registerGlobalTableLayout() 图3-5-7-38 全局纬度注册布局代码示例 效果 图3-5-7-39 全局纬度注册布局效果示例 应用 在系统中，我们可以通过指定视图类型和模块名称来替换某一类视图在特定模块下的全局布局。以表格为例，当第二个入参为 { viewType: ViewType.Table, moduleName: ‘resource’ } 时，代表了替换了资源应用下所有表格的布局样式，而其他应用仍使用默认布局 import {registerLayout, ViewType} from '@kunlun/dependencies' const registerModuleTableLayout = () => { return registerLayout(`<view type="TABLE"> <element widget="actionBar" slot="actionBar" slotSupport="action"> <xslot name="actions" slotSupport="action" /> </element> <pack widget="group"> <view type="SEARCH"> <element widget="search" slot="search" slotSupport="field" /> </view> </pack> <pack…

  史, 昂

  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.4K000
• Oinone 7天入门到精通

  4.1.24 框架之分库分表

  随着数据库技术的发展如分区设计、分布式数据库等，业务层的分库分表的技术终将成老一辈程序员的回忆，谈笑间扯扯蛋既羡慕又自吹地说到“现在的研发真简单，连分库分表都不需要考虑了”。竟然这样为什么要写这篇文章呢？因为现今的数据库虽能解决大部分场景的数据量问题，但涉及核心业务数据真到过亿数据后性能加速降低，能给的方案都还有一定的局限性，或者说性价比不高。相对性价比比较高的分库分表，也会是现阶段一种不错的补充。言归正传oinone的分库分表方案是基于Sharding-JDBC的整合方案，所以大家得先具备一点Sharding-JDBC的知识。 一、分表（举例） 做分库分表前，大家要有一个明确注意的点就是分表字段的选择，它是非常重要的，与业务场景非常相关。在明确了分库分表字段以后，甚至在功能上都要做一些妥协。比如分库分表字段在查询管理中做为查询条件是必须带上的，不然效率只会更低。 Step1 新建ShardingModel模型 ShardingModel模型是用于分表测试的模型，我们选定userId作为分表字段。分表字段不允许更新，所以这里更新策略设置类永不更新，并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.enmu.FieldStrategyEnum; @Model.model(ShardingModel.MODEL_MODEL) @Model(displayName = "分表模型",summary="分表模型",labelFields ={"name"} ) public class ShardingModel extends AbstractDemoIdModel { public static final String MODEL_MODEL="demo.ShardingModel"; @Field(displayName = "名称") private String name; @Field(displayName = "用户id",summary = "分表字段",immutable=true/* 不可修改 **/) @UxForm.FieldWidget(@UxWidget(readonly = "scene == 'redirectUpdatePage'"/* 在编辑页面只读 **/ )) @Field.Advanced(updateStrategy = FieldStrategyEnum.NEVER) private Long userId; } 图4-1-24-1 新建ShardingModel模型 Step2 配置分表策略 配置ShardingModel模型走分库分表的数据源pamirsSharding 为pamirsSharding配置数据源以及sharding规则 a. pamirs.sharding.define用于oinone的数据库表创建用 b. pamirs.sharding.rule用于分表规则配置 pamirs: load: sessionMode: true framework: system: system-ds-key: base system-models: – base.WorkerNode data: default-ds-key: pamirs ds-map: base: base modelDsMap: "[demo.ShardingModel]": pamirsSharding #配置模型对应的库 图4-1-24-2 指定模型对应数据源 pamirs: sharding: define: data-sources: ds: pamirs pamirsSharding: pamirs #申明pamirsSharding库对应的pamirs数据源 models: "[trigger.PamirsSchedule]": tables: 0..13 "[demo.ShardingModel]": tables: 0..7 table-separator: _ rule: pamirsSharding: #配置pamirsSharding库的分库分表规则 actual-ds: – pamirs #申明pamirsSharding库对应的pamirs数据源 sharding-rules: # Configure sharding rule ，以下配置跟sharding-jdbc配置一致 – tables: demo_core_sharding_model: #demo_core_sharding_model表规则配置 actualDataNodes: pamirs.demo_core_sharding_model_${0..7} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: table_inline shardingAlgorithms: table_inline: type: INLINE props: algorithm-expression: demo_core_sharding_model_${(Long.valueOf(user_id) % 8)} props: sql.show: true 图4-1-24-3 分库分表规则配置 Step3 配置测试入口 修改DemoMenus类增加一行代码，为测试提供入口 @UxMenu("分表模型")@UxRoute(ShardingModel.MODEL_MODEL) class ShardingModelMenu{} 图4-1-24-4 配置测试入口 Step4 重启看效果 自行尝试增删改查 观察数据库表与数据分布 图4-1-24-5 自行尝试增删改查 图4-1-24-6 观察数据库表与数据分布 二、分库分表（举例） Step1 新建ShardingModel2模型 ShardingModel2模型是用于分库分表测试的模型，我们选定userId作为分表字段。分库分表字段不允许更新，所以这里更新策略设置类永不更新，并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import…

  史, 昂

  2024年5月23日

  1.5K000
• Oinone 7天入门到精通

  应用中心

  在App Finder 中点击应用中心可以进入Oinone的应用中心，可以看到Oinone平台所有应用列表、应用大屏、以及技术可视化。 1. App Finder 平台提供App Finder搜索查找已安装的应用、点击进入应用； 我收藏的应用：在应用中心收藏后会呈现在“我收藏的应用”； 业务应用：与业务相关、用户可操作的应用； 设计器：平台提供五大设计器设计应用，即平台的无代码能力，包括：模型设计器、界面设计器、流程设计器、数据可视化、集成设计器。 2. 应用列表 应用列表管理平台中所有应用，管理应用的生命周期，如安装、升级、卸载，提供搜索、创建、编辑、卸载、收藏、设置首页等功能。 在介绍应用具体操作前，我们先来了解以下概念： 应用类型：分为应用与模块两种类型，两者区别在于在于应用有前台页面，可以在前台页面操作数据，模块没有前台页面、服务于其他应用或模块，大家在创建应用时可根据业务需求创建应用或模块。 依赖：创建新应用时，可依赖已有应用或模块，依赖后使用依赖应用/模块的能力，比如依赖文件应用可使用导入、导出能力，依赖资源应用可使用地址、语言等能力。 图3-2-35 Oinone的应用列表 2.1 创建 创建应用时，需要选择类型、定义应用名称、技术名称，选择依赖模块、所属分类、客户端类型。 每个应用大多数都需要依赖一些基础模块：文件、资源、 应用分类是按照应用所属业务域进行的分类管理，目前是平台提供的分类，后续会开放给用户自行管理。 客户端类型是指应用适用于PC端、移动端，如果只选择PC端，则应用不可在移动端使用。 2.2 编辑 编辑时，不允许编辑类型，技术名称，需要在创建时定义正确。 2.3 安装与卸载 卸载后，应用就不会呈现在App Finder中，不可进入应用、使用应用，可重新安装，安装后继续使用。 2.4 收藏应用 点击应用卡片右上角的星标可收藏、取消收藏应用，收藏的应用在App Finder和工作台中展示在收藏位置，可快捷进入。 2.5 设置首页 定义每个应用的首页，有两种方式： a. 通过绑定菜单，进入绑定菜单的页面； b. 直接绑定视图，选择模型、找到模型下的视图，如果可作为首页的视图不存在，也可以进入设计器创建。 2.6 应用详情 点击了解更多，可进入应用详情，查看应用基础信息。 2.7 设计器快捷入口 设计页面：进入界面设计器； 设计模型：进入模型设计器； 设计流程：进入流程设计器； 3. 应用大屏 应用大屏按照分类展示应用，未设置应用分类的应用，无法在应用大屏中呈现。 图3-2-37 未设置应用类目则无法在应用大屏中呈现。 4. 技术可视化 在技术可视化页面，出展示已经安装模块的元数据，并进行分类呈现。 图3-2-38 云数据分类呈现

  史, 昂

  2024年5月23日

  2.3K000
• 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.0K000