KubeVela 以应用为中心，因此对控制器处理逻辑的分析中选取 Application 控制器作为主要的分析对象。 控制器启动 Application 控制器是 OAM 控制集中的一个控制器，在控制器启动的流程中，通过调用了 OAM 控制集的启动，间接启动了该控制器。 123456789101112// Setup adds a controller that reconciles AppRol

KubeVela KubeVela以应用为中心，通过OAM（开放应用模型）作为核心API进行构建，同时KubeVela也是OAM的最佳实践。 KubeVela中将应用拆分为各种细粒度的组件，并通过CRD注册到K8S中。同时KubeVela通过引入CUE作为模板引擎，提供了对CRD的抽象，用户可以用过编写CUE定义的应用模板，将多种K8S资源组装在一起构成应用。 控制器启动 我们从cmd/core/

Addon KubeVela本身是一个比较新的项目，正处于高速发展期，因此很多设计可能会在短时间内就迎来变化，因此本文介绍是V1.4~V1.5版本时KubeVela内部加载一个插件的流程。 插件目录结构 自定义插件 | KubeVela 以上暂时是KubeVela V1.4版本的插件结构，在V1.5版本后会将插件使用的VelaQL实例view文件单独渲染，因此引入了一个新的文件目录views，

实际上我很早就看过《Go Web编程》这本书，其中的一章很详细地介绍了Go中构建一个最简单的服务器的方法， Go在标准库中为我们提供了一个net/http包，这个包中提供了完善的功能来帮助我们构建一个Web服务器，Go中很多Web框架的底层实际上也是借助了这个标准库来实现自己的功能。 当时看完这本书后，觉得自己已经掌握了相关的知识，但在前两天打算写一个最简单的服务器打包成Docker镜像来进行Ku

在我使用docker对我目前负责的一个项目进行部署时，遇到了这样的一个问题，使用dockerfile构建出的docker镜像的体积太大了。当时我只觉得这是不可避免的，毕竟容器的底层还是运行着一个操作系统，加之Golang的编译环境，再加上项目的代码以及静态资源，最终构建出的镜像体积为1.1G似乎是一件再正常不过的事情。 Version 1 以下是我第一版用于构建docker镜像的dockerfil

前言 前几天听学长们回忆面试的经历，其他的内容大多都不记得了，只记得他们提到面试官问了线程池的相关概念，线程池对我来说不算熟悉也不算陌生。 按照我的理解，线程池主要应用在多线程服务器中，是为了解决存在大量请求时，为了使每个请求可以被迅速处理，而为每一个请求创建了一个处理线程，但每个处理请求本身所需要消耗的时间是很短暂的，在处理请求的任务完成后，运行时会销毁线程、进行GC等一系列操作，导致在处理请求

前言 本文是阅读《Redis 实战》期间的学习笔记，书中的主要功能使用使用Python进行实现，本文使用Golang对功能进行复现。 Redis为开发者们提供了事务的功能，具体的实现为：以特殊命令MULTI开始，接着输入要执行的多条命令，最后输入特殊命令EXEC标志着事物的结束，同时还需要配合WATCH命令以保持数据的一致性，在WATCH期间，当客户端执行EXEC时，若Redis检测到，有其他

问题 之前的正常使用中，我的Clash的代理端口一直都是被设置为7890，但是在一次系统更新后，我发现不光是以往需要代理才能访问的网站，甚至是平时不需要代理就可以正常访问的网站，全部无法访问了，并且原因是由于Clash造成的。 在排除了Clash代理的配置文件是否过期和机场提供商是否跑路的问题后，我发现了一个严重的问题，我的代理端口变为了0，0号端口是一个非法端口，使用这个端口进行转发，毫无疑问

Project1的主要内容是实现一个单机的K/V存储引擎，并通过gRPC为上层提供服务，通过RPC调用该存储引擎可以执行Put、Delete、Get、Scan四种操作。存储引擎的底层借助badger作为底层K/V数据库实现。 该项目的任务可划分为以下两个步骤，包括： 实现一个单机的存储引擎。 借助实现的存储引擎，实现K/V服务。 虽然在Project1阶段，涉及的代码量并不多，只要明确工作内容

2021年就要过去了，我不想怀念他。 悄悄地，2021也走到了尾声，不过我的2021相比2020过得更加充实，这一年中我也有了更多的收获与感悟。 2021年我的生活中少了一些人，也多了一些人，少了一些事，也多了一些事。这些人和事有让我欣喜的、意外的、惋惜的以及怀念的。但我知道这都是我的生命中不可或缺的，他们成为了我人生中的一部分，也在悄悄地改变着我的人生。 关于今年 与大家的分别 2021年