Quick Notes

由于当前公司的绝大多数应用都还是使用eureka来做服务发现，算法团队又提出一些灰度的需求。从不重复造轮子以及技术趋势的角度，自然想到是否能够将Istio整合到平台产品中。但是，据我所知，eureka2.0已经被放弃了，Istio也在早期版本中，直接废弃了对Eureka做服务发现的支持。因此，这可能需要对现有的脚手架做一定改造，这个后面具体再论。另一封面，听说istio在架构上发生了很大的变化，于是下载了1.5版本来亲自体验了一下。

MySQL的一些集群方案和数据库中间件都在视图解决当表条目变大时，查询性能下降的问题。TiDB的设计原生适用于大规模数据量的存储和查询，重点学习了关于其计算、存储和调度的三篇文档，整理如下。

之前一直对腾讯TDSQL的实现原理比较感兴趣，号称使用Raft来保障数据的一致性。MySQL官方推荐使用MGR的方案来搭建高可用集群，基于Paxos的MGR毕竟是官方的解决方案，也很想知道其性能到底如何。

整理多数据中心容灾备份的方案的时候，必然绕不过应用的持久化的备份方案。MySQL经历了这么多年的发展，对应也衍生除了很多高可用的部署架构，能够适用于两地三中心或者同城多活的场景。但是，这里我准备系统性的粗略理一遍MySQL的原理，日后再慢慢填充各部分的内容。

最近整理应用可靠性保障评估建议，吸取之前做微服务的一些经验，同时也参考了许多书籍，大致整理了一些细则。分别从可靠性、高性能、伸缩性、容错和灾备、监控以及文档化的角度来评估应用是否具有高可靠保障。大致整理如下，有需要的同学，可以参考！

分布式系统的一致性是特别伤脑筋的事情，当然也可以使用一些现成的协议，比如Raft之类的。今天我们准备来聊下两阶段提交（2PC）和三阶段提交（3PC），以及它们之间的关系。

Redis是一个非常小而美的缓存中间件，官方早期没有集群方案的时候，社区采用哨兵的方式来做集群。官方在3.0版本后开始支持集群方案，但是依然需要至少6台节点，那处于对各种中间件研究的兴趣，我们就来聊聊Redis Cluster希望解决的问题，以及其实现原理。

头阵子基于kubebuilder实现了一套用于大数据交换平台底层调度的operator。在过程中遇到一些坑，平时学习的时候不太容易注意到的点，简单记录一下。

kubeedge默认在云端部署edgeController和deviceController，然后通过websocket/quic隧道连接云端和边缘端，通过云端一个中心来统一调度应用到特定edge node上运行。但是，就像Rancher K3S的应用场景，有些时候边缘端也希望运行一套完整的k8s集群。K3S的方案只是提供了一套精简的k8s集群，而kubeedge的edgesite模式，除了运行k8s集群之外，还提供了对IOT设备的适配和支持。

可能由于各自的定位不同，K3S更像是一个kubernetes厂商的一个发行版，在边缘计算方面其实是没有摄入细节的。相比起来，kubeedge目标更明确，除了在kubernetes的方面做了各种异步通信通道，保障offline后的业务连续性之外；还定义了一系列的设备抽象，用来管理边缘设备。而且，其v1.0版本正朝着边缘端服务网格，以及函数式计算等方向发展。