YTS文档
一致性框架(YTS)设计文档-评审-new
技术了解
分布式事务
本质上来说,分布式事务就是为了保证不同数据库的数据一致性。
认识打桩
什么是桩
桩,或称桩代码,是指用来代替关联代码或者未实现代码的代码。如果函数B用B1来代替,那么,B称为原函数,B1称为桩函数。打桩就是编写或生成桩代码。
打桩的目的主要有:隔离、补齐、控制。
隔离是指将测试任务从产品项目中分离出来,使之能够独立编译、链接,并独立运行。隔离的基本方法就是打桩,将测试任务之外的,并且与测试任务相关的代码,用桩来代替,从而实现分离测试任务。例如函数A调用了函数B,函数B又调用了函数C和D,如果函数B用桩来代替,函数A就可以完全割断与函数C和D的关系。
补齐是指用桩来代替未实现的代码,例如,函数A调用了函数B,而函数B由其他程序员编写,且未实现,那么,可以用桩来代替函数B,使函数A能够运行并测试。补齐在并行开发中很常用。
控制是指在测试时,人为设定相关代码的行为,使之符合测试需求。例如:
1 | externint B(); |
如果函数B返回随机数,或者返回网络状态,或者返回环境温度,等等,则当调用其实际代码时,函数A很难测试,这时可以用桩函数B1来代替B,使其返回测试所需要的数据。
Spring事务了解
https://blog.csdn.net/java123456111/article/details/124946361
事务、事务特性、
编程式事务管理TransactionTemplate、TransactionManager
声明式事务管理
通过 AOP 实现(基于@Transactional 的全注解方式使用最多)
1
2
3
4
5
6
7
8
public void aMethod {
//do something
B b = new B();
C c = new C();
b.bMethod();
c.cMethod();
}
- 2023/1/4,阅读未完成,1/5继续阅读
消息队列
消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ
异步处理
引入消息队列,将不是必须的业务逻辑,异步处理。
应用解耦
流量削峰
Iris
Iris是一款Go语言中用来开发web应用的框架,该框架支持编写一次并在任何地方以最小的机器功率运行,如Android、ios、Linux和Windows等。该框架只需要一个可执行的服务就可以在平台上运行了。
Iris框架以简单而强大的api而被开发者所熟悉。iris除了为开发者提供非常简单的访问方式外,还同样支持MVC。另外,用iris构建微服务也很容易。
在iris框架的官方网站上,被称为速度最快的Go后端开发框架。在Iris的网站文档上,列出了该框架具备的一些特点和框架特性,列举如下:
1)聚焦高性能
2)健壮的静态路由支持和通配符子域名支持
3)视图系统支持超过5以上模板
4)支持定制事件的高可扩展性Websocket API
5)带有GC, 内存 & redis 提供支持的会话
6)方便的中间件和插件
7)完整 REST API
8)能定制 HTTP 错误
9)源码改变后自动加载
Dubbo
了解iuap
iuap聚焦PaaS、支撑SaaS、适配多种IaaS,遵循开放、开源、生态的发展原则,为企业提供互联网开发、测试、构造、发布、部署、云运维、云运营、云集成等各种平台技术能力,支撑企业构建高并发、高性能、高可用、安全的C2B、O2O、B2B 或B2B2C 等企业互联网应用或服务。
HttpClient
文档阅读
认知
本框架目前针对YonSuite(后续支持采购、财务、人力、协同等各领域云)如何保障各个微服务之间的数据一致性考虑
框架和iuap平台下的MDD、MDF及RPC结合,结合本地数据库事务提交机制,目前支持Mysql。后续逐步支持单纯RPC方式或者HTTP client方式。
技术中台的云端,提供事务监控中心,监控和查看未及时完成的及未正确结束的长事务,支持云端查看错误堆栈、链路拓扑图、下发重试命令等功能。
名词解释
功能架构
技术架构设计
需要再深入了解下事务协调器、事务管理器、运行时(TCC的try、confirm、cancel
核心类和枚举
逻辑架构设计
核心业务场景
- 销售出库信息回写(MDD)
- 财务支付业务凭证(RPC)
- 生态应用调用用友云开放服务(HTTP)
领域概念模型
- BASE理论模型
通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态
基于此的分布式一致性解决方案
- Sagas模式
- TCC模式
- 异步Sagas模式
- 基于MQ的可靠消息模式
技术支撑设计
基于Spring的DB事务回调
分布式事务LOG及状态转换
- Sagas正向操作的状态扭转
- Tcc模式正向操作(Try)状态扭转
- Tcc模式确认(Confirm)操作状态扭转
- TCC,Sagas模式事务异常cancel操作的状态扭转
序列化机制
RPC调用上下文序列化采用Hession协议的二进制协议,hession在上下文包含java枚举以及泛型操作时能够正确处理。在RPC调用前,YTS的sdk将RPC调用的上下文信息,持久化到TransactionRel的数据表中,在确认(Confirm),回滚(Cancel)时从TransactionRel表中反序列化为RPC调用上下文进行RPC的调用。
统一监控设计
定时扫描数据任务
核心场景及流程
- MDD框架正向业务调用
- 正向调用报错后的业务回滚
- 回滚报错后的错误信息上报
- 云端重试命令的下发及执行
- 分支事务嵌套链式长事务的协调执行
- 分支事务嵌套链式长事务的逐级回滚
MDD(模型驱动开发)
传统的瀑布式开发流程如下图,每一个需求的产生都需要进行需求分析、设计、编码、测试等一系列流程。
模型驱动框架的开发流程如下图:
模型驱动的优势在于不用为每个需求定制化的编码,而是通过高度抽象化的模型映射到具体的业务元数据上来实现需求功能;这样大大减少了编码的重复工作,同时也提高了软件的可变更性。
模型驱动架构(MDA,Model Driven Architecture)
MDA的三大目标:轻便可移植性、互操作性和可重用性,采用了模型和技术分离的架构设计。
使用一定的建模标准(UML、MOF、XMI等)构建描述应用程序或集成系统的业务功能和行为的模型,这些模型独立于具体平台并且和实现具体业务功能和行为的特定技术代码分离,从而实现了业务和应用程序逻辑与底层平台技术的分离,这种分离也带来了应用程序的核心与技术变化周期的隔离。系统的业务部分和技术部分都可以各自进化而互不影响 - 业务逻辑响应业务需求,技术部分按业务需要利用新的技术开发。
上图为MDA 结构示意图。最左侧为OMG提出的架构理论,其次是 MDA 的核心技术:MOF ( Meta Object Facility ,元对象设施)、 CWM (Common Warehouse Metamodel ,公共数据仓库元模型)和 UML . MDA 的主要工作就是要把基于这些技术建立的PIM 转换到不同的中间件平台上,得到对应的 PSM .PSM中给出的是目前主要针对的实现平台:CORBA 、 XML 、JAVA 、 Web Services 和 .NET .显然,随着技术的发展,这个列表将不断扩充。最后是基于PSM平台相关模型在公共服务及垂直领域等组件或应用中进行模型驱动开发。
领域驱动设计/模型驱动设计(DDD,Domain-Driven Design)
DDD是由Eric Evans最先提出,目的是对软件所涉及到的领域进行建模,以应对系统规模过大时引起的软件复杂性的问题。整个过程大概是这样的,开发团队和领域专家一起通过通用语言(Ubiquitous Language)去理解和消化领域知识,从领域知识中提取和划分为一个一个的子领域(核心子域,通用子域,支撑子域),并在子领域上建立模型,再重复以上步骤,这样周而复始,构建出一套符合当前领域的模型。
建模的过程是由不同阶段的成员来完成,有些模型之间有引用关系,应用软件通过所有人的建模工作而构建起来。
模型驱动开发(MDD, Model Driven Development)
模型驱动开发框架(MDF, MDD Framework)
MDF 实际上就是一套开发框架,可以是基于spring、spring boot 等技术开发框架搭建的脚手架,承载了模型驱动相关的设计、开发方法等的编码框架。
MDA环境下的系统开发方式就是在开发活动中通过创建各种模型精确描述不同的问题域,并利用模型转换来驱动包括分析、设计和实现等在内的整个软件开发过程。
不难看出MDA说的是整体的软件架构设计使用的是模型驱动;而在软件开发的过程中,对不同领域的业务需求进行分析、抽象建模和技术框架分层所常用的分析方法就是DDD;整个软件的开发活动就称之为MDD。
MDA架构设计中,MDA需要从需求采集和理解业务需求开始;PIM和PSM可以由不同团队完成,独立工作,但是组合后能产生健壮的业务解决方案;整个流程中模型转化和相关模型的驱动引擎是核心。
接下来重点了解一下我们的MDD的脚手架(MDF)都做了什么?
在脚手架中主要的是通过元数据SDK、规则SDK、UI元数据SDK和其他相关支持工具包完成对整体的模型驱动开发支持的。其中元数据SDK包含业务元数据的建模、数据查询等相关功能;UI元数据SDK包含了UI模板定义查询相关功能,搭配Node的前端驱动项目进行UI模板的渲染和组件的过滤展示等;而规则SDK包含了对于业务数据CRUD的默认规则、编码规则、唯一性校验规则、参照查询规则以及卡片翻页等默认规则。接下来让通过一个更完整的图来看MDD开发脚手架。
首先,需求输出到开发阶段,根据需求设计抽取定义业务元数据,及页面设计的UI元数据。
其次,业务元数据通过XML或统一中央元数据仓库的形式加载到脚手架项目启动中。
再次,浏览器访问node前端,node前端路由请求到java后端Controller.
最后,后端处理逻辑在规则执行引擎中执行相应的规则,分别查询UI元数据用于页面渲染,以及业务数据的查询。并将结果返回给node前端做渲染展示。
目前脚手架功能中部分扩展功能上图没有体现,这些扩展功能包括:
a. UI元数据查询逻辑通过规则引擎查询,可通过增加前置或后置规则进行功能扩展;UI元数据支持远程获取;
b. Redis 是否使用可通过开关配置。并支持单机模式,哨兵模式,集群模式配置;
c. MySQL数据库支持规则、UI元数据和业务数据区分不同的数据源存储;
d. 支持Ali OSS 存储;
e. 支持基于ES的参照及翻译;
f. 接入统一三方包管理和统一异常及日志;
g. 支持MySQL、Redis、应用基本信息、环境信息等的健康检查与监控;
以上就是MDD的基本实现原理和功能描述,整体看上去还是很简单清晰的。
总结展望
下面通过下图表达一下模型驱动开发的优势
继续阅读:https://blog.csdn.net/weixin_43145299/article/details/122623568