4.4 Oinone的分布式体验进阶

史, 昂 • 2024年5月23日 am8:28 • Oinone 7天入门到精通 • 1504 views

在分布式开发中，每个人基本只负责自己相关的模块开发。所以每个研发就都需要一个环境，比如一般公司会有（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模块一起部署。
跨模块的多对多关系，配置中间表模型，在3.3.9【字段类型之关系与引用】一文中的“M2M字段”部分有详细介绍。
基础依赖：base。
canal相关参考：4.1.10【函数之触发与定时】中提到的修改topic方案。

编码约定

跨模块间用service来调用，避免直接调用模型的数据管理器（如new 非本模块Model().queryPage等）。结构性代码可以用oinone提供研发辅助工具进行提效率
在3.4.1【构建第一个Function】一文中有提到，需要在API包中声明注解了@Fun注解的函数接口，并在接口的方法上加上@Function注解。

Oinone社区作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9311.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

Oinone 7天从入门到精通

Like (0)

史, 昂数式管理员

0 0

4.5 研发辅助

Previous 2024年5月23日

4.3 Oinone的分布式体验

Next 2024年5月23日

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.5K000
序篇

史, 昂
Oinone 7天入门到精通 2024年5月23日
2.6K000
4.1.22 框架之分布式缓存

分布式缓存Oinone平台主要用到了Redis，为了让业务研发时可以无感使用RedisTemplate和StringRedisTemplate，已经提前注册好了redisTemplate和stringRedisTemplate，而且内部会自动处理相关特殊逻辑以应对多租户环境，小伙伴不能自己重新定义Redis的相关bean。使用说明配置说明 spring: redis: database: 0 host: 127.0.0.1 port: 6379 timeout: 2000 # cluster: # nodes: # – 127.0.0.1:6379 # timeout: 2000 # max-redirects: 7 jedis: pool: # 连接池中的最大空闲连接默认8 max-idle: 8 # 连接池中的最小空闲连接默认0 min-idle: 0 # 连接池最大连接数默认8 ，负数表示没有限制 max-active: 8 # 连接池最大阻塞等待时间（使用负值表示没有限制）默认-1 max-wait: -1 图4-1-22-1 分布式缓存配置说明代码示例 package pro.shushi.pamirs.demo.core.service; import org.springframework.stereotype.Component; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data.redis.core.RedisTemplate; import org.springframework.data.redis.core.StringRedisTemplate; @Component public class Test { @Autowired private RedisTemplate redisTemplate; @Autowired private StringRedisTemplate stringRedisTemplate } 图4-1-22-2 代码示例

史, 昂
Oinone 7天入门到精通 2024年5月23日
1.7K000
Oinone 7天入门到精通

4.1.8 函数之事务管理

