由于当前公司的绝大多数应用都还是使用eureka来做服务发现,算法团队又提出一些灰度的需求。从不重复造轮子以及技术趋势的角度,自然想到是否能够将Istio整合到平台产品中。但是,据我所知,eureka2.0已经被放弃了,Istio也在早期版本中,直接废弃了对Eureka做服务发现的支持。因此,这可能需要对现有的脚手架做一定改造,这个后面具体再论。另一封面,听说istio在架构上发生了很大的变化,于是下载了1.5版本来亲自体验了一下。
TiDB架构原理
MySQL的一些集群方案和数据库中间件都在视图解决当表条目变大时,查询性能下降的问题。TiDB的设计原生适用于大规模数据量的存储和查询,重点学习了关于其计算、存储和调度的三篇文档,整理如下。
MySQL Innodb Cluster(MGR)压力测试
之前一直对腾讯TDSQL的实现原理比较感兴趣,号称使用Raft来保障数据的一致性。MySQL官方推荐使用MGR的方案来搭建高可用集群,基于Paxos的MGR毕竟是官方的解决方案,也很想知道其性能到底如何。
MySQL必须掌握的原理
整理多数据中心容灾备份的方案的时候,必然绕不过应用的持久化的备份方案。MySQL经历了这么多年的发展,对应也衍生除了很多高可用的部署架构,能够适用于两地三中心或者同城多活的场景。但是,这里我准备系统性的粗略理一遍MySQL的原理,日后再慢慢填充各部分的内容。
应用可靠性保障评估
最近整理应用可靠性保障评估建议,吸取之前做微服务的一些经验,同时也参考了许多书籍,大致整理了一些细则。分别从可靠性、高性能、伸缩性、容错和灾备、监控以及文档化的角度来评估应用是否具有高可靠保障。大致整理如下,有需要的同学,可以参考!
Redis Cluster总结
Redis是一个非常小而美的缓存中间件,官方早期没有集群方案的时候,社区采用哨兵的方式来做集群。官方在3.0版本后开始支持集群方案,但是依然需要至少6台节点,那处于对各种中间件研究的兴趣,我们就来聊聊Redis Cluster希望解决的问题,以及其实现原理。
kubeedge之EdgeSite
kubeedge默认在云端部署edgeController和deviceController,然后通过websocket/quic隧道连接云端和边缘端,通过云端一个中心来统一调度应用到特定edge node上运行。但是,就像Rancher K3S的应用场景,有些时候边缘端也希望运行一套完整的k8s集群。K3S的方案只是提供了一套精简的k8s集群,而kubeedge的edgesite模式,除了运行k8s集群之外,还提供了对IOT设备的适配和支持。
Kubeedge实现原理
可能由于各自的定位不同,K3S更像是一个kubernetes厂商的一个发行版,在边缘计算方面其实是没有摄入细节的。相比起来,kubeedge目标更明确,除了在kubernetes的方面做了各种异步通信通道,保障offline后的业务连续性之外;还定义了一系列的设备抽象,用来管理边缘设备。而且,其v1.0版本正朝着边缘端服务网格,以及函数式计算等方向发展。