-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.json
1 lines (1 loc) · 27.5 KB
/
index.json
1
[{"content":"进程信息 master节点上存在的进程信息 Kubernetes API Server 所有涉及到k8s的操作都需要经过API Server进行下发\nKubernetes Controller Manager 具体控制主进,用来控制k8s的主要运行逻辑\nKubernetes Scheduler 资源调度进程。例如要运行一个pod,将由scheduler进程根据已知的所有机器的CPU、内存等资源进行考虑后进行分配,选出最佳node节点\nEtcd 集群状态存储,集群所有的组件的状态都保存在这里\nnode节点上存在的进程信息 kubelet 和master节点进行通信,协助管理node节点.负责pod的创建、启停等动作\nkube-proxy 负责Service通信和负载均衡\ndocker 运行容器\n概念介绍 Pod (原子调度单元) pod是一个虚拟化的概念,是一系列资源的集合(包括容器、存储卷等),切共享同一个网络命名空间(uts时间功效、ipc进程间通信、net网络名称空间功效)\n控制器 原则:高层控制器通过标签选择器来定位下一层控制器,所以对于高层控制器selector是必填字段,对于底层控制器 label是必填字段\n无状态服务: 无状态服务是指服务实例间没有依赖关系,每个服务都是单独存在的 例如web服务等 有状态服务: 例如redis/mysql等存在数据存储,实例间强关联的服务\nDeployment (管理无状态服务的控制器) deployment ==\u0026gt; replicaset ==\u0026gt; pod ==\u0026gt; container (实体) deployment是也是一层抽象,它是基于relicaSet的二次封装,replicaset是用来管理pod使用的组件。 对比relicaSet,deployment新增了自动缩扩容、滚动更新和回滚等机制。 更高维度的去管理replicaset\nStateful (管理有状态服务的控制器) Stateful有状态服务,每个Pod有独立的PVC/PV存储组件\n唯一性: 每个Pod会被分配一个唯一序号. 顺序性: Pod启动,更新,销毁是按顺序进行. 稳定的网络标识: Pod主机名,DNS地址不会随着Pod被重新调度而发生变化. 稳定的持久化存储: Pod被重新调度后,仍然能挂载原有的PV,从而保证了数据的完整性和一致性. Job 一次性任务 Job 普通job,运行一次。如果运行时挂了会重新启动运行 CronJob 周期性运行job Service K8S 上的 Service 不是一个应用程序,也不是一个组件,它是一个 iptables dnat 规则,或者 ipvs 规则,Service 只是规则,所以是 ping 不通的,由于是dnat规则或是ipvs规则,可以使用利用端口进行测试\n总的来说客户端请求 Service 由 Service 代理至后端的 POD,所以客户端看到的始终是 Service 的地址。\n网络模型 k8s 有三种网络:POD网络、集群网络、节点网络\nk8s网络模型设计基础原则:每个Pod都拥有一个独立的 IP地址,而且 假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中 。 所以不管它们是否运行在同 一 个 Node (宿主机)中,都要求它们可以直接通过对方的 IP 进行访问。设计这个原则的原因 是,用户不需要额外考虑如何建立 Pod 之间的连接,也不需要考虑将容器端口映射到主机端口等问题。\n容器间网络: 容器启动时可以指定对应的容器ID进行网络互访,给每个pod都提供一个pause容器,将所有pod的其他容器都指向于pause容器就实现了容器间的网络共享。 同一node下 Pod和Pod共享: 为了让多个Pod的网络命名空间链接起来,我们可以让veth对的一端链接到root网络命名空间(宿主机的),另一端链接到Pod的网络命名空间。 不同node下 pod和pod共享:k8s中每个集群中的每个Node都会被分配了一个CIDR块(无类别域间路由选择,把网络前缀都相同的连续地址组成的地址组称为CIDR地址块)用来给该Node上的Pod分配IP地址。(保证pod的ip不会冲突) 参考资料 https://awesome-kubernetes-notes.readthedocs.io/en/latest/awesome-kubernetes-notes.html?highlight=deployment#\n","permalink":"https://thebestll.github.io/2023/k8s/","summary":"进程信息 master节点上存在的进程信息 Kubernetes API Server 所有涉及到k8s的操作都需要经过API Server进行下发\nKubernetes Controller Manager 具体控制主进,用来控制k8s的主要运行逻辑\nKubernetes Scheduler 资源调度进程。例如要运行一个pod,将由scheduler进程根据已知的所有机器的CPU、内存等资源进行考虑后进行分配,选出最佳node节点\nEtcd 集群状态存储,集群所有的组件的状态都保存在这里\nnode节点上存在的进程信息 kubelet 和master节点进行通信,协助管理node节点.负责pod的创建、启停等动作\nkube-proxy 负责Service通信和负载均衡\ndocker 运行容器\n概念介绍 Pod (原子调度单元) pod是一个虚拟化的概念,是一系列资源的集合(包括容器、存储卷等),切共享同一个网络命名空间(uts时间功效、ipc进程间通信、net网络名称空间功效)\n控制器 原则:高层控制器通过标签选择器来定位下一层控制器,所以对于高层控制器selector是必填字段,对于底层控制器 label是必填字段\n无状态服务: 无状态服务是指服务实例间没有依赖关系,每个服务都是单独存在的 例如web服务等 有状态服务: 例如redis/mysql等存在数据存储,实例间强关联的服务\nDeployment (管理无状态服务的控制器) deployment ==\u0026gt; replicaset ==\u0026gt; pod ==\u0026gt; container (实体) deployment是也是一层抽象,它是基于relicaSet的二次封装,replicaset是用来管理pod使用的组件。 对比relicaSet,deployment新增了自动缩扩容、滚动更新和回滚等机制。 更高维度的去管理replicaset\nStateful (管理有状态服务的控制器) Stateful有状态服务,每个Pod有独立的PVC/PV存储组件\n唯一性: 每个Pod会被分配一个唯一序号. 顺序性: Pod启动,更新,销毁是按顺序进行. 稳定的网络标识: Pod主机名,DNS地址不会随着Pod被重新调度而发生变化. 稳定的持久化存储: Pod被重新调度后,仍然能挂载原有的PV,从而保证了数据的完整性和一致性. Job 一次性任务 Job 普通job,运行一次。如果运行时挂了会重新启动运行 CronJob 周期性运行job Service K8S 上的 Service 不是一个应用程序,也不是一个组件,它是一个 iptables dnat 规则,或者 ipvs 规则,Service 只是规则,所以是 ping 不通的,由于是dnat规则或是ipvs规则,可以使用利用端口进行测试","title":"K8s"},{"content":"背景 新进了俩款容器安全产品需要体验一下,需要搭建一套Ci环境进行体验测试 我目前搭建好了K8S 特此记录一下 整体的部署并不复杂,只是会涉及到一些坑还有部分未了解的知识点 简单罗列出来学习一下\n部署 docker 安装 yum install -y docker 安装docker systemctl restart docker 启动docker 关闭selinux selinux检测过于严格 setenforce 0 \u0026amp;\u0026amp; sed -i \u0026quot;s/SELINUX=enforcing/SELINUX=disabled/g\u0026quot; /etc/selinux/config 关闭防火墙 将网络交由k8s管理 systemctl stop firewalld systemctl disable firewalld 设置hostname 在/etc/hosts 最后一行加上host 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 k8s 关闭 swap 当内存不足时,linux会自动使用swap,将部分内存数据存放到磁盘中,这个这样会使性能下降,为了性能考虑推荐关掉 swapoff -a \u0026amp;\u0026amp; sed -i '/ swap / s/^\\(.*\\)$/#\\1/g' /etc/fstab 安装etcd和Kubernetes yum -y update yum install -y etcd kubernetes 安装containerd k8s 1.24版本后默认使用containerd sudo yum -y install containerd 删除配置 cat /etc/containerd/config.toml | grep -n \u0026quot;sandbox_image\u0026quot; 修改/etc/docker/daemon.json 添加\u0026quot;exec-opts\u0026quot;: [\u0026quot;native.cgroupdriver=systemd\u0026quot;] 启动! systemctl daemon-reload systemctl restart docker kubeadm init \u0026ndash;image-repository=registry.aliyuncs.com/google_containers \u0026ndash;v=5 kubeadm reset (如果上次启动没有成功的话,需要进行重置) 解决网络未启动的命令 curl https://docs.projectcalico.org/manifests/calico.yaml -O \u0026raquo; calico.yaml kubectl apply -f calico.yaml 命令操作手册 概念学习 ","permalink":"https://thebestll.github.io/2023/k8sbuild/","summary":"背景 新进了俩款容器安全产品需要体验一下,需要搭建一套Ci环境进行体验测试 我目前搭建好了K8S 特此记录一下 整体的部署并不复杂,只是会涉及到一些坑还有部分未了解的知识点 简单罗列出来学习一下\n部署 docker 安装 yum install -y docker 安装docker systemctl restart docker 启动docker 关闭selinux selinux检测过于严格 setenforce 0 \u0026amp;\u0026amp; sed -i \u0026quot;s/SELINUX=enforcing/SELINUX=disabled/g\u0026quot; /etc/selinux/config 关闭防火墙 将网络交由k8s管理 systemctl stop firewalld systemctl disable firewalld 设置hostname 在/etc/hosts 最后一行加上host 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 k8s 关闭 swap 当内存不足时,linux会自动使用swap,将部分内存数据存放到磁盘中,这个这样会使性能下降,为了性能考虑推荐关掉 swapoff -a \u0026amp;\u0026amp; sed -i '/ swap / s/^\\(.*\\)$/#\\1/g' /etc/fstab 安装etcd和Kubernetes yum -y update yum install -y etcd kubernetes 安装containerd k8s 1.24版本后默认使用containerd sudo yum -y install containerd 删除配置 cat /etc/containerd/config.","title":"k8s构建"},{"content":"ebpf学习 名称 eBpf =\u0026gt;Extended Berkeley(报文) Packet Filter 拓展的伯克利报文过滤器 实际上ebpf已经脱离该定义范畴,目前已经发展成一种内核技术,它允许开发人员在不修改内核代码的情况下运行特定的功能\n一些基础概念 实现原理: 基于内核态实现了一个小的通用的虚拟机运行用户态编写的字节码程序。 用户态概念: Ebpf程序: 由c语言编写,后续需要在内核态运行的程序。 Clang LLVM: clang翻译Ebpf指令 提供基础环境 LLVM用于生成字节码。 Ebpf指令集: 内核提供的ebpf指令集,解决一些特殊的转化问题。 内核态概念: 解释器: 将ebpf字节码解释为机器码。 JIT: 提供缓存功能,不需要每次解释一遍ebpf字节码。 内核解释器:直接解释ebpf字节码的工具。 Ebpf指令集: 拓展的指令方法。 验证器:所有的ebpf程序都需要经过验证才能进入内核的EBPF虚拟机 事件源: ebpf hook的节点,主要是tracepoint、USDT\u0026hellip;这些是目前的薄弱点,需要加强学习 静态追踪: 网络套接字、tracepoint、USDT 动态追踪: Kprobe、Uprobe 采样,PMC: perf_event 和用户态交互: Ebpf Map: 栈空间 无限制的映射型存储 perf缓冲区 512字节大小的栈空间 尾调用(tail call): 实现逻辑程序链 流程展示 确定hook节点以及函数入参结构体\nkprobe sudo cat /sys/kernel/debug/tracing/available_filter_functions 查看查看哪些函数支持 sudo echo 'p tcp_v4_connect' \u0026gt; /sys/kernel/debug/tracing/kprobe_events 添加kprobe函数 cat /sys/kernel/debug/tracing/kprobe_events #查看是否添加成功 cat /sys/kernel/debug/tracing/events/kprobes/p_tcp_v4_connect_0/format #查看添加函数参数类型 定义hook函数结构体 struct tcp_v4_connect_args { unsigned short common_type; unsigned char common_flags; unsigned char common_preempt_count; int common_pid; unsigned long __probe_ip; }; TODO #其他流程待补充 用户利用c语言编写ebpf程序\n代码编写-\u0026gt;涉及到的概念: ebpf指令集 ebpfmap ebpf perf_event 利用llvm等工具 进行汇编 翻译成Ebpf字节码 加载器\nBPF_PROG_LOAD函数 load programs,判断类型决定入参数 {kprobe:7,kretprobe:10,tracepoint:11\u0026hellip;} 将ebpf字节码load到内核中 load_and_attach=\u0026gt;bpf_prog_load 分配内核程序和数据结构空间 bpf_prog_alloc bpf虚拟机指令由用户态拷贝到内核态 copy_from_user 合法性扫描 bpf_check 分配一个fd用于和用户态交流 bpf_prog_new_fd 创建 bpf_prog 存储指令\nbpf_prog和特定hook关联 hook访问到时,取出对应的bpf_prog,执行 bpf字节码-\u0026gt;{解释器}-\u0026gt;bpf机器码\n若有JIT则由JIT解释器执行 无JIT则内核解释器执行 运行bpf机器码: 可能涉及到的概念:\npref缓冲区传递每个事件的输出 EBpf map传递数据,调用栈数据 事件源配置 TODO kprobes和kreprobes kprobes k =\u0026gt;内核 ;probe =\u0026gt;探针 ;re=\u0026gt;返回 kprobes相当于在内核函数打断点\n工作机制\n内核函数某处字节内容进行复制保留 以单步中断指令覆盖目标地址[int3 or jmp] 内核函数运行到断点时会提交给handler_pre()处理 pre函数处理完成后,返回原函数继续执行 kreprobes k =\u0026gt;内核 ;probe =\u0026gt;探针 ;re=\u0026gt;返回 kreprobes在内核返回时处打断点\n工作机制\n在内核函数入口处插桩 当该函数被命中时,会将返回函数替换为trampoline函数地址 原内核函数运行完,会优先运行替换的trampoline函数 trampoline函数运行完后,返回原函数返回 uprobes和ureprobes 将内核态的函数替换为用户态的函数理解即可,其他过程参照 kprobes和kreprobes[#kprobes和kreprobes]\n参考来源 ebpf-pdf资料 http://kerneltravel.net/blog/2021/ebpf_beginner/ebpf.pdf 一个大佬写的博客 https://davidlovezoe.club/wordpress/archives/tag/bpf cilium项目 https://github.com/cilium/cilium 一个巨佬的博客 https://www.brendangregg.com/blog/2019-07-15/bpf-performance-tools-book.html ","permalink":"https://thebestll.github.io/2023/ebpf/","summary":"ebpf学习 名称 eBpf =\u0026gt;Extended Berkeley(报文) Packet Filter 拓展的伯克利报文过滤器 实际上ebpf已经脱离该定义范畴,目前已经发展成一种内核技术,它允许开发人员在不修改内核代码的情况下运行特定的功能\n一些基础概念 实现原理: 基于内核态实现了一个小的通用的虚拟机运行用户态编写的字节码程序。 用户态概念: Ebpf程序: 由c语言编写,后续需要在内核态运行的程序。 Clang LLVM: clang翻译Ebpf指令 提供基础环境 LLVM用于生成字节码。 Ebpf指令集: 内核提供的ebpf指令集,解决一些特殊的转化问题。 内核态概念: 解释器: 将ebpf字节码解释为机器码。 JIT: 提供缓存功能,不需要每次解释一遍ebpf字节码。 内核解释器:直接解释ebpf字节码的工具。 Ebpf指令集: 拓展的指令方法。 验证器:所有的ebpf程序都需要经过验证才能进入内核的EBPF虚拟机 事件源: ebpf hook的节点,主要是tracepoint、USDT\u0026hellip;这些是目前的薄弱点,需要加强学习 静态追踪: 网络套接字、tracepoint、USDT 动态追踪: Kprobe、Uprobe 采样,PMC: perf_event 和用户态交互: Ebpf Map: 栈空间 无限制的映射型存储 perf缓冲区 512字节大小的栈空间 尾调用(tail call): 实现逻辑程序链 流程展示 确定hook节点以及函数入参结构体\nkprobe sudo cat /sys/kernel/debug/tracing/available_filter_functions 查看查看哪些函数支持 sudo echo 'p tcp_v4_connect' \u0026gt; /sys/kernel/debug/tracing/kprobe_events 添加kprobe函数 cat /sys/kernel/debug/tracing/kprobe_events #查看是否添加成功 cat /sys/kernel/debug/tracing/events/kprobes/p_tcp_v4_connect_0/format #查看添加函数参数类型 定义hook函数结构体 struct tcp_v4_connect_args { unsigned short common_type; unsigned char common_flags; unsigned char common_preempt_count; int common_pid; unsigned long __probe_ip; }; TODO #其他流程待补充 用户利用c语言编写ebpf程序","title":"Ebpf"},{"content":"mutex是什么 mutex是golang中处理异步状态的工具 有互斥锁 sync.Mutex 和读写锁 sync.RWMutex\n互斥锁和读写锁的区别 读写锁本身内部实现就是用来互斥锁的技术 互斥锁是简单意义上的上锁开锁概念,且不支持多次上锁 会报错。 读写锁是在互斥锁的基础上封装了业务逻辑,即 允许多次读锁的上锁和开锁 待到读锁都释放时方能运行写锁上锁 写锁上锁时,不允许读锁使用 概念说明 自旋条件: 未获取到锁时循环获取,有次数限制 超过次数进入唤醒队列进行等待 饥饿状态: 竞争状态下老goroutine长时间未获取到锁就会进入饥饿状态,取消自旋机制,采用FIFO 先进先出的办法处理等待队列 正常状态: 非饥饿状态,等待队列的原则是先进先出。若有自旋状态的goroutine则相互竞争获取锁 结构体 //互斥锁 type Mutex struct { state int32 //状态标志位 通过原子操作进行修改 sema uint32 //信号量,用于使用goroutine的阻塞和唤醒 } // state状态标志位实际上是用多个位的状态来进行区分(如下所示,x表示0/1) // xxxxxx... x x x // goroutine排队个数 是否饥饿状态 是否有协程被唤醒 是否上锁 //读写锁 type RWMutex struct { w Mutex // 互斥锁的原理 writerSem uint32 // 写协程的信号量 readerSem uint32 // 读协程的信号量 readerCount int32 // number of pending readers readerWait int32 // number of departing readers } ","permalink":"https://thebestll.github.io/2023/lock/","summary":"mutex是什么 mutex是golang中处理异步状态的工具 有互斥锁 sync.Mutex 和读写锁 sync.RWMutex\n互斥锁和读写锁的区别 读写锁本身内部实现就是用来互斥锁的技术 互斥锁是简单意义上的上锁开锁概念,且不支持多次上锁 会报错。 读写锁是在互斥锁的基础上封装了业务逻辑,即 允许多次读锁的上锁和开锁 待到读锁都释放时方能运行写锁上锁 写锁上锁时,不允许读锁使用 概念说明 自旋条件: 未获取到锁时循环获取,有次数限制 超过次数进入唤醒队列进行等待 饥饿状态: 竞争状态下老goroutine长时间未获取到锁就会进入饥饿状态,取消自旋机制,采用FIFO 先进先出的办法处理等待队列 正常状态: 非饥饿状态,等待队列的原则是先进先出。若有自旋状态的goroutine则相互竞争获取锁 结构体 //互斥锁 type Mutex struct { state int32 //状态标志位 通过原子操作进行修改 sema uint32 //信号量,用于使用goroutine的阻塞和唤醒 } // state状态标志位实际上是用多个位的状态来进行区分(如下所示,x表示0/1) // xxxxxx... x x x // goroutine排队个数 是否饥饿状态 是否有协程被唤醒 是否上锁 //读写锁 type RWMutex struct { w Mutex // 互斥锁的原理 writerSem uint32 // 写协程的信号量 readerSem uint32 // 读协程的信号量 readerCount int32 // number of pending readers readerWait int32 // number of departing readers } ","title":"mutex"},{"content":"buffer是什么 一个实现了缓冲字节流的高效数据类型 buffer的存在意义 减少系统调用减少读写操作,常见于网络io和文件io中 内存使用优化 可以预定字节流大小 自动扩充字节切片 buffer重置时不需要使用新内存块,只需要重用字节切片即可 支持多种数据格式 支持并发读写 buffer具体实现 //Go 1.19版本 type Buffer struct { buf []byte // 实际数据切片 包括 len(buf)长度和 cap(buf)容量 off int // 已读数据,或者是已写数据 lastRead readOp // 标志位,用于记录上一次操作状态 分为空状态、读状态、读一个字节、读俩个字节... ","permalink":"https://thebestll.github.io/2023/buffer/","summary":"buffer是什么 一个实现了缓冲字节流的高效数据类型 buffer的存在意义 减少系统调用减少读写操作,常见于网络io和文件io中 内存使用优化 可以预定字节流大小 自动扩充字节切片 buffer重置时不需要使用新内存块,只需要重用字节切片即可 支持多种数据格式 支持并发读写 buffer具体实现 //Go 1.19版本 type Buffer struct { buf []byte // 实际数据切片 包括 len(buf)长度和 cap(buf)容量 off int // 已读数据,或者是已写数据 lastRead readOp // 标志位,用于记录上一次操作状态 分为空状态、读状态、读一个字节、读俩个字节... ","title":"Buffer"},{"content":"chan是什么 chan是用于goroutine通信的重要方式 分为无缓冲通道和有缓冲通道俩种 并发安全,可以支持多取多给 chan的存在意义 简化了多协程环境通信的复杂性(并发安全、准确性、原子性\u0026hellip;) chan实现存在意义的方法 make定义的chan实际上是一个结构体的指针 在chan传递值的时候,实际上进行的是值拷贝 Do not comminute by sharing memory;instead, share memory by communicating 利用环形列表使得缓冲通道得以实现 利用互斥锁实现的读取堵塞 chan结构体 #源码位于 1.19版本runtime\\chan.go type hchan struct { qcount uint // chan长度 有缓存\u0026gt;1 无缓存=1 dataqsiz uint // 环形队列首部 buf unsafe.Pointer // 环形数据指针 elemsize uint16 // 环形队列尾部 closed uint32 elemtype *_type // chan数据类型 sendx uint // 发送 index recvx uint // 接收 index recvq waitq // 等待接收的 waiters sendq waitq // 等待发送的 waiters // lock protects all fields in hchan, as well as several // fields in sudogs blocked on this channel. // // Do not change another G\u0026#39;s status while holding this lock // (in particular, do not ready a G), as this can deadlock // with stack shrinking. lock mutex //互斥锁 } chan接收\\发送数据的流程 make数据 testChan:=make(chan int,1) 或者无缓存 testChan:=make(chan int) 注意此时的testChan本质上是一个hchan指针 接收goroutine数据 testChan\u0026lt;-data 判断环形队列是否已经满了,即判断chan的环形队列尾索引值+1是整除总长度是否等于队列首索引值 (this.tail + 1) % this.maxSize == this.head 若队列未满,则上锁 sendx+1 将goroutine数据复制一份到队列中保存后, recv+1 再释放锁 若队列已满,则利用将goroutine加入 recvq队列中 中,并利用GMP调度,将替换当前执行的goroutine 队列有空间时,则启用recvq队列相应接收数据 向goroutine发送数据 data\u0026lt;-testChan 判断环形队列是否有数据,即判断chan环形队列的首尾索引是否相等 若队列有数据,则上锁 sendx+1 将队列数据复制一份到goroutine后, recv+1 再释放锁 若队列为空,则利用将goroutine加入 sendq队列中 中,并利用GMP调度,将替换当前执行的goroutine 待有数据到来到时,则启用sendq队列相应消费数据 ","permalink":"https://thebestll.github.io/2023/chan/","summary":"chan是什么 chan是用于goroutine通信的重要方式 分为无缓冲通道和有缓冲通道俩种 并发安全,可以支持多取多给 chan的存在意义 简化了多协程环境通信的复杂性(并发安全、准确性、原子性\u0026hellip;) chan实现存在意义的方法 make定义的chan实际上是一个结构体的指针 在chan传递值的时候,实际上进行的是值拷贝 Do not comminute by sharing memory;instead, share memory by communicating 利用环形列表使得缓冲通道得以实现 利用互斥锁实现的读取堵塞 chan结构体 #源码位于 1.19版本runtime\\chan.go type hchan struct { qcount uint // chan长度 有缓存\u0026gt;1 无缓存=1 dataqsiz uint // 环形队列首部 buf unsafe.Pointer // 环形数据指针 elemsize uint16 // 环形队列尾部 closed uint32 elemtype *_type // chan数据类型 sendx uint // 发送 index recvx uint // 接收 index recvq waitq // 等待接收的 waiters sendq waitq // 等待发送的 waiters // lock protects all fields in hchan, as well as several // fields in sudogs blocked on this channel.","title":"chan学习"},{"content":"自我介绍 Hello\n我叫车牛皮糖,96年出生。\n一个拥有可爱女儿的年轻爸爸,也是一个工龄4年半的安全研发。 我的想法很多,但是它们经常跑得也很快。\n从来没有得到真正反复淬炼和思考,所以我选择记录它并尝试分享。 分享得过程回让我喜悦,也是一次思想整理的过程。\n目前我在同程旅游工作,是全栈工程师(偏后端)。 关注的方向是 主机安全(小白) 和 AI(纯小白)。 如果您有兴趣一起来探讨技术上或者生活上的问题,可以通过微信联系到我。\nWechat Email 792501053@qq.com\n","permalink":"https://thebestll.github.io/aboutme/","summary":"自我介绍 Hello\n我叫车牛皮糖,96年出生。\n一个拥有可爱女儿的年轻爸爸,也是一个工龄4年半的安全研发。 我的想法很多,但是它们经常跑得也很快。\n从来没有得到真正反复淬炼和思考,所以我选择记录它并尝试分享。 分享得过程回让我喜悦,也是一次思想整理的过程。\n目前我在同程旅游工作,是全栈工程师(偏后端)。 关注的方向是 主机安全(小白) 和 AI(纯小白)。 如果您有兴趣一起来探讨技术上或者生活上的问题,可以通过微信联系到我。\nWechat Email 792501053@qq.com","title":"About Me"},{"content":"写在前面 虽然今年已经过去一半,但是任何时候启程都不算太晚 “也算是对抗焦虑的一剂良药”\n概述 自我总结 工作也好几年了,但是一直没有对自己掌握的知识做归纳总结。处于一个比较混乱的状态。\n未来的路 定好方向,才不会迷茫\n每一步 具体分步做好规划,做好持久战的准备\n自我总结 后端开发 go 主要在使用的开发语言,平台后端构建相关知识熟练,但是基础不牢 python 主要用于构建一些测试样例,解决实际小任务,水平 “简答会用” java 弱 前端开发 Vue 熟练掌握Vue2,存在Vue3开发经验 浏览器插件 有过一个项目的开发经验 electron 有过一个项目的开发经验 中间件 数据库 mysql 业务熟练,基础缺乏 mongo 业务熟练,基础缺乏 redis 业务熟练,基础缺乏 消息处理 kafka 业务熟练,基础缺乏 Es 业务熟练,基础缺乏 ETCD 业务熟练,基础缺乏 未来的路 考虑继续往安全开发岗位发展 目前尝试的太少 探索的太少\nstepToStep 专注于基础 2023-6-11 to 2023-7-30 go语言八股文学习 基本遵循 https://github.com/debuginn/golang-developer-roadmap-cn学习路线 命令行、信道、缓冲区、互斥锁 延迟机制、panic、Recover 对前端的学习,暂时处于能用就行 中间件基础学习 mysql、mongo、redis ","permalink":"https://thebestll.github.io/2023/plan/","summary":"写在前面 虽然今年已经过去一半,但是任何时候启程都不算太晚 “也算是对抗焦虑的一剂良药”\n概述 自我总结 工作也好几年了,但是一直没有对自己掌握的知识做归纳总结。处于一个比较混乱的状态。\n未来的路 定好方向,才不会迷茫\n每一步 具体分步做好规划,做好持久战的准备\n自我总结 后端开发 go 主要在使用的开发语言,平台后端构建相关知识熟练,但是基础不牢 python 主要用于构建一些测试样例,解决实际小任务,水平 “简答会用” java 弱 前端开发 Vue 熟练掌握Vue2,存在Vue3开发经验 浏览器插件 有过一个项目的开发经验 electron 有过一个项目的开发经验 中间件 数据库 mysql 业务熟练,基础缺乏 mongo 业务熟练,基础缺乏 redis 业务熟练,基础缺乏 消息处理 kafka 业务熟练,基础缺乏 Es 业务熟练,基础缺乏 ETCD 业务熟练,基础缺乏 未来的路 考虑继续往安全开发岗位发展 目前尝试的太少 探索的太少\nstepToStep 专注于基础 2023-6-11 to 2023-7-30 go语言八股文学习 基本遵循 https://github.com/debuginn/golang-developer-roadmap-cn学习路线 命令行、信道、缓冲区、互斥锁 延迟机制、panic、Recover 对前端的学习,暂时处于能用就行 中间件基础学习 mysql、mongo、redis ","title":"2023学习计划"}]