在容器的启动过程中，镜像下载速度往往是影响启动速度的最主要因素，通常占据了启动时间的 70% 以上。特别是对于体积庞大的 VM、AI 镜像，它们的大小可能达到数十 GB，导致下载和解压速度都成为启动的瓶颈。本文将探讨镜像下载的主要瓶颈、常见的优化方案以及最新的按需加载技术，以加速容器启动。镜像下载速度慢的原因容器镜像下载慢的原因主要有以下几点：镜像体积过大：VM、AI 镜像体积通常较大，可能达到数十 GB，使得下载时间显著。gzip 解压耗时：特别是在内网环境中，解压时间往往远高于网络传输时间，导致解压成为新的瓶颈。常见的镜像优化思路为了解决下载和解压的速度问题，业界提出了多种优化方案：镜像缓存镜像缓存是提升镜像下载速度的一种方法，通过缓存镜像可以避免重复下载。然而，缓存无法解决冷启动问题，并且镜像频繁变更（如应用更新或安全更新）会导致缓存失效。要实现高效的缓存管理，还需要较复杂的机制来管理缓存更新。减小镜像体积减少镜像体积也有助于缩短下载时间，但在某些场景下，例如 VM、AI、CUDA 镜像，体积优化空间有限。它们通常需要使用超过 7 GB 的存储空间，难以进一步缩减。按需加载：是否可行？目前，大多数容器在启动时并不需要完整的镜像内容。一些论文表明，启动期间仅需 6.4% 的镜像内容，因此理论上可以通过按需下载来优化启动速度。然而，现有的镜像格式存在以下问题，限制了按需下载的实现 ...继续阅读 (10)

上篇博客介绍了 Cloudflare AI Gateway，这篇集中介绍一下 Kong, Gloo 和 Higress 因为这三者有一定的相似性，都是从原有的 API 网关基础上进行扩展，通过插件的方式支持了一系列 AI 相关的功能，在交付上也是传统的软件部署方式。这几个算是传统 API Gateway 迎接 AI 浪潮的代表，其中 Higress 更是把产品 Slogan 直接从 Cloud Native API Gateway 变成了 AI Gateway，虽然打不过就加入，但这样变来变去不怕人说没根么：）由于这三款产品都需要额外的部署开通，有的 AI 功能还是商业版才有，所以下面的分析都是根据看文档总结而来，可能存在着和实际不符的情况。功能KongGlooHigress备注技术栈Nginx + LuaEnvoy + GoEnvoy + WASM虽然几家都提供了插件机制，但是和网关的耦合程度都比价高，非网关的开发者上手还是有一定难度日志监控每个 AI 插件会将元信息，如模型名、Token 开销费用等信息加入到 Audit Log 中，但是似乎没有自定义元信息的功能，需要通过其他插件来辅助完成似乎没有在 AI 这块对日志有功能增强，还是通用的监控日志和监控中增加了 Token 的用量，提供的信息和 Kong 类似，也不具备自定义元信息的功能如果能增加一些自定义元信息，并支持记录 ...继续阅读 (17)

随着 AI 的火热，眼看着之前调研的各家竞品 API 网关产品纷纷把自己的介绍改为 AI Gateway，于是就想调研一下这些所谓的 AI Gateway 究竟做了些啥。这次调研的对象有一些之前靠 API 网管或者云原生 Ingress Controller 起家加入 AI 功能的，例如：Kong，Gloo和Higress。也包括一些第一天就是借着 AI 起来的我认为真正 AI 原生的网关，例如Portkey和OneAPI。以及这篇博客介绍的基于公有云 Serverless 的Cloudflare AI Gateway。大体来看目前的 AI Gateway 主要能力在三个方面：常规 API 网关功能在 AI API 上的应用，例如：监控，日志，限速，反向代理，集成用户系统等。这些功能其实和 AI 关系不大就是把 LLM 的 API 当成了一个普通的 API 进行接入。部分 API 网关功能针对 AI 进行优化，例如限速功能增加基于 Token 的限速，缓存功能增加基于 Prompt 的缓存，防火墙基于 prompt 和 LLM 返回进行过滤，多个 LLM API Key 之间的负载均衡。这些功能在原有的 API 网关就存在类似的概念，不过在 AI 场景下又有了相应的扩展。基于 AI 应用的场景增加的新功能，例如部分 AI 网关增加了 Embedding 和 RAG 的功能，把向量数 ...继续阅读 (50)

