SOFA Weekly | 每周精选【11/04 - 11/08】

2019-11-08 · SOFA 团队 ·

SOFA WEEKLY | 每周精选,筛选每周精华问答

同步开源进展,欢迎留言互动

weekly.jpg

SOFAStack(Scalable Open Financial Architecture Stack)是蚂蚁金服自主研发的金融级分布式架构,包含了构建金融级云原生架构所需的各个组件,包括微服务研发框架,RPC 框架,服务注册中心,分布式定时任务,限流/熔断框架,动态配置推送,分布式链路追踪,Metrics 监控度量,分布式高可用消息队列,分布式事务框架,分布式数据库代理层等组件,也是在金融场景里锤炼出来的最佳实践。

SOFAStack 官网:https://www.sofastack.tech

SOFAStack:https://github.com/sofastack

每周读者问答提炼

欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 ” SOFA WEEKLY “ 的形式回复

@温明磊 提问: > 出参入参都放在 Saga 的上下文中,如果参数内容较多较大,业务量又大的话,对内存有限制吗?

A: 没有做限制,建议无关的参数不要放到上下文。下一个服务需要用的参数、或用于分支判断的参数可以放入上下文。

确认个事情:每个节点,要么自己方法内部 Catch 异常处理,使最终有返回信息。要么自己内部可以不处理,交由状态机引擎捕获异常,在 json 中定义 Catch 属性。 而不是补偿节点能够自动触发补偿,需要补偿必须手动在 json,由 Catch 或者 Choices 属性路由到 CompensationTrigger。

A:对的,这个是为了提高灵活性。用户可以自己控制是否进行回滚,因为并不是所有异常都要回滚,可能有一些自定义处理手段。

所以 Catch 和 Choices 可以随便路由到想要的 state 对吧?

A:是的。这种自定义出发补偿的设计是参考了 bpmn2.0 的。

还有关于 json 文件,我打算一条流程,就定义一个 json,虽然有的流程很像,用 Choices,可以解决。但是感觉 json 还是要尽量简单。这样考虑对吗?

A:你可以考虑用子状态机来复用,子状态机会多生成一行 stateMachineInstance 记录,但对性能影响应该不大。

Service Mesh 相关阅读

活动推荐

image.png

2019 年度 TOP100 全球软件案例研究峰会即将举行,蚂蚁金服也受邀参与本次案例分享。

Service Mesh 是蚂蚁金服下一代架构的核心,本主题主要分享在蚂蚁金服当前的体量下,我们如何做到在奔跑的火车上换轮子,将现有的 SOA 体系快速演进至 Service Mesh 架构。RPC、消息、DB、安全、运维等每一个环节均充满挑战。本次实战分享蚂蚁金服双十一核心应用如何大规模落地 Service Mesh 架构并降低大促成本。

主题:《蚂蚁金服 Service Mesh 双十一实战

嘉宾:石建伟,花名:卓与,蚂蚁金服中间件技术专家,主要负责蚂蚁金服服务注册中心、配置中心与 Service Mesh 的研发与架构。当前专注在蚂蚁金服 Service Mesh 内部落地。

时间:2019 年 11 月 15 日(周五)16:50-17:50

地点:北京国际会议中心

报名方式:点击“这里”即可锁定席位