云原生应用以分布式系统为主，应用会被切分到多个分布式的微服务系统下，拆分一般分 为水平拆分和垂直拆分，这并不仅仅单指对数据库或者缓存的拆分，主要是表达一种分而治之 的思想和逻辑。
分布式系统的底层无法逃离“CAP 的不可能三角” (C: Consistency， 一 致 性；A: Availability， 可用性；P: Partition tolerance， 分区容忍性)。CAP 原理证明， 任何分布式 系统只可同时满足以上两点，无法三者兼顾。而分布式的服务化系统都需要满足分区容忍性， 那么必须在一致性和可用性之间进行权衡。如果网络发生异常情况，导致分布式系统中部分节 点之间的网络延迟不断增大，可能会导致分布式系统出现网络分区。复制操作可能会被延后， 如果这时我们的使用方等待复制完成再返回，则可能导致在有限时间内无法返回，就失去了可 用性；而如果使用方不等待复制完成，而在主分片写完后直接返回，则具有了可用性，但是失 去了一致性。
对金融机构而言，架构层面的高可用和业务层面的强一致性，几乎同样重要。这就需要金 融级云原生能够很好地平衡“CAP 的不可能三角”，需要尽可能兼顾业务强一致与系统高可用。
但是“一致性挑战”在分布式系统中绝不仅仅是一个数据库问题，而是一个大的话题，涵 盖分布式系统的各个层面：事务一致性、节点一致性、系统间业务一致性、消息幂等一致性、 缓存一致性、跨 IDC 一致性等等。所以也需要云原生架构有一系列技术能够应对金融级对一致 性的严苛挑战。
事务级：需要根据不同的金融场景选择合适的分布式事务模式，在平衡成本和性能后， SAGA 和 TCC 是目前金融机构比较常用的两种分布式事务模式。SAGA 模式对应用实现侵 入性更小，但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性；而 TCC 模式能做到比较好的事务隔离性，但需要应用层感知更多的复杂度。对于事务流程中部分 不需要同步返回结果的节点，为提高执行效率可采用异步消息队列实现，对于一些事务流程较 长的场景可明显降低事务实现复杂度、削峰填谷。典型场景如客户购买理财场景简化分为存款 账户扣款和理财账户入账两个步骤，如选用 SAGA 模式，存款账户成功扣款后、理财账户入账 失败，客户会看到“钱已付、货没到”的中间异常状态，需要系统进行冲正存款账户扣款来保 障事务一致性。若选用 TCC 模式，先后完成存款账户扣款、理财账户入账的逻辑处理，各自 需要存款系统和理财系统记录逻辑处理的状态，二者均成功后再发起统一提交。
数据库级：金融场景下对于数据不丢有着极致的要求，一方面需要在同城、异地多个机房 保存多个副本，另一方面需要在多个副本之间实现数据同步，保障同城 RPO 为零、异地 RPO 接近零。Paxos 算法是基于消息传递的实现分布式系统数据一致性的算法，是至今为止公认的 实现一致性的最有效的算法之一，分布式数据库通过对 Paxos 的支持来实现跨多服务器，甚 至跨多中心的数据一致性保证。
机房级：跨机房的路由能力、异常事务的跨机房恢复能力。发生机房故障时，数据库需要 能够切到同城 / 异地的副本、并保障 RPO 为零，配合应用层的交易路由切换，完成机房级容 灾切换、恢复业务。期间因机房故障导致的部分交易事务流程中断，分布式事务组件需要具备 自动恢复能力，重新启动中断的事务流程按事先设定的业务规则向前完成或向后冲正。