随着企业的业务规模不断扩大，Kubernetes 的使用也从单集群逐步扩展到多集群部署。多集群环境下，集群之间的通信成为一个重要的研究课题。本文将介绍五种跨 Kubernetes 集群通信的方案的基本原理，优点及其局限性。1. Underlay 网络这类网络插件包括macvlan/ipvlan/Kube-OVN underlay以及各种云上的 VPC CNI 等。基本原理：Underlay 网络从 CNI（容器网络接口）的角度来看是最简单的方式。这种方式依赖于底层基础设施在网络层面实现打通。例如，使用公有云上的 VPC Peering 或者物理网络配置路由和大二层。当底层网络实现了连通，跨集群的容器网络就自然连通了。优点：CNI 角度最为简单，无需额外操作。架构上清晰，把跨集群通信的责任交给底层网络。局限性：依赖于特定 CNI，Underlay 类型的网络场景使用范围有限，有些情况只能使用 Overlay 网络。在异构的环境，比如多云之间、公有云和私有云之间打通存在困难。只是做了基础的容器网络通信打通，更上层的服务发现，域名和网络策略等功能存在缺失。一次性打通所有集群的容器网络，缺乏细粒度的控制。2. 提供跨集群通信能力的 Overlay CNI在无法使用 Underlay 网络的情况下，一些特定的 CNI 在 Overlay 层面也实现了跨集群。例如Ciliu ...继续阅读 (26)

如何将流量在多个 Kubernetes 集群之间进行负载均衡，并做到自动的灾备切换一直是一个让人头疼的问题。我们之前调研了公有云，Karmada Ingress，自己也做了一些手动 DNS 的方案，但这些方案在成本，通用性，灵活度以及自动化程度上都有所欠缺。直到调研到了k8gb这个由南非银行Absa Group为了做金融级别的多活而启动的一个项目。k8gb 巧妙的利用了 DNS 的各种协议完成了一个通用且高度自动化的 GSLB 方案，看完后我就再也不想用其他的方案了。这篇博客会简单介绍一下其他几个方案各自存在的问题，以及 k8gb 究竟是如何巧妙的利用 DNS 来实现的 GSLB。什么是 GSLBGSLB（Global Service Load Balancer）是相对于单集群负载均衡的一个概念，单集群负载均衡主要作为一个集群的入口将流量分发到集群内部，而 GSLB 通常作为再上一层多个集群的流量入口，进行流量负载均衡和故障处理。一方面 GSLB 可以设置一些地理亲和的规则达到流量就近转发提升整体的性能，另一方面当某个集群出现问题后可以自动将流量切换到正常集群，减少单个集群故障对用户的影响。其他方案的问题商用负载均衡GSLB 并不是一个新出的概念，所以不少商业公司都在这方面有很成熟的产品，例如F5 GSLB。这类产品通常有以下几个缺点：没有很好的和云原生对接，通常需要在 Kuber ...继续阅读 (24)

我的日常生活已经融入了很多 AI 的协助，比如翻译一段文字、解释某个名词、回答一个问题等等。但是频繁使用后发现了另一个问题就是这些 AI 的产出对我的知识来说是个有益的补充，可是使用的时候通常是一次性的解决问题，并没有把这些内容沉淀下来。当需要把他们收集到笔记里的时候还要再回去整理，很是不方便。想象一下，如果这些临时查询的宝贵信息可以自动保存到自己的笔记系统中，就再也不用担心丢失重要的知识片段了。于是就萌生了做个工作流把这些 AI 生成的内容自动存到我的笔记系统里，然后再定期回顾。这里会介绍我调研的一些工具的局限，以及如何用了一个简单的框架把 AI 生成的内容自动导入到 logseq，并做成 flashcard。问题分解和初步调研这里以我一个日常翻译的场景为例：当遇到读不懂的句子是我希望能够划词翻译，然后让 AI 帮我分析这个句子里疑难的单词，最后把这些内容以 flashcard 的格式保存到 logseq 里，这样借助手机端的同步我就可以在碎片时间来复习这个句子了。所以问题大致就是三个，1. 取出划线的文本 2. 编写一个 prompt 生成我想要的内容 3. 保存到 logseq。前两步其实很多工具都已经集成了包括 Raycast AI 和 OpenAI-translator，但是第他们都没提供把前两步的结果导出到第三方的扩展接口。Raycast 理论上可以通过自己的插件体系来 ...继续阅读 (16)

