应用通过容器部署由K8S调度，对于此类应用的业务连续性要求实现同城双活，异地容灾，需要考虑哪些方面？

非常赞同之前郭经理的回复，其中概括了很多非常重要的最佳实践逻辑。这里再补充几点。

1、Kubernetes 应用体系的可靠性是靠可重复部署的描述文件来保障的，由于所有的部署都可以通过yaml所描述的完成整过程快速复现，因此Kubernetes体系可以实现快速、灵活的业务部署与分布。这也是为什么很长一段时间以来我们在Kuberenetes平台上都不提及数据的一个主要原因。Kubernetes 设计最初是根本不考虑数据的。而真实业务中我们又无法脱离数据。因此之前我们的可靠性保障理论中、微服务理论中，都是通过高速构建就近数据源，完成快速局部数据供应来实现微服务的数据单元化的。当然这不可能解决所有问题，因此我们后来有了 Stateful set。

2、 Stateful Set 的核心意义就在于将存储与计算容器捆绑统一调度。但Stateful Set保障的是计算与存储的同步，并不保障存储的可用，因此 OpenShift 推出了 OpenShift Container Storage （OCS产品）来协助解决这个问题。软定义存储的多副本、备份恢复等手段可以结合Kubernetes来保障业务的连续性要求。但我们仍然面临核心数据的连续性服务能力要求，因为微服务理论中，每个服务的数据都是整体数据模型的小局部供应模型。最终一致性还在核心数据模型上。

3、因此在今天分享的内容中多处提到了如何实现局部小数据模型如何与核心数据模型的同步与快速供应方案。这部分方案其实就是我们现在关注的数据中台，通过隔离局部数据逻辑与核心数据模型，我们通常要分拆成部分核心数据模型的子集，用于面向部分具有共性数据需求的业务上，这部分能力就是数据中台。数据中台相当于过去中间件的数据库连接池，而差别在于，数据中台具备缓存、同步、传递交易等能力。这部分能力需要借助一些工具来实现。Redhat AMQ Streams （Kafka 中台），Redhat Data Grid（Memcahe/分布式数据网格/NoSQL内存库 中泰），RedHat Data Virtulization（数据视图中台）都是这类工具可以有效隔离业务与数据逻辑，并可以借助一些微服务概念，通过蓝绿部署，金丝雀部署等方式，屏蔽数据底层核心逻辑，实现无感知化化面向应急数据源或灾备数据源的目的。从而强化容器化PaaS平台的必须服务能力。

4、通过Redhat Change Data Capture 这样的技术可以实现复杂/异构/异地/差异逻辑的多数据源同步，从而协助用户实现同城双活、异地双活、异地容灾等需求的实现。但这种方案并不能从逻辑上彻底解决最终数据一致性问题。最终数据一致性仍然需要人为逻辑设定来参与保障。

5、结合另一个问题的回答 “ 在大数据平台容器化基础上如何考虑数据安全？ ” 在这也抛出一个个人观点供大家参考与讨论。随着数据使用平台的容器化、分布化、敏态化，数据的安全性，唯一权威性与最终一致性的保障将变得越来越复杂。区块链的技术在性能上还不成熟，但在溯源与权威性保障上有独到的优势。因此可以考虑通过区块链技术来实现未来全局数据体系的最终一致性保障。当然实现途径仍然有待论证。