![](https://img-blog.csdnimg.cn/20201014180756925.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
架构相关
文章平均质量分 80
小屋子大侠
这个作者很懒,什么都没留下…
展开
-
pika主从同步原理
pika主从同步主要为了分析探索一下pika是如何实现主从同步的,pika的主从同步的原理与redis的同步方案还不相同,本文主要是为了分析其主从同步的相关流程(pika基于3.4版本)。pika主从同步原理主从同步的原理,主要是通过在启动的时候启动了两部分的线程来进行的。auxiliary_thread线程pika_rm中的pika_repl_client线程池和pika_repl_server线程池先逐个分析一下两个部分线程的工作的流程。auxiliary_thread线程在pika原创 2022-04-01 15:05:12 · 1301 阅读 · 0 评论 -
flannel原理初探针对0.1.0版本
flannelflannel是针对k8s设计的三层的网络解决方案。在k8s中为了使pod之间能够使用一种偏平的网络架构,从而完成跨Pod的网络通信。官网给的原理图如下:flannel 使用TUN/TAP 设备,并使用 UDP 创建覆盖网络来封装 IP 数据包。 子网分配是在 etcd 的帮助下完成的,它维护覆盖到实际 IP 的映射。从以上的原理图也可知大概的流程是是怎么操作的。其中具体是一个什么流程呢,本文就根据flannel的0.1.0版本的源码进一步学习。flannel流程-基于Backen原创 2021-11-11 10:57:52 · 692 阅读 · 0 评论 -
pika-NoSQL原理概述
pikapika是一款基于rocksdb可持久化兼容redis协议的kv存储。当前最新的特性中还支持codis,可作为codis的后端存储使用,但是运维命令稍微有些不同。pika相对于redis而言主要是适合在容量大的场景下,简化了数据加载和迁移的相关操作,但是整体基于硬盘或者SSD的存储响应性能可能会差些。不过本文只是简单的来了解一下pika的设计的思路,方便以后在使用过程中加快对问题的诊断。pika设计pika在设计的时候支持了两种运行模式,即经典模式和分布式模式。模式原理经原创 2021-10-27 17:39:44 · 1180 阅读 · 1 评论 -
gossip协议与memberlist实现
gossip协议gossip协议是基于流行病传播传播方式的节点或者进程之间信息交换的协议。主要在分布式系统中使用gossip协议来达到数据的最终一致性,利用一种随机的方式将信息传播到整个网络中,并在一定时间之后完成数据的最终一致性,并且该算法时一种去中心化的算法,当前应用较多的为redis,consul等分布式组件中。优点扩展性较好,节点的加入和退出都可以无损有序,对应用优化。容错性较好,任何节点的宕机都不会影响正在运行的节点。健壮性较好,因为没有中心化的节点,所有对象都是对等。最终一致性,当原创 2021-09-22 10:59:14 · 1621 阅读 · 0 评论 -
反应器(Reactor)模式-golang探索
反应器模式在以前的博文模式设计概述:反应器(Reactor)模式介绍过相关的概念和流程,当时使用了python但是从结果上来看并没有起到很明显的效果。最近在接受有关proxy的项目中,刚刚好涉及到有关性能的问题,故本文探索一下go的反应器模式的探索过程,当前比较知名的项目有两个一个是evio和gnet,都是反应器模式的很好的实现范例,特别是gnet在反应器模式上还加入了协程池从而比evio性能更好,本文就从头开始探索如何一步步优化改进。go原生服务流程package mainimport ( "原创 2021-06-29 16:06:47 · 2027 阅读 · 1 评论 -
k8s概念入门之kube-proxy-针对1.1版本阅读
背景在后续阅读k8s0.4版本的过程中,发现文档上描述的确实是一个不完整的版本,故切换版本到1.1,因为在1.1文档中已经标明了可以在生成环境中使用,故重新再学习一下有关kube-proxy的内容,本文主要是做一个补充。kube-proxy功能还是以前那样通过部署在每个node节点上面,来提给service层面和node层面的通信支持。其主要的功能内容就是通过iptables来进行网络的联通与路由功能。proxy通过master提供的api直接获取对应的endpoints和services,通过定原创 2021-04-16 17:33:25 · 352 阅读 · 0 评论 -
k8s概念入门之kube-proxy-针对早期(0.4)版本阅读
k8s的kube-proxy分析Kube-proxy主要是伴随着kubtlet进程一起部署在每个node节点中,proxy的功能主要就是为了完成在k8s集群中实现集群内部的通信,也可完成集群外的数据到集群内部的通信。从功能上来说确实是完成了完成更高层次的网络封装,让用户能够忽略网络层的部分细节从而专注于业务层的功能。在早期的k8s的实现中,使用了最简单快速的方式来实现流量的转发,即通过用户态的数据接受直接转发到后端的目标地址上去。首先查看proxy的main函数:var ( etcdServerL原创 2021-04-09 11:13:15 · 443 阅读 · 0 评论 -
k8s概念入门之apiserver-针对1.1.版本阅读
apiserverk8s中最重要的一个通信节点就是apiserver,是一个中心节点连接着每一环,是kubelet,kube-proxy和control-manager的交互的中心点,提供基于API服务来管理每一步的流程,后端采用高可用的etcd等组件作为数据库来提供数据的高可用。从介绍来看,apiserver的整个架构也基于上基于传统的http服务端来实现,这对外可提供友好的接口进行二次开发。apiserver流程func main() { runtime.GOMAXPROCS(runtime.N原创 2021-05-13 19:41:00 · 614 阅读 · 0 评论 -
k8s概念入门之control-manager-针对1.1.版本阅读
control-manager资源控制器主要是为了控制各种资源的变更信息,例如pod的创建新增,副本控制器和账户控制器等信息,资源控制器的主要职责就是通过list-watch机制,从APIServer处获取所有的操作,从而将资源的操作依次解耦,通过不同的事件来驱动整个k8s的步骤。最容易理解的一张图(该图摘自于网络)如下所示;[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WJOtxeiq-1620452706803)(/Users/wuzi/Desktop/屏幕快照 20原创 2021-05-08 13:45:32 · 906 阅读 · 0 评论 -
k8s概念入门之kubelet-针对1.1.版本阅读
kubeletkubelet是在每个节点上运行的主要“节点代理”。它可以使用以下之一向apiserver注册该节点:主机名;用于覆盖主机名的标志;或云提供商的特定逻辑。kubelet根据PodSpec起作用。 PodSpec是一个描述Pod的YAML或JSON对象。 kubelet接收通过各种机制(主要是通过apiserver)提供的PodSpec集合,并确保这些PodSpec中描述的容器正在运行且运行状况良好。 Kubelet不管理不是Kubernetes创建的容器。kubelet流程kubele原创 2021-04-21 14:11:41 · 392 阅读 · 0 评论 -
codis3.2升级redis3.11到redis6.0.10调研
codis升级redis3.11到redis6.0.10背景当前codis最新版本为3.2对应的redis的版本为3.2.11,针对以往的redis在使用过程中当内存碎片率过高时只能重启节点,无法动态释放故调研升级到redis6版本。codis调研从codis的架构可以知道,codis中的jodis-client(通过zk)或者redis-client直连的方式来访问codis-proxy,codis-proxy通过计算对应的key的slot来转发到对应的codis-group中去,这样完成一个完整原创 2021-03-26 16:16:08 · 1006 阅读 · 2 评论 -
ServiceMesh有关sidecar理解
理解sidecar的功能特性在前文中分享了有关ServiceMesh的大概的一个演进过程,该过程都是大家对于服务管理与规划的解决方案。本文主要是通过简单的代码的编写来更加体会sidecar相关的功能与优缺点。sidecar的功能点sidecar实现的过程中,主要包含了sidecar与sidecar的通信,sidecar对应用流量的管控,对于不同的应用的限流、熔断等策略的实现。主要架构图如下;大致功能流程如上所示,将以往在应用程序A或B中实现的服务发现、应用限流等功能都集成在了sidecar中,后续原创 2021-01-30 22:15:44 · 807 阅读 · 0 评论 -
ServiceMesh架构的演变过程概述
ServiceMesh概述在软件体系结构中,服务网格是专用的基础结构层,用于通常使用Sidecar代理来促进微服务之间的服务之间通信。具有这样一个专用的通信层可以提供许多好处,例如,提供对通信的可观察性,提供安全的连接,或针对失败的请求自动进行重试和后退。以上为维基百科对于服务网格的解释,服务网格基于当前的微服务的进一步的发展演进,其实本质上服务发现、服务熔断等内容仍然是服务网格的核心内容,但是服务网格进一步抽象提炼了微服务中的公共组件的功能,并添加了对于这些公共的基础组件的管理能力,从而达到了对微服原创 2020-12-31 16:57:01 · 365 阅读 · 0 评论 -
分布式集群任务调度概述
分布式集群任务调度在以往单机的任务执行中,任务都在一台机器上执行,所有任务都需要有序排队等待执行,多个任务执行的时间大致为每个任务在单机上执行的时间。但是当执行任务的机器数量变多之后,就需要将任务有序合理的分配到不同的机器上去执行,这也催生了一些分布式集群中任务调度的算法。集群任务调度算法当前较为主流的经典算法有如下两个,Min-Min算法和Max-Min算法,这两种算法计算过程相对简单并且不复杂,但是缺点也很明显就是对任务的负载均衡,长短任务的分配效果会差点。Min-Min算法1.假设网格任务集原创 2020-12-24 15:12:01 · 2282 阅读 · 2 评论 -
应用层网关调研与基础测试
背景故事的开始还是源于现阶段各个平台之间有些许的接口调用,但是各个平台之间又相对比较独立,并没有将各个平台整合成一组微服务的需求。现在面临的问题就是各个平台直接都有互相调用的需求,如果各个平台有业务升级的情况下,不一定能察觉到是否会影响到对提供给其他系统使用的API,而且还有一个问题就是大家好像都不是太清楚哪些平台调用了哪些接口,某个平台对外提供了哪些接口,而且在一些脚本使用的过程中如果部署的系统迁移而需要重新修改访问的地址,基于这些原因考虑搭建一个openapi相关的服务,主要是来管理与监控各个调用链,原创 2020-06-10 18:12:27 · 579 阅读 · 0 评论 -
微服务初步理解
本文参考书籍https://github.com/oopsguy/microservices-from-design-to-deployment-chinese微服务简介单体应用在项目开发启动阶段,比如开发一个电商系统,该系统包括了订单模块、商品搜索模块、用户模块和后台等系统,启动阶段虽然按照业务逻辑分模块开发,但是最终成功上线运行的是一个单体应用,在项目开发的初期,单应...原创 2018-08-04 12:06:12 · 274 阅读 · 0 评论