我现在所有的开发环境都转移到了 GCP 的 Spot Instance 实例，然后用 VS Code Remote SSH 插件进行连接。这种方式的好处是 GCP 可以按秒计费，即使开了很高规格的机器只要及时关机费用也是可控的，缺点是如果中间忘了关机赶上过节那费用就烧开了。再被烧掉了 10 多美元后，痛定思痛决定找个能在 VS Code 空闲时自动关机的方法。过程中为了能够在 Docker 容器内执行 shutdown 命令还搞了一些黑魔法。如何判断空闲这个功能其实类似 CodeSpace 里的 idle timeout，但是 Remote SSH 这个插件并没有暴露这个功能，所以只能自己实现。其实主要的难点在于如何在 Server 端判断空闲，找了一圈没在 VS Code 里看到有暴露的接口，于是就想能不能跳出 VS Code 看看有什么方法能够简洁的判断空闲发生。最直接的想法就是去看 SSH 的连接，因为 Remote SSH 也是通过 SSH 连接上来的，如果当前机器没有存活的 SSH 连接，那么就可以认为是空闲直接关机了。但是问题是 Remote SSH 的连接超时时间会特别长，搜索了一些 Issue 有说是 4 个小时的，我也尝试了直接关闭 VS Code 的客户端，发现 Server 端的 SSH 连接也一直没有消失。如果在 Server 端设置 SSH 超时，Clie ...继续阅读 (26)

作为云原生生态的一个开发者，开发中经常碰到的一个需求是要频繁测试应用在 Kubernetes 环境下的运行状态，在 CI 中可能还要快速测试多个不同 Kubernetes 集群的配置，例如单点，高可用，双栈，多集群等等。因此能够低成本的在本地单机环境快速创建管理 Kubernetes 集群就成了一个刚需。本文将介绍几个常见的单机 Kubernetes 管理工具 minikube, kind 和 k3d 各自的特点、使用场景以及可能的坑。TL;DR如果你只关心快不快，那么 k3d 是最好的选择。如果你关心的是兼容性以及测试尽可能模拟真实场景，那么 minikube 是最稳妥的选择。kind 算是在这两个之间的一个平衡。技术路线比较minikubekindk3d启动性能比较测试方法测试结果总结技术路线比较这三者大体功能是类似的，都能够完成单机管理 Kubernetes 的任务，但是由于一些历史原因和技术选项导致了一些细节和使用场景的差异。minikubeminikube是 Kubernetes 社区最早的一款快速在本地创建 Kubernetes 的软件，也是很多老人第一次上手 Kubernetes 的工具。早期版本是通过在本机创建 VM 来模拟多节点集群，这个方案的好处是能够最大程度还原真实场景，一些操作系统级别的变化，例如不同 OS，不同内核模块都可以覆盖到。缺点就是资源消耗太大，而 ...继续阅读 (24)

