和平统一微服务场景下的数据一致性解决方案

殷湘

华为PaaS微服务架构师开源能力中心

大纲

????????

? ????

?

??

起因 对比 Saga 选择

数据一致性的起因

单体应用

•单体应用由于所有模块(A/B/C)使用同一个数据库•数据一致性通过数据库事务保证

A B C

commit rollback

微服务场景

•独立进程每个微服务都在自己的进程中，采用轻量级通信协议•独立部署服务通过全自动的部署机制来进行独立部署•独立技术可用不同开发语言、数据存储技术•独立团队配备开发、测试、DBA、运维等对结果负责的全功能团队

MySQL MongoDB Cassandra

数据一致性无法完全通过数据库保证

解决方案对比

事务模式预约模式

补偿模式

事务模式 -两阶段提交(2PC)

B

C

A

Coordinator

propose

propose

propose

B

C

A

Coordinator

yes/no

yes/no

yes/no

B

C

A

Coordinator

commit/abortcommit/abortcommit/abort

B

C

A

Coordinator

ack

ack

ack

两阶段提交 (2PC)

•优点：• 事务原子性

•缺点：• 阻塞式，锁定资源• 复杂度高，难以扩展 )( 2nO

预约模式 - TCC (Try-Confirm/Cancel)

B

C

A

Coordinator

try

try

try

B

C

A

Coordinator

yes/no

yes/no

yes/no

B

C

A

Coordinator

confirm/cancelconfirm/cancelconfirm/cancel

B

C

A

Coordinator

ack

ack

ack

TCC (Try-Confirm/Cancel)•优点：• 如果在try阶段失败，服务可恢复至原状态

•缺点：• 非原子操作• 在confirm阶段失败，只能重试直至成功或采取回退措施 (人工干预)• 额外的try流程，服务需要提供额外try接口，实现额外reserved状态• 适合本来有两个处理阶段的业务

ask send cancel

Try Confirm Cancel

会议邀请

补偿模式 - Saga

B

C

A

Saga

transact

transact

transact

B

C

A

Saga

yes/no

yes/no

yes/no

恢复策略 -向前恢复

• 重试N次直到成功或采取回退措施 (人工干预)

B

C

A

Saga

transact

transact

transact

B

C

A

Sagatransact

恢复策略 -向后恢复

•补偿

B

C

A

Saga

transact

transact

transact

B

C

A

Saga

compensate

compensate

Saga

•优点：• 不需要服务提供额外接口 (通常服务有类似commit/abort接口)• 低侵入

•缺点:• 非原子操作• 对事务的补偿不一定能恢复服务至原状态

send send anotherto explain

Transact Compensate

会议邀请

Saga简介

T1T2T3C2C1

• 1987年Hector&Kenneth发表论文 Sagas• Saga=LongLiveTransaction(LLT)• LLT=T1+T2+T3+...+Tn•每个本地事务Tx有对应的补偿 Cx•已知使用saga的厂商：Microsoft/Twitter/Uber

Saga

https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

T1T2T3...TnC1C2C3...Cn

T1T2T3...Tn正常情况 异常情况

FlightStarted

SagaFlight Ended

SagaStarted

案例 –正常情况request

SagaStartedFlightStarted

Hotel Started SagaFlight Ended

案例 –正常情况request

Hotel Ended

SagaStartedFlightStarted

Hotel StartedHotel EndedCar Started

SagaFlight Ended

案例 –正常情况request

Car Ended

SagaStartedFlightStarted

Hotel StartedHotel EndedCar StartedCar Ended

Payment StartedPayment EndedSagaEnded

SagaFlight Ended

案例 –正常情况request

FlightStarted

SagaFlight Ended

SagaStarted

案例 –异常情况request

SagaStartedFlightStarted

Hotel Started SagaFlight Ended

案例 –异常情况request

Hotel Aborted

SagaStartedFlightStarted

Hotel Started SagaFlight Ended

案例 –异常情况request

Hotel AbortedFlightCompensated

SagaEnded

Compensation

复杂业务场景案例start

end

$>=1K

#<10

• How?

复杂业务场景案例start

end

$>=1K

#<10

Saga

{…"sagaChildren": [“inventory”]}

复杂业务场景案例start

end

$>=1K

#<10

Saga

{…"sagaChildren": [“none"]}

业务逻辑归属业务服务

要求

•幂等 T = T T … Tcarrentalsaga

T

T'

time

要求

•幂等 T = T T … Tcarrentalsaga

T

T'

time

C

•可交换 T C = TC T

Do NOT delete transaction records!

carrentalsaga

T

T'

time

系统架构

SagaExecutionComponent SagaSaga

SagaID:x

SagaLog

SagaStartedT1StartedT1EndedT2Startedparams

{T1:[a,b],C1:[c,d],...}

config{T1:name,path,C1:name,path,...}

TransactionViewer

Caller

1 2 3

ServiceRegistry

DynamicConfig

综合比较

两阶段提交 TCC Saga

原子性 yes no no

最差时间复杂度 𝑛" 3𝑛 2𝑛平均时间复杂度 2𝑛 2𝑛 𝑛阻塞式 yes no no

侵入性 额外接口和状态 额外接口和状态 无

事务失败恢复原状态 能恢复 第一阶段能恢复，第二阶段未必能恢复

未必能恢复

事件驱动方式

•建立在消息队列基础上，2PC/TCC/Saga的非集中式实现

CA B

requestcaller

statuspending

…

ID1…

statusnew…

ID1…

A Eventsstatuspending

…

ID1…

statusnew…

ID1…

B Eventsstatusdone…

ID1…

statusnew…

ID1…

C Events

ACreatedEvent BCreatedEvent

CA Bresponsecaller

statusdone…

ID1…

statuspublished

…

ID1…

A Eventsstatusdone…

ID1…

statuspublished

…

ID1…

B Eventsstatusdone…

ID1…

statuspublished

…

ID1…

C Events

CCompletedEventB CompletedEvent

事件驱动

•优点：• 服务自治，去中心化

•缺点：• 服务互相耦合，新增服务导致服务间事件流转变化

• 服务与分布式事务带来的应用复杂性耦合

• 额外事件表• 多语言支持需要多种实现• 服务越多，服务间事件流转越难可视化，难以定位问题

C

A B

Dchangesrequired

changesrequired

一致性方案的选择 ????????

? ????

?

??

微服务架构与领域驱动设计

• Ingeneral,microservices shouldcleanlyaligntoboundedcontexts.• if ourserviceboundariesaligntotheboundedcontexts inourdomain,andourmicroservices representthoseboundedcontexts,weareofftoanexcellentstartinensuringthatourmicroservices arelooselycoupledandstronglycohesive.

微服务：限界上下文

领域驱动设计是微服务系统架构的最佳指南

聚合与数据一致性

• Aproperly designed Aggregate is one that canbemodified inany wayrequired by the business with its invariants completely consistentwithin asingletransaction

RULE: MODELTRUEINVARIANTSINCONSISTENCYBOUNDARIES

RULE:USEEVENTUALCONSISTENCYOUTSIDETHEBOUNDARY• Any rulethat spans AGGREGATESwill not beexpected tobeup-to-dateatall times.

聚合内：强一致

跨聚合：最终一致

聚合边界：强一致边界

一致性方案选择总结•微服务：限界上下文•聚合边界：强一致边界•限界上下文 -> 1 .. N 聚合

•微服务内：聚合通过数据库事务保证强一致•微服务间：最终一致

如果需要分布式强一致，先考虑设计是否合理而非追求最新技术合理的设计能大大减少技术复杂度和商业成本

欢迎大家参加ServiceComb社区的Meetup

ServiceComb的来历

SPO Cloud 核心网

Cloud ServiceEngine

Saga

Service Center

Java ChassisRest Highway

Java ChassisRest Highway

Java ChassisRest Highway

Zipkinserver

Java ChassisRest Highway

Zuul

Java ChassisRest Highway

ServiceComb 微服务解决方案• Java Chassis: service framework• Service Center: service registry• Saga: eventual data consistency

Samples:• Company workshop

WhyServiceComb-Saga?

•和平：低侵入• 减少业务代码集成／运维难度• 剥离业务与数据一致性复杂度

•统一：集中式• 让运维监控更加简单• 可视化事务、调用链

•高可用• 无状态、可集群、可分片• Event Sourcing架构，对持久化存储无要求，可扩展以重现历史场

和平统一

未来的开发计划

•使用Akka actor模型实现异步事务执行•集成调用链追踪 (Zipkin)，定位性能瓶颈•可视化事务拓扑，定位异常最多的服务•集成熔断功能 (Hystrix)•实现基于消息队列的通信模式• ……

• https://github.com/ServiceComb/ServiceComb-Saga/issues

谢谢http://servicecomb.io

https://github.com/ServiceComb

扫码注明：“ServiceComb进群”