https://example.org/ Recent content on akuo98 Hugo -- gohugo.io en-us Fri, 21 Aug 2026 00:00:00 +0800 https://example.org/posts/go/cilium_knowleage/ Fri, 21 Aug 2026 00:00:00 +0800 https://example.org/posts/go/cilium_knowleage/ 本文从两个方向解释 Cilium： 控制面：Node、Pod、CiliumEndpoint、Service、EndpointSlice、CiliumNetworkPolicy 和 CiliumEgressGatewayPolicy 等资源如何转化为 Linux 路由、eBPF 程序和 BPF Map； 数据面：同节点 Pod、跨节点 Pod、普通 Pod 访问公网、命中统一 Egress Gateway、公网访问内部 Pod时，数据包如何流动。 本文以 IPv4、TC BPF 和 kube-proxy replacement 为主。不同配置可能使用 XDP、native routing、VXLAN、Geneve、WireGuard、IPsec、socket LB 或 L7 proxy，但核心状态模型一致。 1. 总体模型 Cilium agent 预先监听 Kubernetes 资源、分配 identity、计算策略和路由，并把结果写入 BPF Map。数据包到达后，eBPF 程序在内核中查表、执行策略、NAT 和重定向，不会为每个包访问 Kubernetes API。 flowchart LR API[Kubernetes API] --> W[Cilium Watchers] W --> NM[Node Manager] W --> EM[Endpoint Manager] W --> PR[Policy Repository] W --> SM[Service Manager] W --> EGM[Egress Gateway Manager] NM --> TM[cilium_tunnel_map / Linux routes] NM --> IPC[cilium_ipcache] EM --> LXC[cilium_lxc] EM --> PM[cilium_policy_endpointID] PR --> PM PR --> IPC SM --> SVC[cilium_lb4_services_v2] SM --> BE[cilium_lb4_backends_v3] SM --> REV[LB reverse NAT / Maglev maps] EGM --> EGP[cilium_egress_gw_policy_v4] TM --> DP[TC/XDP eBPF datapath] IPC --> DP LXC --> DP PM --> DP SVC --> DP BE --> DP REV --> DP EGP --> DP 1. https://example.org/posts/life/encrypted-usage-test/ Wed, 19 Aug 2026 10:00:00 +0800 https://example.org/posts/life/encrypted-usage-test/ 此文章已加密，用于测试加密文章的构建和解锁流程。 https://example.org/posts/years/2025/ Sat, 10 Jan 2026 14:00:00 +0800 https://example.org/posts/years/2025/ 此文章已加密，用于测试加密文章的构建和解锁流程。 https://example.org/posts/think/philosophy/ Mon, 29 Jul 2024 11:27:49 +0800 https://example.org/posts/think/philosophy/ Introduction Yangming’s philosophy, as an important branch of traditional Chinese philosophy, was founded by the Ming Dynasty philosopher Wang Yangming (also known as Wang Shouren). Its core idea is “the mind is the principle,” advocating that the human mind itself has the ability to recognize and practice moral truth. This doctrine not only had a profound impact on society at the time but also provides valuable wisdom for personal self-cultivation and social governance in modern times. https://example.org/posts/rust/tokio/ Sat, 06 Jul 2024 09:57:50 +0800 https://example.org/posts/rust/tokio/ this artical is from The State of Async Rust: Runtimes Recently, I found myself returning to a compelling series of blog posts titled Zero-cost futures in Rust by Aaron Turon about what would become the foundation of Rust’s async ecosystem and the Tokio runtime. This series stands as a cornerstone in writings about Rust. People like Aaron are the reason why I wanted to be part of the Rust community in the first place. https://example.org/posts/rust/pin/ Fri, 05 Jul 2024 13:18:29 +0800 https://example.org/posts/rust/pin/ this artical is from https://mayer-pu.medium.com/why-does-rust-need-pin-and-unpin-a50a3f2cc1e2 Using asynchronous Rust libraries is usually straightforward, much like working with regular Rust code, using .async or .await. However, writing your own asynchronous library can be challenging. There are some obscure and hard-to-understand syntax, such as T: Unpin and Pin<&mut Self>. Therefore, in this article, we will explain these syntax elements. Self-referentiality is unsafe The presence of Pin addresses a very specific issue: self-referential data types, referring to structures with pointers pointing to themselves. https://example.org/posts/rust/axum/ Tue, 18 Jun 2024 21:32:18 +0800 https://example.org/posts/rust/axum/ axum 是一个基于 tokio,hyper 的http框架。前段时间上手使用的时候对于其内部自动实现 Handler trait 进行闭包回调的过程比较感兴趣。写篇文档记录一下。 https://example.org/posts/go/http/ Tue, 12 Mar 2024 22:57:37 +0800 https://example.org/posts/go/http/ 从0开始用go写一个http框架，权当练手了 2024-03-12 拆分服务接口 处理器接口 过滤器链 有一点点进度 还行 2024-03-13 路由树节点开始 处理器开始 2024-03-14 处理路由匹配逻辑 写测试用例 2024-03-15 完成开发 后续优化 添加中间层处理。方便接入其他逻辑。组件化 实现可替换逻辑。 https://example.org/posts/thread/juc-1/ Sun, 03 Dec 2023 18:08:07 +0800 https://example.org/posts/thread/juc-1/ 本章主要介绍JUC包当中的一些并发处理 cas /** * Atomically update Java variable to <tt>x</tt> if it is currently * holding <tt>expected</tt>. * @return <tt>true</tt> if successful */ public final native boolean compareAndSwapInt(Object o, long offset, int expected, int x); 上面的代码大家可能都比较熟悉，是Unsafe下的对于int属性的cas操作。native方法我们直接去JNI查找实现 UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x)) UnsafeWrapper("Unsafe_CompareAndSwapInt"); oop p = JNIHandles::resolve(obj); jint* addr = (jint *) index_oop_from_field_offset_long(p, offset); return (jint)(Atomic::cmpxchg(x, addr, e)) == e; UNSAFE_END 上面的代码主要分为3步骤 https://example.org/posts/algorithm/red-blacktree/ Sun, 03 Dec 2023 16:52:36 +0800 https://example.org/posts/algorithm/red-blacktree/ https://example.org/posts/thread/two/ Sun, 03 Dec 2023 08:09:06 +0800 https://example.org/posts/thread/two/ 上次咱们聊到了cpu层面对于上层开发者提供的指令以及原子性实现的一些猜测。本章我们就对我们以上的猜测做一些印证。 以下截图来自于Inter手册第三卷 第八章多处理器管理 为了内存系统上的一致性操作提供的总线锁/缓存一致性协议。 为了保证系统内存一致性 当两个或多个处理器试图同时访问系统存储器中的相同地址时，必须提供一些通信机制或内存访问协议来保证数据一致性，并在某些情况下允许一个处理器暂时锁定内存位置。 为了缓存一致性 当一个处理器访问缓存在另一个处理器上的数据时，它不能接收到不正确的数据。如果它修改了数据，则访问该数据的所有其他处理器都必须接收修改后的数据。这条有点类似与日常开发中分布式部署的项目有本地的map缓存及远端的Redis统一缓存。当我们修改本地缓存中的某一个数值的时候，必须保证这个修改同步到其他的节点上，否则会产生数据不一致的问题。同样的往小里看 CPU 同样是要保证这样的一致性的。必须保证多核心在操作自己缓存数据的时候在其他核心缓存上的一致性。 为了允许对内存的写入按可预测的顺序进行 在某些情况下，重要的是要以与程序完全相同的顺序从外部观察内存写入。我理解的这条是保证 CPU 写入的顺序需要跟我们在程序中代码描述的顺序保持一致。比如代码中的顺序为 int a=1,b=2,c=3; 那么 CPU 需要保证在我们读取到 c=3 的时候 a=1 b=2 不会出现写重排的情况。 32位IA-32处理器支持对系统内存中位置的锁定原子操作。这些操作通常用于管理共享的数据结构（如信号量、段描述符、系统段或页表），在其中，两个或多个处理器可以同时尝试修改同一字段或标志。处理器使用三种相互依赖的机制来执行锁定的原子操作： 保证原子操作。 总线锁，使用LOCK#信号和LOCK指令前缀。 缓存一致性协议，确保原子操作可以执行缓存数据结构（缓存锁）；这种机制存在于奔腾4、Intel Xeon和P6系列处理器中。 这些机制在以下方面相互依存。某些基本内存事务（如读取或写入系统内存中的一字节）总是保证以原子方式处理。也就是说，一旦指令开始执行，处理器就保证在另一个处理器或总线访问内存位置之前，当前指令完成操作。处理器还支持总线锁定，用于执行选定的内存操作（如共享内存区域中的读取-修改-写入操作），这些操作通常需要原子处理，但不会以这种方式自动处理。因为频繁使用的内存置通常缓存在处理器的L1或L2缓存中，所以原子操作通常可以在处理器的缓存内执行，而无需总线锁。处理器的缓存一致性协议确保 当原子操作在被缓存的内存地址上执行时 其它的 缓存相同内存地址的 处理器能够被正确的管理。 Note 当发生锁竞争的情况时，软件可能需要实现算法，以确保公平获取资源以防止锁饥饿。硬件不提供任何资源保证参与代理的公平性。管理信号量的公平性和独占锁是软件的责任。 下一章我们看看Java中的具体应用 https://example.org/posts/life/test/ Sun, 03 Dec 2023 08:07:20 +0800 https://example.org/posts/life/test/ https://example.org/posts/thread/stage/ Sat, 02 Dec 2023 21:37:00 +0800 https://example.org/posts/thread/stage/ test https://example.org/posts/life/think/ Sun, 12 Nov 2023 00:00:00 +0800 https://example.org/posts/life/think/ https://example.org/posts/thread/one/ Mon, 01 Jan 0001 00:00:00 +0000 https://example.org/posts/thread/one/ 经常在面试或者各种技术交流群中听到各种并发/多线程的讨论。发现自己对这块还是一知半解的状态，缺少一个整体的了解。因此本系列也算自己对并发/多线程的一些思考和总结。随笔记录，如有不正确的地方欢迎沟通指正。 场景 我们看如下的场景： 在我们多cpu在执行不同的程序代码（数据隔离）的时候。他们是不会互相进行影响的。因为他们之间的数据及代码是独立的不涉及到共享变量的情况。 那其实问题就很明确了当多cpu涉及到执行同一段代码/修改共享数据时，如下图所示： 例如多cpu同时执行如下代码 int a=a+1; 它并不是一个原子性的操作，它其中涉及到3个步骤。 读取b的值。 将b的值进行加1操作。 将处理完毕的数据写入到a的地址。 我们用伪代码来分别标识这3步为 load b，add， store a，那么在两个cpu同时执行的情况下大致会出现以下组合（我们以a=0为例 只列举几种情况）。 1:load a 1:add 1:store a 2:load a 2:add 2:store a 1:load a 2:load a 1:add 1:store a 2:add 2:store a 我们能够发现出现了两种情况，情况1是我们的预期值 2,情况2得到的实际值却为 1。这明显与我们的预期值不符。我们能够很轻松的发现问题的原因，程序并没有按照我们的预期在 cpu1 执行完代码之后 cpu2 再去执行代码。那问题就比较简单了 我们该如何保证两个cpu执行代码的顺序呢？在我们进行讨论之前我们先看一下cpu获取数据进行计算的一个大致演示图1吧： 我们想要保证两个 cpu 执行代码的先后顺序，其实就是要保证 a =a+1 这行代码的原子性，即 load a add store a 三个指令同时执行完毕之后才能执行其他的指令。如上图所示 cpu 通过总线来跟内存中的数据进行交互， 那我们能不能通过在总线上添加标识的形式来告诉其他 cpu 说此路繁忙，请稍后呢。明显是可以的。在我们的 cpu1 进行指令处理的时候我们在总线上设置标识告诉 cpu2 先等一会，在 cpu1 处理完毕之后在执行操作。欸 好像确实能够解决问题，但是我们 仔细想想就能够发现。这种行为就好像是高速公路上某一车道发生了抛锚，结果我们把整条高速公路都给封闭了，等抛锚车辆处理完毕之后我们再放开高速的管制。是能够解决代码执行先后的问题，但是好像对整个与此计算无关的指令都进行了限制，代价是有 一些高的… 既然锁总线代价有些高，那我们就很自然而然的能想到一个解决方案。我们能不能只对我们用到的那个数据进行上锁？应该是可以的吧，我们要相信计算机行业前辈们的智慧👍。如下图所示，我们想要对具体数据进行上锁的话肯定就要在cpu内部 的缓存行1上进行处理了。 我们只需要对加载进入和cpu 缓存的数据进行加锁，既保证了数据的读取又不会太影响 cpu 的执行效率。