比如，蚂蚁的金融业务需要和一些机构进行信息交换，由于金融领域的RPC交互常常使用标准化文件，在文件场景下如何保证可演变也是高可用设计需要关注的内容。典型的用于提高架构可用性的设计原则包括四种：解耦、冗余、异构和异步。
在数据库方面，如何解耦核心和非核心业务的DB。在业务链路方面，由于微服务具有复杂的业务场景和节点，这些业务场景和节点间如何混合，业务节点如何支撑业务链路，容量不足时哪些业务场景应优先通过，限流时应优先限流哪些业务等也是解耦需要关注的内容。总体而言，解耦原则要求将最核心的业务链路隔离出来，使其与其它业务间的耦合尽可能小。
应用程序可能有多个机房，如果多个机房间存在数据冗余，那么一个位置的错误就能够由另一个位置的数据来弥补，从而保证系统的持续可用。读写分离也是一种冗余设计，缓存和DB间存在数据冗余，当缓存宕机时，可以从DB回源到缓存。
其二，该系统的一些节点还需要支撑整个支fb的业务体系，比如会员信息节点，它需要支持成百上千个与蚂蚁森林相同体量的业务功能，对可用性的要求非常高。
在具体设计时，一个逻辑支付处理单元实际上被拆分成信息处理单元和资金处理单元。中间的T+x表示，信息处理单元和资金处理单元间可以存在一个较大的时间差。在信息受理时，即使不需要进行实际的资金流处理，也需要明确买家和卖家信息，而这些信息来自会员系统和商家系统。
理论上，这种架构设计是可以扩展的。信息流处理和业务流处理被解耦后就可以被部署在不同的节点中。比如，在国际支付时可以将信息流处理逻辑部署在支付方所在的区域中，这就使得支付操作不需要依赖原来的处理逻辑所部署的机房。需要注意的是，在将数据部署在其它机房时，通常需要一些额外的处理，比如信息安全等内容。
未来还可能实现5个9的高可用。首先，假设存在一个和蚂蚁非常类似但又异构的环境，它们之间完全是去中心化的；其次，这两个环境下的数据规则同步应该是可舍弃的，能够实现FO以及全自动的切换；另外，还需要实现监控，监控也应该是异构的，需要有一个外部系统来观测本系统的行为。
在自动驾驶汽车中使用深度学习可以帮助克服各种挑战，例如了解行人的行为，找到最短的路线以及对人和物体进行准确检测。
Cloud Native 翻译为云原生，是 Matt Stine 提出的一个概念，它是一个思想的集合，包括 DevOps 、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。
日志：把日志当作事件流
12-factor 应用本身从不考虑存储自己的输出流。不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出（stdout）事件流。开发环境中，开发人员可以通过这些数据流，实时在终端看到应用的活动。