一、事务管理介绍函数Function支持事务字段为isTransaction（默认为false），事务传播行为propagationBehavior（默认PROPAGATION_SUPPORTS），事务隔离级别isolationLevel（默认使用数据库默认的事务隔离级别），所以不会默认为函数添加事务。另外事务配置提供全局配置。平台事务管理兼容Spring声明式与编程式事务，支持多数据源事务管理。事务管理中多数据源嵌套独立事务，不会造成死锁风险。使用多数据源或分表操作，不会导致脏读。如果需要多数据源分布式事务，请使用PamirsTransational分布式事务管理方案（@PamirsTransational(enableXa=true)）。分布式事务一般用于量小的跨模块配置管理场景使用方式声明式事务，使用@PamirsTransactional注解在需要事务管理的类或方法上标注。在非无代码场景下，与@Transactional注解功能一致。编程式事务，使用PamirsTransactionTemplate即可。在非无代码场景下，与TransactionTemplate功能一致。配置式事务，使用TxConfig模型在模块安装时初始化存储事务配置数据。事务特性原子性（atomicity）:强调事务的不可分割. 一致性（consistency）:事务的执行的前后数据的完整性保持一致. 隔离性（isolation）:一个事务执行的过程中,不应该受到其他事务的干扰持久性（durability） :事务一旦结束,数据就持久到数据库事务隔离级别事务隔离级别指的是一个事务对数据的修改与另一个并行的事务的隔离程度，当多个事务同时访问相同数据时，如果没有采取必要的隔离机制，就可能发生以下问题：问题描述脏读一个事务读到另一个事务未提交的更新数据，所谓脏读，就是指事务A读到了事务B还没有提交的数据，比如银行取钱，事务A开启事务，此时切换到事务B，事务B开启事务–>取走100元，此时切换回事务A，事务A读取的肯定是数据库里面的原始数据，因为事务B取走了100块钱，并没有提交，数据库里面的账务余额肯定还是原始余额，这就是脏读不可重复读在一个事务里面的操作中发现了未被操作的数据比方说在同一个事务中先后执行两条一模一样的select语句，期间在此次事务中没有执行过任何DDL语句，但先后得到的结果不一致，这就是不可重复读幻读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。表4-1-8-1 事务隔离级别 Pamirs（Spring）支持的隔离级别隔离级别描述 DEFAULT 使用数据库本身使用的隔离级别 ORACLE（读已提交） MySQL（可重复读） READ_UNCOMITTED 读未提交（脏读）最低的隔离级别，一切皆有可能。 READ_COMMITED 读已提交，ORACLE默认隔离级别，有不可重复读以及幻读风险。 REPEATABLE_READ 可重复读，解决不可重复读的隔离级别，但还是有幻读风险。 SERLALIZABLE 串行化，最高的事务隔离级别，不管多少事务，挨个运行完一个事务的所有子事务之后才可以执行另外一个事务里面的所有子事务，这样就解决了脏读、不可重复读和幻读的问题了表4-1-8-2 隔离级别与描述隔离级别脏读可能性不可重复读可能性幻读可能性加锁度 READ_UNCOMITTED 是是是否 READ_COMMITED 否是是否 REPEATABLE_READ 否否是否 SERLALIZABLE 否否否是表4-1-8-3 隔离级别说明表事务的传播行为保证同一个事务中 PROPAGATION_REQUIRED 支持当前事务，如果不存在就新建一个(默认) PROPAGATION_SUPPORTS 支持当前事务，如果不存在，就不使用事务 PROPAGATION_MANDATORY 支持当前事务，如果不存在，抛出异常保证没有在同一个事务中 PROPAGATION_REQUIRES_NEW 如果有事务存在，挂起当前事务，创建一个新的事务 PROPAGATION_NOT_SUPPORTED 以非事务方式运行，如果有事务存在，挂起当前事务 PROPAGATION_NEVER 以非事务方式运行，如果有事务存在，抛出异常 PROPAGATION_NESTED 如果当前事务存在，则嵌套事务执行 A中嵌套B事务，嵌套PROPAGATION_REQUIRES_NEW方法勿与A在同类中。异常状态 PROPAGATION_REQUIRES_NEW （两个独立事务） PROPAGATION_NESTED (B的事务嵌套在A的事务中) PROPAGATION_REQUIRED (同一个事务) A抛异常 B正常 A回滚，B正常提交 A与B一起回滚 A与B一起回滚 A正常 B抛异常 1.如果A中捕获B的异常，并没有继续向上抛异常，则B先回滚，A再正常提交； 2.如果A未捕获B的异常，默认则会将B的异常向上抛，则B先回滚，A再回滚 B先回滚，A再正常提交 A与B一起回滚 A抛异常B抛异常 B先回滚，A再回滚 A与B一起回滚 A与B一起回滚 A正常 B正常 B先提交，A再提交 A与B一起提交 A与B一起提交表4-1-8-4 事务传播行为二、声明式事务（举例） Step1 修改PetShopBatchUpdateAction 用@PamirsTransactional或者@Transactional注解来声明事务，PamirsTransactional跟Spring的Transactional区别在于PamirsTransactional支持多库事务，但此多库事务为非严格的分布式多库事务，之所以选择这个方案，原因如下 a. 不损害任何性能。 b. 事务保障率超过4个9 c. 经过阿里的大厂验证，特别是在阿里的结算平台中得到了很好的验证 @PamirsTransactional更多配置项请详见4.1.7【函数之元数据详解】一文，自己多试试。同时@PamirsTransactional百分百兼容@Transactional @Action(displayName = "确定",bindingType = ViewTypeEnum.FORM,contextType = ActionContextTypeEnum.SINGLE) @PamirsTransactional //@Transactional public PetShopBatchUpdate conform(PetShopBatchUpdate data){ if(data.getPetShopList() == null || data.getPetShopList().size()==0){ throw PamirsException.construct(DemoExpEnumerate.PET_SHOP_BATCH_UPDATE_SHOPLIST_IS_NULL).errThrow(); } List<PetShopProxy> proxyList = data.getPetShopList(); for(PetShopProxy petShopProxy:proxyList){ petShopProxy.setDataStatus(data.getDataStatus()); } new PetShopProxy().updateBatch(proxyList); throw PamirsException.construct(DemoExpEnumerate.SYSTEM_ERROR).errThrow(); // return data; } 图4-1-8-1 修改PetShopBatchUpdateAction Step2 重启看效果进入店铺管理列表页，选择记录点击【批量更新数据状态】按钮，修改记录的数据状态为【未启用】，提交看效果。期望效果为：提示系统异常，数据修改失败图4-1-8-2 数据状态显示已启用图4-1-8-3 批量更新数据状态…

史, 昂
2024年5月23日
1.3K000
庄卓然

从2009年加入阿里至今，经历了“三淘”时期、天猫时期、双十一，到最后的all in无线手淘时期，几乎是赶上了淘系发展的所有历史性事件。在这个过程中，每一次业务的变革都催生着技术的变迁，倒逼着我们用技术的方式去解决业务问题：在存储、IO、网络等环节满足不了淘系的业务规模时，开始去IOE，最后演化成了阿里云；当业务的规模大到不能通过简单加机器的方式去做调整、当开发的规模大到所有人在一起开发会互相影响的的时候，我们开始做SOA改造，最后演化成了业务中台；在经历了几届双十一后的巨大挑战后，我们开创了里程碑式的全链路压测；在手淘时代，为了解决动态发版问题，我们植入容器概念，搭建了可动态插拔的三层架构，一年实现了500多次的发版；为了同时满足写一套代码就解决多端开发和高并发的性能问题，我们做了weex，最后还捐给了开源社区…… 每一次的业务需求推动技术进步，而技术的进步永远会超出我们的想象！同为技术宅，我在Oinone身上能清晰地感受到技术演进的脉络，企业在数字化时代，需要一个能快速上手、全面设计、灵活适应且低成本的技术工具，时代的变迁推动了Oinone的诞生。Oinone是一种全新的开发方式，在数字化时代，Oinone在提升研发效率上做出的创新性“低无一体”的设计对传统软件代码开发或者无代码开发一定会有巨大冲击，这种冲击会对软件市场格局造成什么样的变化，我拭目以待。最后，愿我们这些追光人，在时代的洪流中，都能留下一抹印迹，不辜负时代，不辜负自己。现任阿里巴巴副总裁，飞猪总裁，曾任阿里大文娱CTO兼优酷COO、淘宝CTO 庄卓然（南天）

史, 昂
Oinone 7天入门到精通 2024年5月23日
2.0K000

Please Login to Comment