gydtep

异步要求将业务流程的核心部分抽象出来，使其不与非核心的内容耦合。从理论上看，核心部分越精炼，系统出错误的概率越小。比如，支付宝的支付业务背后有一百多个业务处理节点，在微服务时代，其背后可能有几百个甚至上千个业务节点，假设每个节点的可用率都是5个9，把几百个甚至几千个节点的可用率乘起来就会使得整体的可用率非常小。

gydtep

但通过移除和核心业务无关的内容，从而减小节点数量后，系统的可用率就会大幅增高。上图的左右两边从不同角度对微服务的高可用设计进行了分析。左边是微服务设计应具有的能力，右边是设计高可用微服务架构时应遵循的原则。

gydtep

另外，有三块内容实际支撑着一个微服务系统：代码、配置和数据。其中，代码和配置是相辅相成的，代码执行的间歇可能需要修改系统配置；业务数据也非常重要。对这三块内容进行分析是微服务架构高可用设计的重要方面。

gydtep

如果此时将FO库作为主库继续进行修改，那么最终得到的数据必然不是用户所预期的。一个处理方式是将持续往黑名单库里写差异。当主库宕机时，首先将FO库拉起来，此时，这些差异可能使得FO库中某一部分数据是禁写的。

gydtep

对用户信息这样的业务而言，每天只有很少的数据会发生更改，并且用户信息发生宕机的概率很低，因此这种处理带来的禁写对业务的影响非常小。通过这种方式强一致地写黑名单库，能够近似地实现无损的容灾设计。回切数据库时也是如此。由于FO库已经有很多新的数据内容，因此在回切数据库时需要将这部分数据merge回主库中。

gydtep

即使在云原生时代，一个业务场景的高可用架构设计也仍然需要许多操作来共同实现。未来，这些与业务无关的设计可能被组件化地沉淀下来，成为基础设施。

gydtep

高可用设计通常是静态的，它能够被内嵌到架构设计中，被内嵌到基础设施或者中间件中。高可用设计应根据业务场景实现个性化设计。这要求我们不仅需要关注系统当下的业务特点，还需要预测其未来的业务特点，通过各种特性来刻画该业务对用户的可用性影响。这就需要结合各种原子手段以实现业务在当前阶段所需要的高可用能力。未来，可能存在非常智能的系统，能够使用最低成本刻画业务的当前特征，然后自动化地组合一些原子高可用能力最大化系统高可用能力。

gydtep

未来还可能实现5个9的高可用。首先，假设存在一个和蚂蚁非常类似但又异构的环境，它们之间完全是去中心化的；其次，这两个环境下的数据规则同步应该是可舍弃的，能够实现FO以及全自动的切换；另外，还需要实现监控，监控也应该是异构的，需要有一个外部系统来观测本系统的行为。

gydtep

前端智能化算法工程体系升级，引入云原生能力使智能化算法框架 Pipcook 可以从数据侧、模型侧、训练侧、部署侧支持云原生，能够更便捷的融入云原生体系，保障使用者可以直接上线模型算法支撑业务，打通业务的全链路。

gydtep

P2C 业务研发平台打造：需求暨代码、需求暨生产、协作在线化的全新业务研发模式。打通需求、设计、研发的全链路，保证信息流转的完整性、迅捷性、连贯性，确保最终交付物和需求的结构化信息的一致性，需求迭代的数据化驱动。