gydtep

前面提到了由于DTS支持的并不是很完善，所以我基于DRC（一个阿里内部数据订阅组件，类似canal）自己实现了数据同步的能力，下面介绍一下实现一致性的过程，中间也走了一些弯路。

gydtep

同时单机消费的第二个问题就是单点。所以我们要实现Failover。这里我们采用Raft协议进行多机选主以及对主的请求。当单机挂掉之后，其余的机器会自动选出新的Leader执行同步任务。

gydtep

delete

delete也是天然满足结合律的，而无论之前都有什么操作，只要执行就好了。

在insert和update操作里面，都有一个转换的过程，而这里有个前提，那就是从DRC拿到的变更数据每一条都是全字段的。可能有人会说这里的转换可以用replace into替换，为什么没有使用replace into呢，首先由于顺序错乱的情况毕竟是少数，而且我们并不单纯复制数据，同时也是在复制操作，而对于DRC来说，replace into操作会被解析为update或insert。这样无法保证消息唯一性，也无法做到防循环广播，所以并不推荐。我们看看下面的流程图也许会更清晰些：

gydtep

根据上面的介绍，我们来看下多中心容灾架构的形态，这里用了两级调度来保证中心封闭，同时利用自研的同步组件进行多中心双向同步。我们还可以制定一些快恢策略，例如快速摘掉一个中心。同时还有一些细节需要考虑，例如在摘掉一个中心的过程中，在摘掉的中心数据还没有同步到其他中心的过程中，应该禁掉写操作，防止短时间出现双写的情况，由于我们同步的时间都是毫秒级的，所以影响很小。

gydtep

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”

gydtep

可编程的、动态的、弹性基础设施：支持公共云、专有云、边缘计算等不同环境。
分布式应用架构：具备松耦合、可弹性扩展、高容错性等特点。

gydtep

容器镜像迅速成为了应用分发的工业标准。随后 Google 开源的 Kubernetes 因为其优秀的开放性、可扩展性和活跃的社区，在容器编排之战中脱颖而出，成为分布式资源调度和自动化运维的事实标准。Kubernetes 屏蔽了底层基础架构的差异，提供了良好的可移植性，可以帮助应用一致地运行在不同的环境，包括数据中心、云、边缘计算等。

gydtep

随后 Google 开源的 Kubernetes 因为其优秀的开放性、可扩展性和活跃的社区，在容器编排之战中脱颖而出，成为分布式资源调度和自动化运维的事实标准。Kubernetes 屏蔽了底层基础架构的差异，提供了良好的可移植性，可以帮助应用一致地运行在不同的环境，包括数据中心、云、边缘计算等。

gydtep

在技术上，容器技术彻底解耦了应用和运行时环境，可以帮助应用更加快速平滑地迁云；容器轻量化、自包含的特性极大简化了应用弹性，释放云的核心价值。此外，容器技术的标准化促进生态的分工和协同。

gydtep

基于 Kubernetes，社区开始构建上层的业务抽象。比如，服务网格 Istio、机器学习平台 Kubeflow 以及无服务器应用框架 Knative 等等。