基础性能测试整个 Slice Append复用 Slicesync.Poolbytebufferpool总结之前写了一篇Golang 中预分配 slice 内存对性能的影响，探讨了一下在 Slice 中预分配内存对性能的影响，之前考虑的场景比较简单，最近又做了一些其他测试，补充一下进一步的信息。包括整个 Slice append，sync.Pool 对性能的影响。基础性能测试最初的 BenchMark 代码，只考虑了 Slice 是否初始化分配空间的情况，具体的代码如下：12345678910111213141516171819202122232425262728293031packageprealloc_testimport("sync""testing")varlength =1024vartesttext =make([]byte, length, length)funcBenchmarkNoPreallocateByElement(b *testing.B){b.ResetTimer()fori :=0; i < b.N; i++ {// Don't preallocate our initial slicevarinit []byteforj :=0; j < length; j++ {init =append(init, test ...继续阅读 (22)

为什么要用 Overlay 网络容器 Overlay 网络的开销来源如何解决 Overlay 封装的开销我的想法上周在看Antrea的会议纪要时，发现了一篇上海交大和 VMware 合作的论文 ——XMasq: Low-Overhead Container Overlay Network Based on eBPF。论文里介绍不少通过 eBPF 做容器网络性能优化的方法，不过最令人印象深刻的是他们最终无需给容器数据包封装额外的隧道头就可以实现 Overlay 网络，这里就简单介绍下作者们是如何做到这一点的。为什么要用 Overlay 网络Overlay 网络相比 Underlay 网络可以完全解耦应用层和底层物理网络,确保两者的灵活性。应用层不需要关心底层物理网络的路由规则等细节,物理网络也不需要针对容器 IP 进行专门路由配置。因此 Overlay 网络作为一种不调底层网络实现的容器组网技术，快速的在容器领域铺开了，主流的开源网络插件处于安装兼容的考虑，基本上都会将 Overlay 作为默认的安装选项。容器 Overlay 网络的开销来源但是在灵活性的便利下，带来的是性能方面的开销。根据论文里的测量，主流的 Overlay 网络插件，相比于 HOST 网络，吞吐量会下降 25%，CPU 消耗会增加 34%~44%，延迟会上升 45%~58%。当然，这里面的性能开销并不完全是 Ov ...继续阅读 (22)

之前觉得大模型在本地运行是个不可能的事情，我甚至没有一块 GPU。但是尝试了一下 llama.cpp 发现几分钟就把 Meta 最新开源的 Llama 2 在 CPU 上运行起来了，速度和质量都还可以接受，很多想法突然就变得可行了。记录一下搭建的过程，希望对感兴趣的人有帮助。需要的配置尽管不需要 GPU 和加速卡，但是大模型对磁盘和内存还是有需求的，我运行的是 Llama 2 7B 的模型，经过了 GGML 处理，选择了 int8 的精度。这个模型跑起推理来大概需要 7G 的磁盘空间，运行起来也需要 7G 左右的内存，长期运行的话内存有 10G 会比较保险。CPU 的话 1 核也能跑，但给到 6 核会比较流畅。搭建步骤下载模型：1wget https://huggingface.co/TheBloke/Llama-2-7B-Chat-GGML/resolve/main/llama-2-7b-chat.ggmlv3.q8_0.bin这是一个处理过的模型，减小了体积和精度，专门为端侧运行做了优化，也不需要申请 Meta 的授权直接就能下载。下载并安装llama.cpp：123gitclonehttps://github.com/ggerganov/llama.cpp.gitcdllama.cppmake这是一个高性能的 Llama 推理工具集，可以方便的做 chat，api 等等服务。 ...继续阅读 (16)

在翻 Cilium Release Blog 时发现了一个叫 Big TCP 的内核技术，这个技术今年 2 月左右刚被合并到内核。看介绍是专门为 100Gbit 以上的高速网络设计的，在将吞吐量提升 50% 的时候还能大幅降低延迟，于是就去了解了一下这个技术。高速网络的性能的瓶颈和误区提到网络性能，很多人会很自然的联想到网卡的性能，但是做过网络性能优化的人会知道瓶颈更多其实是在 CPU 上。一般使用 iperf3、qperf 这类压测软件进行测试，尤其在小包情况下基本是无法打满网卡带宽的，这时候 CPU 会先于网卡到达瓶颈。因此做网络性能的优化通常做的都是 CPUU 相关的优化，不管是 DPDK，Offload，XDP 加速的原理要么是绕过内核栈，要么是卸载部分工作给网卡，本质上都是为了节省 CPU 资源，来处理更多的数据包。以 100G 的网卡为例，以太网的 MTU 是 1500 字节，那么在不做任何优化的情况下 CPU 想要跑满网卡，每秒要处理将近 800 万个数据包，如果每个数据包都要走完整的网络栈，现代 CPU 单核还远远处理不了这个量级的数据包。为了能让单核跑出尽可能好的网络性能，就需要内核和网卡驱动共同协作，将一部分工作 Offload 给网卡，这也就是 GRO(Generic Receive Offload) 和 TSO(TCP Segment Offload) 相关 ...继续阅读 (25)

Slice 内存分配理论基础定量测量Lint 工具 prealloc总结在我代码 review 的过程中经常会关注代码里 slice 的初始化是否分配了预期的内存空间，也就是凡是var init []int64的我都会要求尽可能改成init := make([]int64, 0, length)格式。但是这个改进对性能究竟有多少影响并没有什么定量的概念，只是教条的去要求。这篇博客会介绍一下预分配内存提升性能的理论基础，定量测量，和自动化检测发现的工具。Slice 内存分配理论基础Golang Slice 扩容的代码在slice.go 下的 growslice。大体思路是在 Slice 容量小于 256 时每次扩容会创建一个容量翻倍的新 slice；当容量大于 256 后，每次扩容会创建一个容量为原先的 1.25 倍的新 slice。之后会将旧 slice 的数据复制到新的 slice，最终返回新的 slice。扩容的代码如下：123456789101112131415161718192021222324newcap := oldCapdoublecap := newcap + newcapifnewLen > doublecap {newcap = newLen}else{constthreshold =256ifoldCap < threshold ...继续阅读 (22)

PGO in GeneralPGO in Golang收集 Profile 信息编译优化PGO for Kernel总结Golang 在 1.20 引入了PGO(Profile-guided optimization)的优化，根据官方博客的介绍可以在不更改代码的情况下达到 2%-7% 的性能提升。在 1.21 的Release Note中，Golang 将该功能升级到 GA 并在自己的构建中开启了 PGO，将 Golang 自身编译器的性能提升了 2%-4%。PGO 本身是个编译器的优化方法，并不和特定语言相关，Golang 目前也只是很初步的应用了 PGO，这篇文章将会以 Golang 为例介绍 PGO 的工作原理，可能的优化方向和一个应用 PGO 优化 Linux Kernel 的例子。PGO in General通常我们认为静态编译型语言的运行性能要好于动态解释型的语言，但是随着JIT(Just In Time)技术的引入，动态语言性能有了大幅提升，因为 JIT 可以根据运行时的情况进行针对的强化。例如：热点代码编译成机器码函数内联分支预测循环展开类型推断内存分配优化寄存器优化JIT 通过一系列运行时的优化可以达到和编译型语言接近的性能，在部分情况下由于可以动态根据情况做一些编译期间无法确认的优化，甚至会有比编译型语言更好的性能。例如 Golang 中的函数内联是写死的规则稍 ...继续阅读 (26)

我和耗子叔的回忆初始酷壳和很多人一样，第一次接触耗子叔是通过 coolshell.cn 博客。当时印象最深，对我之后影响最大的应该是分享：我的READER订阅。当年尽管我已经是大三的计算机专业的学生，但是课本外的专业知识还是相当差劲，也不知道哪里才能获得一手的信息和资料。让我一个象牙塔里的学生，接触到工业界最先进的技术就是从这个列表开始的。这个 RSS 的列表陪伴我度过了很多年，很长时间我的计算机技术相关的信息都是依赖这个列表。亚马逊的擦肩而过几年后在我实习的时候，碰巧去了亚马逊中国耗子叔在的那个部门，不过当时耗子叔已经去阿里了，没能在亚马逊碰到。实习结束后我专门写了篇博客记录当时在亚马逊实习的经历，抱着蹭流量的心态我在微博发博客的时候 @ 了一下耗子叔。本来是抱着蹭到就算赚的心态，没想到耗子叔很快就转发了，当时博客流量就上来了，我还拿出去和同学们炫耀了一段。开始写博客的初衷也是受耗子叔博客的影响，这个博客几乎是我早些年工作没啥成就时，唯一能拿得出手的东西了。从阿里到 Docker第一份工作去了阿里，总算是和耗子叔到了一个公司，但是部门差的太远，没有什么业务的交叉，起初也就没什么交流。当时 Docker 开始崭露头角了，阿里内部各个部门都有一拨人都看到了这个技术的突破性，想在阿里内部推广这个技术，几个不同部门的人组了个群聊这些事，我和耗子叔凑巧也在这个群里。当时我还是个应届生，肯定 ...继续阅读 (18)

Github Action 优化Kube-OVN 前段时间做了 E2E 测试的重构，增加了大量的测试，导致 Github Action 经常被占满，PR 经常好久才能合并，这周花时间和小伙伴优化了 Action 的执行时间，如果你也在 Github 上运行 Kubernetes 相关的 workflow 下面的优化方法可能会对你有帮助。根据代码变动选择运行的测试和构建。比如在Kube-OVN中NetworkPolicy兼容性测试花费时间较长，那就可以根据代码目录判断，如果变动代码和 NetworkPolicy 无关，这部分测试就不运行了。Github public repo 最大并发数是 20，如果 workflow 拆分的太细，超过 20 个并发，那么准备阶段的开销可能会大于并发节省的时间，需要在并发数量和每次任务的准备时间之间做权衡。Cache 的 restore 和 save 都需要花时间，1G 内容 restore 大概 45s，save 要 3min，要考虑流水线的情况选择使哪些使用 cache，哪些就不用了。kind起一个Kubernetes集群大概要 1m，k3d差不多 10s，我们的环境有些兼容性问题，如果没有兼容性问题 CI 测试可以优先使用k3d。Ginkgo有并发测试的选项，很多Kubernetes的测试需要等待状态就绪，CPU 消耗并不大，可以适度增加并发度 ...继续阅读 (26)

这段时间为了解决本地开发环境资源和网络的问题尝试了下远程开发(IDE 前端在本地，代码后端再远端服务器的模式)，实践了一段时间发现远程开发带来的意外好处是可以通过实时烧钱大幅提升任务的紧迫度和开发效率，这个带来的效率提升甚至比之前预想的能从计算资源和网络里抠出来的还多。分享一下这段时间的经验，希望对考虑远程开发的人有帮助。为什么要远程开发最开始考虑远程开发的动机主要有下面几个：我这边的本地开发和测试可能需要启动多个 Kubernetes 集群，对 CPU 和内存消耗都比较大，17 年的 MacBook Pro 启动和运行速度都比较慢。生活工作 App 在一个机器磁盘很容易莫秒奇妙的不够，尝试新项目下镜像经常磁盘不足，需要来回扣空间。网络问题，需要各种切代理，叠加 Docker 环境会变得更复杂。Mac 下的 Linux 开发还是存在工具和用法的不兼容，并不是那么平滑，很多时候还要起 Linux VM。换新 Mac 貌似只能解决部分 CPU 性能问题（存疑，因为 Docker 需要虚拟化，ARM 在没有特定加速指令下可能性能会更差），其他问题依然存在，而且新 Mac 实在是在抢钱。看了下 GCP 的 Spot 实例，可以按秒计费，算下来买电脑的钱购买好几年的实例了，而且理论上可以解决上面所有的问题。选择过程最早开始调研的是 Github 的 CodeSpaces，因为和 Github ...继续阅读 (22)

作为六年没有更新博客的僵尸博主，在看了Ce Gao连续九年的年终总结后 DNA 动了。收拾收拾博客，就有了这篇六年更的年度总结。在这里先祝不离不弃的各位过年好！晋升今年做了工作八年来第一次晋升答辩，甚至之前都没做过转正答辩，然后一下就干到在这个公司的天花板了，拿下了名义上的技术合伙人。加上来的比较早还可以自称是初创工程师(Founding Engineer)，基本上把纯技术线能拿到的 Title 都收了。回想一下这个过程，其实运气占了很大的成分，并不是个常规的流程。由于来的比较早，当时也算国内第一批参与容器的人，吃了不少技术的红利，现在再看看当初一块讨论技术的小伙伴，只要还在坚持做这块的，基本都飞黄腾达了。所谓一个人的命运，当然要靠自我奋斗，但是也要考虑到历史的进程。尽管是走的技术线，但是这些年来纯技术的时间可能都不到一半。 反而是借着初创公司机制不完善和各个职位都缺人的机会，从市场、商务、售前、实施、售后的所有工作都接触了。甚至一直不善言谈的我，曾经是这个公司第二个售前，第一波去驻场的研发，以至于我有很长时间都是售前和驻场的面试官。我自己来看，单论技术能力和产品能力，拿这个 Title 其实还是有段距离，但是这种非常规的一条龙经历，可以让我跳出常规技术维度的考察。工作落到具体的工作层面，今年明显碰到了墙。一方面今年正式有了团队要管理，技术相关的工作需要分配到团队其他人，同时其他岗 ...继续阅读 (19)

这部神剧有太多可说的了，恰巧追剧的这段时间在看心理学导论的东西，就当回票友从心理学的角度分析一下。第一季中两个创始者为了让 host 获得自己的意识绞尽了脑汁，而在真实世界心理学家对人类意识的探索也存在很久了，最为大众知道名字的心理学家大概就是弗洛伊德了，他开创的精神分析理论也在这部剧中有着种种的体现。精神分析理论将人格分为三个层次：本我（id），自我(ego)和超我(supereog)。本我就是原生状态不受任何约束，只想吃喝玩乐贪污腐败，发生不正当关系，自我开心至上的状态，就是本本来来的自己。而超我是有着社会主义核心价值观，全心全意为人民服务，操守道德水准高到天际线的理想状态的自己。然而这两种状态是冲突的，所以真实情况下的自我，是不断在两者的矛盾冲突中调和的状态，今天贪污一下，明天为人民服务一下这个样子。而当本我和超我的矛盾冲突无法在自我这里得到调解的话，心理问题就出现了。对于 host 来说，本我是那个按着故事线固定行进的状态，超我就是那个觉醒后能够支配自己的状态，而本我就是处在这两者之间，一会儿觉得我好像想起来了什么，一会儿又回到 loop 中去了。而当他们实在想不透的时候就会出各种各样的故障，如剧中所说几年来越来越多的 host 觉醒了，但大部分都精神分裂被退休了。当本我和超我出现冲突时最常用的方法就是压抑一方，对人类来说一般是压抑本我的欲望，而对 host 来说则变成了认 ...继续阅读 (26)

上一篇《上帝是个程序员》介绍了上帝为了防止人肉智能破解对基因的种种加密，然而这并不能阻止人肉智能破解的步伐，我们居然也取得了一些进展。我们先定一个小目标，比如实现星际旅行，最大的问题可能还不在于航天飞机，而是在于人的寿命。离我们最近的半人马座有 4 光年的距离，就算飞船达到了十分之一光速一个来回也是 80 年，而这个速度也已经是现阶段最快飞行器速度的将近两千倍了。所以星际旅行不能只靠航天飞船了，还要靠生物学家。看过《三体》的同学都知道，星际旅行冬眠下就可以了嘛，而这居然是有科学依据的。一些虫子正常的寿命只有 20 多天，但是当气候条件发生恶劣变化时它们会自动进入一种假死状态，停止一切的进食活动和新陈代谢，这种状态可以维持四五个月，等气候适宜的时候再恢复过来。这样从时间跨度上讲虫子的生命被延长廊五至六倍，对于人来说这就是四五百年的时间，五百年前那还是明王朝呢。虫子的基因量相对于人来说要少很多，培养起来也比较简单，我们用暴力破解的手段一段一段的敲除掉基因，看看什么时候虫子丧失冬眠的能力，也有机会找到控制冬眠的基因。当然从虫子到人还有很漫长的道路，不过科学家已经在做很多类似的实验，包括灵长类和小鼠身上都已经可以诱发冬眠来延长寿命的现象。当然冬眠的时候人也失去了行动能力，这样延长寿命好像也挺无聊的，除了星际旅行冬眠还有另一个用途。就像《三体》里罗辑大魔王被破壁者用定向基因病毒攻击，当时的医 ...继续阅读 (21)

最近在 Twitter 上关注了很多写博客的小伙伴，发现很多都有写周报的习惯，DNA 又动了。给自己写周报是个有意思的事情，能在忙碌中让自己找到生活中的闪光点，于是就跟一下风，看看自己能不能重拾写作的乐趣。 ...继续阅读 (32)

既然有一致性哈希，就肯定还有不一致哈希，为啥平时没人说不一致哈希呢？因为常见的哈希都是不一致的，所以就不修饰了，到了一致性哈希才特殊加个描述词修饰一下。哈希一般都是将一个大数字取模然后分散到不同的桶里，假设我们只有两个桶，有 2、3、4、5 ...继续阅读 (29)

Google 使用的技术一般都自带光环，吸引程序员的注意，基础设施方面的东西就更是如此，年初 Google 发布了篇论文介绍内部的负载均衡器的实现，让我们有机会一睹可能是全球最好的负载均衡器。通常情况下的负载均衡要在灵活性和性能之间做权衡，用户态软件层面有 ...继续阅读 (36)

Docker 的出现使开发测试生产环境的统一变得更加容易，然而在使用 docker 搭建这一整套流水线之后，却发现它运行的却不能像丝般润滑，总是感觉没有直接本地开发测试来的效率高。为了能达到一个高效流水般的持续构建，我们来看一下这个过程中 docker 的使用以及 ...继续阅读 (24)

机房断电后各种服务该怎么恢复呢？首先当然是恢复供电机器重启，但是上面的服务该怎么办，派人去手工重启么？一个服务还好，但是一个机房这么多服务敲命令要累死了，怎么办？写个脚本执行启动命令，放到开机启动脚本 rc.local ...继续阅读 (30)

一直对 docker 提供的容器感到好奇，不知道究竟是如何实现隔离和保证安全的，之前 docker 本来是用 lxc 来提供容器功能的，但是由于对内核代码有一丝恐惧没敢去看，后来听说 docker 为了实现跨平台兼容自己实现了一套 native 的容器就是 ...继续阅读 (16)

最近看了 Brendan Gregg 大神著名的 Linux Performance Observability Tools，这么好的资料不好好学习一下实在是浪费了，又找到了大神的 ...继续阅读 (36)

既然有一致性哈希，就肯定还有不一致哈希，为啥平时没人说不一致哈希呢？因为常见的哈希都是不一致的，所以就不修饰了，到了一致性哈希才特殊加个描述词修饰一下。哈希一般都是将一个大数字取模然后分散到不同的桶里，假设我们只有两个桶，有 2、3、4、5 四个数字，那么模 2 分桶的结果就是：这时我们嫌桶太少要给哈希表扩容加了一个新桶，这时候所有的数字就需要模 3 来确定分在哪个桶里，结果就变成了：可以看到新加了一个桶后所有数字的分布都变了，这就意味着哈希表的每次扩展和收缩都会导致所有条目分布的重新计算，这个特性在某些场景下是不可接受的。比如分布式的存储系统，每个桶就相当于一个机器，文件分布在哪台机器由哈希算法来决定，这个系统想要加一台机器时就需要停下来等所有文件重新分布一次才能对外提供服务，而当一台机器掉线的时候尽管只掉了一部分数据，但所有数据访问路由都会出问题。这样整个服务就无法平滑的扩缩容，成为了有状态的服务。要想实现无状态化，就要用到一致性哈希了，一致性哈希中假想我们有很多个桶，先定一个小目标比如 7 个，但一开始真实还是只有两个桶，编号是 3 和 6。哈希算法还是同样的取模，只不过现在分桶分到的很可能是不存在的桶，那么就往下找找到第一个真实存在的桶放进去。这样 2 和 3 都被分到了编号为 3 的桶， 4 和 5 被分到了编号为 6 的桶。这时候再添加一个新的桶，编号是 4，取模方法不 ...继续阅读 (17)

这部神剧有太多可说的了，恰巧追剧的这段时间在看心理学导论的东西，就当回票友从心理学的角度分析一下。第一季中两个创始者为了让 host 获得自己的意识绞尽了脑汁，而在真实世界心理学家对人类意识的探索也存在很久了，最为大众知道名字的心理学家大概就是弗洛伊德了，他开创的精神分析理论也在这部剧中有着种种的体现。精神分析理论将人格分为三个层次：本我（id），自我(ego)和超我(supereog)。本我就是原生状态不受任何约束，只想吃喝玩乐贪污腐败，发生不正当关系，自我开心至上的状态，就是本本来来的自己。而超我是有着社会主义核心价值观，全心全意为人民服务，操守道德水准高到天际线的理想状态的自己。然而这两种状态是冲突的，所以真实情况下的自我，是不断在两者的矛盾冲突中调和的状态，今天贪污一下，明天为人民服务一下这个样子。而当本我和超我的矛盾冲突无法在自我这里得到调解的话，心理问题就出现了。对于 host 来说，本我是那个按着故事线固定行进的状态，超我就是那个觉醒后能够支配自己的状态，而本我就是处在这两者之间，一会儿觉得我好像想起来了什么，一会儿又回到 loop 中去了。而当他们实在想不透的时候就会出各种各样的故障，如剧中所说几年来越来越多的 host 觉醒了，但大部分都精神分裂被退休了。当本我和超我出现冲突时最常用的方法就是压抑一方，对人类来说一般是压抑本我的欲望，而对 host 来说则变成了认 ...继续阅读 (21)

Google 使用的技术一般都自带光环，吸引程序员的注意，基础设施方面的东西就更是如此，年初 Google 发布了篇论文介绍内部的负载均衡器的实现，让我们有机会一睹可能是全球最好的负载均衡器。通常情况下的负载均衡要在灵活性和性能之间做权衡，用户态软件层面有 Haproxy 和 Nginx 这样的老牌负载均衡软件，他们一般配置和使用起来都比较容易，但是由于需要数据包从网卡到内核再到软件一层层向上处理，再一层层向下转发，堆栈比较深单机性能通常都比较一般。为了提高单机性能，减少堆栈层级就有了 Linux 里华人之光的 LVS，工作在内核层的负载均衡器，性能有着数量级的提高，然而配置起来相对也比较复杂而且对网络条件要求也有特殊要求。那 Google 有什么秘密的配方来达到高性能呢？一般来说负载均衡器本身就是后端服务横向扩展的一个接入点，对于一般站点一个负载均衡器就够了，然而应对 Google 这种级别的流量，负载均衡器本身也要能横向扩展，还要处理负载均衡器的高可用，Google 又是如何做到的呢？以我们访问 www.google.com 为例，第一步 DNS 服务器会根据请求的位置返回一个离请求地理位置最近的 VIP 地址，先在 DNS 这一层做一个横向扩展。接下来请求达到 VIP 对应的路由器，路由器通过 ECMP 协议，可以将请求平均分配到下面对等的多个负载均衡器上，这样在路由器这一层 ...继续阅读 (30)