Elasticsearch大文本字段(large text field)优化方案

在全文检索的场景下,经常会有text类型的字段存储的数据量比较大,比如一个pdf文档或者是一本书的内容,可能会有几兆,几十兆,上百兆的大小,单个字段的内容过大,会对集群性能以及稳定性造成比较大的影响,因此本文档针对该场景给出优化建议。

UMI框架解析

阿里开源的umi就是这样基于react的框架,它把涉及到前端开发的几乎所有方面都纳入到这个框架的管理范围内,比如路由、打包、国际化、状态管理、依赖管理等等,有了统一的标准,就可以让团队协作开发变得高效顺畅,由于它包罗万象,因此它的实现方式也很有特点,即全插件化,一个个功能都是通过插件来实现的,即使是umi最核心的功能也是通过插件实现的,开发人员也可以开发自己的插件,去满足特定需求。这套框架实现的相当不错,对我这种新手来说,简直就是福音,可以直接继承大厂的开发经验,使用上最前沿的开发技术,以最正确的姿势去做我想做的事情。

Kubernetes Kubelet CSI 机制解析

在CSI之前,Kubernetes本身就内置了很多插件去对接第三方存储,如果内置插件不满足需求,还可以通过FlexVolume机制,去编写自己的存储插件,然后被动态的加载到Kubernetes中,也就是说Kubernetes并不存在像对接容器运行时那种代码侵入性不好维护的问题,那为什么还...

Kubernetes Kubelet CNI 机制解析

这里说Kubelet CNI,其实说法有些不准确,在Kubernetes Kubelet机制概述中就介绍过,Kubelet并没有直接跟CNI交互,而是通过容器运行时跟外部网络进行交互的,换句话说,CNI解决的是容器网络插件化的问题,跟Kubernetes这种容器编排系统并没有直接关系,但是有很多文章都说Kubelet支持了CNI,包括Kubernets官方的文档Network Plugins,其实这里是特指的Docker,因为Docker本身并不支持CNI,kubelet将对Docker网络环境的创建和删除,通过CNI的方式,放在了dockershim中,如果Kubernetes移除了对Docker的支持,就会移除dockershim,那么kubelet对CNI的支持也就会移除,这样两者就完全没有关系了。

Kubernetes Kubelet CRI 机制解析

CRI机制早在2016年的1.5版本就发布出来了,官方在这篇博文中做了介绍,引入CRI的目的是为了让Kubernetes能够对接多种Container Runtime,而不仅限于Docker这一种。我们知道Docker曾经是容器领域的王者,它的出现开启了容器化时代,紧随其后,又出了很多种其他的容器技术,并且随着容器技术的流行,自然而然产生了对容器编排的需求,于是又涌现了一批容器编排的技术,而Kubernetes就是其中的佼佼者,凭借其强大的社区力量和先进的设计理念,很快独领风骚,在众多竞争者中脱颖而出。早期的Kubernetes仅仅支持Docker这一种容器化技术,根本没有设计什么插件化的机制去支持其他的容器技术,一来可以快速迭代出原型,二来也没有这个必要,当时容器领域基本是Docker的天下,但是随着Docker的各种骚操作,很快容器领域有了其他竞争者,于是让Kubernetes支持其他容器技术的呼声就越来越高,但是对当时的Kubernetes架构来说,如果要支持其他容器技术,就要对Kubernetes的代码做很多ugly的修改,想想当嵌入的容器技术多了的话,维护起来必然很困难,因此一种优雅的插件机制就呼之欲出,很快,社区就设计出了CRI。

Kubernetes Kubelet 机制概述

距离上一篇文章,已经过去了将近9个月的时间,2021年第一篇文章,竟然是到8月份了,真没想到这个kubelet竟然拖了我这么长时间。研究api以及scheduler的日夜还历历在目,不知不觉就过了这么长时间,现在突然写起来,恍如隔世的感觉,这一方面说明kubelet相比其他组件确实要更复...

Kubernetes Scheduler Scheduling Framework

在Kubernetes Scheduler机制概览中就介绍过Scheduling Framework这个新的调度框架,它通过`Plugins以及Extension Points`的方式对调度框架进行了重构,通过在各个预定义的扩展点,插入Plugin的方式,扩展Scheduler的功能,核心的调度算法逻辑,也都放到了Plugin中,如果默认的调度器中的Plugin不能满足需求,可以自己写插件,但是要重新编译代码。