首页 (34) - 码厩

#734 Bing 打不开了

互联网 Bing 搜索引擎 2021-12-17

Bing 是我的默认搜索引擎。但是今天早上发现 Bing 打不开了，只有通过特殊手段才行。

应监管部门要求，Bing 需要在 30 天内对搜索框的建议功能做出整改，看到很多网友贴出了公告。
https://www4.bing.com 目前可用 (随时会挂)
切换到谷歌 DNS 之后，Bing 可以正常访问

Update @ 2021-12-19: 必应搜索恢复正常访问（持续时间大约 2 天）。

#733 K8S 核心概念

K8S 2021-12-17

Kubernetes (K8S) 可以通过以下方式判断每个容器需要的资源情况，然后据此进行调度：

可以根据容器所需资源情况调度：

定义 Pod 的资源需求和限制：可以在 Pod 的 YAML 文件中定义每个容器的资源需求和限制，包括 CPU 和内存。
这样 Kubernetes 调度器就可以根据这些需求来选择节点和分配资源。
监测容器资源使用情况：Kubernetes 可以通过 kubelet 代理监测每个容器的资源使用情况，包括 CPU 和内存使用率。
这样 Kubernetes 调度器就可以根据容器的实际资源使用情况来调整 Pod 的调度策略。
自动伸缩 Pod：Kubernetes 还可以根据容器的资源使用情况自动伸缩 Pod 的数量。
可以通过 Horizontal Pod Autoscaler (HPA) 来设置 Pod 的最小和最大副本数，以及触发自动伸缩的 CPU 和内存使用率阈值。
节点亲和性和反亲和性：Kubernetes 可以通过节点亲和性和反亲和性来指定容器在哪些节点上运行，以及在哪些节点上不运行。
可以通过节点标签和 Pod 标签来实现亲和性和反亲和性。

一、K8S 架构概述

K8S 采用主从架构，主要由控制平面（Control Plane）和工作节点（Worker Nodes）构成，这种架构设计使得系统具有良好的可扩展性和稳定性。

控制平面（Master）：作为 K8S 集群的“大脑”，负责全局决策和管理，包含多个关键组件。
- API Server：是 K8S 的核心接口，提供了一套 RESTful API，用户、客户端工具以及其他组件都通过它来与集群进行交互，实现对集群资源的操作和管理。
- etcd：用于存储集群的配置信息和状态数据，是一个高可用的键值存储数据库，保证了数据的一致性和持久性。
- Controller Manager：包含多个控制器，如节点控制器、副本控制器等，它们负责监控集群状态，并根据期望状态进行调整，确保集群始终处于稳定运行状态。
- Scheduler：负责将待部署的 Pod 调度到合适的工作节点上，它会根据节点的资源情况、Pod 的需求等因素进行综合考量，以实现资源的最优分配。
工作节点（Node）：是运行应用容器的实际服务器，可以是物理机或虚拟机，每个节点都运行着一些必要的组件。
- Kubelet：作为节点上的代理，负责与控制平面通信，接收并执行 Pod 的部署任务，同时监控容器的运行状态。
- Kube Proxy：实现服务的网络代理功能，负责将服务的访问请求转发到相应的 Pod 上，确保服务的可访问性。
- 容器运行时（Container Runtime）：用于运行容器，常见的有 Docker、containerd 等。

二、核心资源对象

在 K8S 中，一切皆为资源对象，通过操作这些对象来管理应用。

Pod：是 K8S 中最小的部署单元，它可以包含一个或多个紧密相关的容器。这些容器共享网络和存储资源，通常作为一个整体被调度和管理。例如，一个 Web 应用 Pod 可能包含 Web 服务器容器和日志收集容器。
Service：定义了一组 Pod 的访问规则，为这些 Pod 提供了一个稳定的网络接口。无论 Pod 如何动态变化，Service 都能确保客户端可以通过固定的 IP 和端口访问到服务。Service 有多种类型，如 ClusterIP（仅在集群内部可访问）、NodePort（通过节点端口暴露服务）、LoadBalancer（使用云服务商的负载均衡器）等。
Deployment：用于管理 Pod 的部署和更新，它定义了 Pod 的期望状态，包括副本数量、镜像版本等。通过 Deployment，可以轻松实现应用的滚动更新、回滚等操作，确保服务的高可用性。例如，当需要更新应用版本时，Deployment 会逐步替换旧的 Pod，而不会导致服务中断。
ReplicaSet（RS）：确保指定数量的 Pod 副本始终处于运行状态，它是 Deployment 的底层实现。通常情况下，我们通过 Deployment 来间接管理 ReplicaSet，而不是直接操作 ReplicaSet。
StatefulSet：与 Deployment 不同，StatefulSet 用于管理有状态的应用，如数据库。它能保证 Pod 的顺序性和唯一性，为每个 Pod 提供稳定的标识符和持久化存储，确保应用在重启或迁移后能够恢复到正确的状态。
DaemonSet：确保每个节点上都运行一个指定的 Pod 副本，常用于部署系统监控、日志收集等需要在每个节点上运行的服务。例如，Prometheus Node Exporter 就可以通过 DaemonSet 部署到每个节点上，以收集节点的性能指标。
Job/CronJob：Job 用于执行一次性的任务，当任务完成后，Pod 会被自动终止。CronJob 则用于定时执行任务，类似于 Linux 系统中的 cron 任务，例如每天凌晨备份数据库就可以通过 CronJob 来实现。
Namespace：用于在逻辑上划分集群资源，不同 Namespace 中的资源相互隔离。它可以帮助多个团队或项目在同一个集群中共享资源，同时又不会相互干扰。例如，开发环境和生产环境可以分别使用不同的 Namespace。
ConfigMap/Secret：用于存储配置信息和敏感数据，如应用的配置文件、数据库密码等。通过将这些信息与容器镜像分离，可以在不修改镜像的情况下，灵活地更新应用的配置。ConfigMap 用于存储非敏感的配置信息，Secret 则用于存储敏感信息，并且会对数据进行加密存储。
Volume：为 Pod 提供持久化存储，它可以是本地存储、网络存储（如 NFS、Ceph）等。Volume 使得容器在重启后仍然可以访问到之前的数据，保证了数据的持久性。例如，数据库 Pod 可以使用 Volume 来存储数据文件。

三、关键术语与机制

标签（Label）与选择器（Selector）：标签是附着在资源对象上的键值对，用于对资源进行分类和标识。选择器则用于根据标签筛选资源对象，是 Service、Deployment 等组件关联 Pod 的重要方式。例如，一个 Service 可以通过标签选择器找到所有具有特定标签的 Pod，并将流量转发给它们。
控制器（Controller）：K8S 中的核心组件，通过持续监控资源的实际状态与期望状态的差异，并进行调整，来实现集群的自修复能力。除了前面提到的 Deployment、ReplicaSet 等控制器，还有 NodeController、ServiceController 等。
声明式 API：K8S 采用声明式 API，用户只需定义资源的期望状态，而无需关心具体的实现过程。系统会自动将实际状态调整为期望状态，这种方式大大简化了应用的部署和管理。例如，用户只需要编写一个 Deployment 的 YAML 文件，指定 Pod 的副本数量和镜像版本，K8S 就会自动创建和管理这些 Pod。
服务发现与负载均衡：K8S 内置了服务发现机制，Service 会自动注册和发现相关的 Pod。同时，Service 还提供了负载均衡功能，将客户端的请求均匀地分发到多个 Pod 上，提高了服务的可用性和性能。
自动扩缩容（HPA/VPA）：Horizontal Pod Autoscaler（HPA）可以根据 CPU、内存等指标自动调整 Pod 的副本数量，以适应应用的负载变化。Vertical Pod Autoscaler（VPA）则可以根据 Pod 的资源使用情况自动调整其资源请求和限制。
滚动更新与回滚：Deployment 支持滚动更新，在更新过程中，会逐步替换旧的 Pod，同时保持服务的正常运行。如果更新出现问题，还可以快速回滚到之前的稳定版本，确保服务的可靠性。

四、新人入门建议

搭建本地环境：使用 Minikube 或 Docker Desktop 搭建本地 K8S 集群，便于动手实践，加深对概念的理解。
学习 YAML 配置：K8S 主要通过 YAML 文件来定义资源对象，熟练掌握 YAML 的语法和结构是非常重要的。
动手实践：从部署简单的应用开始，如 Nginx、MySQL 等，逐步熟悉 Pod、Service、Deployment 等资源的创建和管理。
阅读官方文档：K8S 的官方文档非常详细，是学习的重要资料。可以从入门指南开始，逐步深入学习各个概念和功能。
参与社区：K8S 社区非常活跃，可以通过论坛、博客、社交媒体等渠道与其他开发者交流，获取经验和解决问题。

和 Docker 生态的对比

和虚拟化生态（KVM / OpenStack）的对比

本质是计算机资源的隔离和管理，单技术原理和应用场景有显著差异：

一、核心技术定位对比

维度	KVM/OpenStack 虚拟化生态	K8S 容器编排
资源抽象层级	基于硬件虚拟化（CPU、内存、磁盘），抽象出虚拟机（VM）	基于操作系统级虚拟化，抽象出容器（Container）
隔离粒度	操作系统级隔离（每个 VM 有独立内核）	进程级隔离（共享宿主机内核）
核心目标	实现物理服务器资源的池化与虚拟机管理，支持传统应用迁移	解决容器化应用的规模化部署与微服务管理
典型场景	企业传统应用上云、虚拟机集群管理、私有云基础设施建设	云原生应用开发、微服务架构、弹性伸缩场景

二、技术架构与实现原理

虚拟化生态（KVM/OpenStack）
- KVM（Kernel-based Virtual Machine）
  - 定位：Linux 内核原生支持的硬件虚拟化技术，属于 Type 1 hypervisor（裸金属虚拟化）。
  - 核心组件：
    - KVM 模块：运行在宿主机内核中，负责创建和管理虚拟机（VM）。
    - QEMU：模拟虚拟机的硬件设备（如网卡、磁盘），与 KVM 协同工作。
    - VM：包含独立的操作系统、应用程序和配置，通过镜像（如 qcow2）存储。
  - 隔离机制：通过 CPU 虚拟化（Intel VT-x/AMD-V）、内存分页技术（EPT/MMU）实现硬件资源隔离，每个 VM 拥有独立内核。
- OpenStack
  - 定位：开源云计算管理平台，用于编排虚拟化资源（VM、网络、存储），构建私有云或公有云。
  - 核心组件：
    - Nova：计算节点管理，负责 VM 的创建、调度和生命周期管理。
    - Neutron：网络服务，为 VM 提供虚拟网络功能（如 IP 分配、负载均衡）。
    - Cinder/Glance：存储与镜像服务，管理 VM 的持久化存储和镜像分发。
  - 特点：通过 API 接口实现对 KVM 等 hypervisor 的统一管理，支持大规模 VM 集群的资源调度。
- K8S 与容器技术
  - 核心架构（与虚拟化的关联）：
    - 节点（Node）：可以是物理服务器或虚拟机（VM），K8S 不关心底层基础设施，仅要求节点运行容器运行时（如 Docker、containerd）。
    - 容器隔离：基于 Linux 命名空间（Namespace）隔离进程空间，通过控制组（Cgroup）限制资源使用，共享宿主机内核，因此资源占用远低于 VM。
    - 编排能力：通过 YAML 声明式配置，实现容器化应用的自动部署、扩缩容和故障恢复，无需手动管理底层服务器。

三、关键特性对比详解

资源占用与性能
- 虚拟化（KVM）：
  - 每个 VM 需加载独立操作系统内核，内存占用通常为数百 MB 到数 GB（如 Ubuntu VM 至少占用 512MB 内存）。
  - 启动时间以秒为单位（10~30 秒），性能接近物理机（因硬件虚拟化开销较小）。
- 容器（K8S）：
  - 容器共享宿主机内核，内存占用可低至 10MB（如 Alpine 镜像的容器）。
  - 启动时间毫秒级（100ms 内），适合快速启停和弹性扩缩容（如应对突发流量）。
隔离性与安全性
- 虚拟化：
  - 隔离性强，VM 之间完全隔离（包括内核、驱动），一个 VM 的故障不会影响其他 VM。
  - 安全性高，适合多租户环境（如公有云），可通过硬件虚拟化技术（如 Intel SGX）增强隔离。
- 容器：
  - 隔离性较弱，依赖宿主机内核的安全性（若内核存在漏洞，可能导致容器逃逸）。
  - 安全性需通过额外机制增强（如 Seccomp、AppArmor 限制容器权限），更适合同租户内的微服务隔离。
部署与管理复杂度
- OpenStack + KVM：
  - 部署复杂，需配置计算、网络、存储等多个组件，运维门槛高（如 Neutron 网络配置易出错）。
  - 管理 VM 时需手动配置镜像、网络策略、存储挂载，适合静态资源分配场景（如固定业务负载）。
- K8S：
  - 声明式管理，通过 YAML 定义应用“期望状态”（如副本数、资源限制），系统自动实现。
  - 支持应用级灰度发布、滚动更新，无需停机即可升级服务，适合快速迭代的互联网应用。
应用迁移与兼容性
- 虚拟化：
  - 适合传统单体应用上云，无需修改代码即可迁移（如 Windows 应用通过 VM 运行）。
  - 对 legacy 应用兼容性好，但资源利用率低（如单台物理机运行多个低负载 VM）。
- 容器：
  - 要求应用支持容器化改造（如拆分微服务、无状态设计），传统应用需重构才能发挥优势。
  - 资源利用率高（单节点可运行数百个容器），但对有状态应用（如数据库）的支持需额外存储方案。

四、适用场景对比

推荐使用虚拟化（KVM/OpenStack）的场景：
- 传统企业应用迁移：如 ERP、OA 等单体应用，无法容器化改造，需通过 VM 保留原有运行环境。
- 多租户公有云/私有云：需强隔离性的场景（如金融、政府行业），避免租户间资源冲突或安全漏洞。
- GPU 等特殊硬件管理：通过 VM 独占 GPU 资源（如深度学习训练），KVM 支持更成熟的硬件直通技术。
- 长生命周期服务：如数据库集群、中间件服务，无需频繁启停，更关注稳定性而非弹性。
推荐使用 K8S + 容器的场景：
- 云原生微服务架构：如电商平台、社交应用，拆分为多个微服务，通过 K8S 实现自动调度和故障恢复。
- 弹性伸缩与峰值流量：如双十一促销、直播平台，支持秒级扩缩容 hundreds of Pod，按需分配资源。
- CI/CD 与快速迭代：开发测试环境中，容器镜像可快速构建部署，配合 K8S 的滚动更新实现持续交付。
- 资源利用率优先场景：如云计算厂商的 Serverless 服务，通过容器高密度部署提升硬件利用率。

五、技术协同与混合部署

K8S 与虚拟化并非对立，而是常以混合形态存在：

K8S 运行在虚拟机上：
- 多数生产环境中，K8S 集群的节点本身是 VM（如通过 OpenStack 创建），利用 VM 的隔离性实现集群资源的安全划分。
- 例如：企业用 OpenStack 构建私有云，在 VM 上部署 K8S，既享受 VM 的稳定性，又利用 K8S 管理容器化应用。
容器与 VM 的互补场景：
- VM 运行有状态服务：如数据库、大数据集群，利用 VM 的强隔离性保障数据安全。
- 容器运行无状态服务：如 Web 前端、API 服务，通过 K8S 实现弹性扩缩容。
新型技术融合：
- Kata Containers：结合 VM 和容器优势，用轻量级 VM 包裹容器，实现“容器的便捷性 + VM 的隔离性”，适合对安全性要求高的容器场景。
- OpenStack 对 K8S 的支持：OpenStack 社区推出 Magnum 组件，支持在 OpenStack 上部署 K8S 集群，简化云原生应用的基础设施管理。

六、技术演进与未来趋势

虚拟化的定位：从“通用计算平台”转向“特殊场景刚需”，如强隔离、传统应用兼容、硬件直通等领域仍不可替代。
K8S 的扩张：成为云原生时代的“操作系统”，不仅管理容器，还通过 Project Krustlet 等项目尝试管理 VM、物理机等异构资源。
混合架构常态化：企业 IT 环境将同时存在 VM 和容器，K8S 可能成为统一的资源编排层，而 OpenStack 专注于基础设施虚拟化。

#732 Tornado 正在死亡

Tornado 2021-12-16

2020 年 10 月发布的 6.1，结果到现在，已经一年多过去了，6.2 还没有见到。
Update @ 2022-04-28: 又过去了小半年，6.2 还是没有影子。

从 GitHub 提交频率图上明显可以看到 Tornado 的活跃度大幅下滑，2020 年的提交已然不多，2021 年更加惨不忍睹。

官方协程框架 AsyncIO 的诞生，标志着 Tornado 的历史使命已经完成。

是时候带着对 Tornado 的回忆，全面转投原生协程生态了。

#731 plocate

Linux 命令行 2021-12-15

Fedora 36 将采用 plocate 替代 mlocate 成为默认的查找索引，据说更快。
而且 Debian 也早采纳了 plocate。

官网: https://plocate.sesse.net/
代码仓库: https://git.sesse.net/?p=plocate;a=tree

安装

apt show plocate
# Package: plocate
# Version: 1.1.8-2
# Priority: optional
# Section: universe/utils
# Origin: Ubuntu
# Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
# Original-Maintainer: Steinar H. Gunderson <sesse@debian.org>
# Bugs: https://bugs.launchpad.net/ubuntu/+filebug
# Installed-Size: 510 kB
# Depends: libc6 (>= 2.33), libgcc-s1 (>= 3.3.1), libstdc++6 (>= 6), liburing1 (>= 0.7), libzstd1 (>= 1.4.0)
# Suggests: systemd-sysv | powermgmt-base, systemd-sysv | nocache
# Breaks: mlocate
# Replaces: mlocate
# Homepage: https://plocate.sesse.net/
# Task: xubuntu-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi
# Download-Size: 119 kB
# APT-Manual-Installed: yes
# APT-Sources: https://mirrors.cloud.tencent.com/ubuntu impish/universe amd64 Packages
# Description: much faster locate
#  plocate is a locate(1) based on posting lists, giving much faster searches
#  on a much smaller index. It is a drop-in replacement for mlocate in nearly
#  all aspects, and is fast on SSDs and non-SSDs alike.

sudo apt install -y plocate

使用

根据 apt show 信息，plocate 会 break mlocate。
updatedb 命令会改由 plocate 提供。

ll /usr/bin/locate /usr/bin/updatedb /etc/alternatives/locate /etc/alternatives/updatedb
lrwxrwxrwx 1 root root 16 2021-12-15 11:51:56 /etc/alternatives/locate -> /usr/bin/plocate
lrwxrwxrwx 1 root root 26 2021-12-15 11:51:56 /etc/alternatives/updatedb -> /usr/sbin/updatedb.plocate
lrwxrwxrwx 1 root root 24 2021-12-15 11:51:56 /usr/bin/locate -> /etc/alternatives/locate
lrwxrwxrwx 1 root root 26 2021-12-15 11:51:56 /usr/bin/updatedb -> /etc/alternatives/updatedb

根据官网提供的演示数据，其 DB 只有 mlocate 的 40%，查询时间只有 mlocate 的万分之四。

其具体操作和 mlocate 类似：

sudo updatedb

locate go.mod

有没有 2500 倍的提升我不知道，但是感觉好像确实快。挺好！

参考资料与拓展阅读

OSCHINA, Fedora 36 将使用新的查找索引组件 Plocate

#730 基于 CentOS Stream 的桌面环境

CentOS 2021-12-15

CentOS Stream 9 已于月初发布，基于 Fedora 34，这就是 RHEL 9 未来的发展方向。
CentOS Stream 的稳定性应该是比 Fedora 更好，如果我想选择改用 Fedora 当桌面环境，为什么不试试 CentOS Stream 呢？
这里就开始调研一下。

#729 Node 包管理器

NodeJS 2021-12-14

Node 包都存储在 Registry 中，官方 Registry 是 npmjs.org。

切换源

npm config set registry https://registry.npm.taobao.org

或者直接修改 ~/.npmrc, 加入:

registry = https://registry.npm.taobao.org

下载的时候也可以指定：

npm info lodash --registry https://registry.npm.taobao.org

包管理器

npm
yarn
Facebook 出的, 对 npm 做了一些优化，npm 后面也做了类似的优化
cnpm
淘宝出的，主要是默认使用淘宝自己维护的国内镜像
pnpm
entropic
据说是 NPM 前 CTO 成立的新项目，目标是去中心化

包依赖的语法

~ 匹配最近的小版本, eg: ~1.2.3 会匹配 1.2.x
^ 匹配最新的大版本，eg: ^1.2.3 会匹配所有 1.x.x
* 永远最新版本

参考资料与拓展阅读

知乎, 如何看待前 npm 首席技术官提出的 Entropic - 去中心化的 NPM 替代品？
知乎专栏, 一文看懂npm、yarn、pnpm之间的区别

#728 DNS_PROBE_FINISHED_NXDOMAIN

WebDev DNS 2021-12-14

浏览器突然打不开 zhihu.com, 报 DNS_PROBE_FINISHED_NXDOMAIN。
Windows 网络诊断之后说是 DNS 不可用。
经过检查，使用 DHCP 获取到的 DNS 172.16.0.1。
改成 AliDNS: 223.5.5.5, 223.6.6.6 之后就好了。
然后再改回默认的 DNS 发现也能正常访问了。

我应该在出现问题的时候先尝试 nslookup 一下，看看 DNS 解析出来的到底是个什么结果。
下次遇到再继续更新。

C:\Users\Administrator>ipconfig /all | findstr DNS
   主 DNS 后缀 . . . . . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :
   DNS 服务器  . . . . . . . . . . . : 172.16.0.1
   连接特定的 DNS 后缀 . . . . . . . :
   DNS 服务器  . . . . . . . . . . . : fec0:0:0:ffff::1%1
   连接特定的 DNS 后缀 . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :
   连接特定的 DNS 后缀 . . . . . . . :

C:\Users\Administrator>nslookup zhihu.com
服务器:  UnKnown
Address:  172.16.0.1

非权威应答:
名称:    zhihu.com
Address:  103.41.167.234

#727 Tornado HTTP 服务的 “ACK”

Tornado 2021-12-13

一个请求会先到 A 服务，然后通过 HTTP 调用的方式传到 B 服务 (基于 Tornado)
面对突然涌来的大量请求，B 服务负载迅速升高，响应时间拉长
A 服务的部分请求因为超时断开，然后重发

也就是说，在负载较高的时候，B 会收到一些重复请求。因为负载高的时候，B 其实已经接收过一遍，只是没有响应。
B 服务处理任务结束之后，会将请求加入幂等。但是在 B 服务正在处理的时候，还是会有重复处理的可能性。
如果是一些对数据可靠性有一定要求的场景，这样重复的处理就不能接受。

比较合适的设计应该是 A 和 B 之间通过 MQ 通讯，根本不可能有这样的情况发生，哪怕请求再多也可以按照自己的速度消费，使系统保持最佳状态运行。而且，服务之间解耦之后，可以避免相互影响。

但是，如果不能改变 A B 两个服务的现有设计（调用关系），可以做的事情：

通过请求的正常返回来当 ACK 机制 (本文原本想重点说的内容)
将请求的接收和处理拆开
请求收到，加入队列，然后就可以返回了，这个时间非常短，这个过程出现问题的可能性非常低
如果在处理请求之前，连接断开，那就结束流程，抛弃任务
A 服务的重试机制延迟一个合适的时间（比如 3 分钟）处理，可以通过 MQ, DB, Redis 实现

两个方案都应该能大幅减小出现重复请求的情况，双管齐下效果会更好。
方案一, 如果引入 MQ 或 DB 的话，就会觉得为什么不在 A 服务做；如果不引入新组件的化，复杂是需要保证服务突然挂掉之后，队列数据的恢复。只能在启动服务时通过扫描日志来恢复数据。
方案二，无论是业务还是代码，影响范围比较小，易于实现。

Tornado 实现 ACK 机制

客户端在正常流程处理完成之前，断开连接，会触发 on_connection_close 调用，可以在这个里面做手脚。

class MainHandler(tornado.web.RequestHandler):
    def post(self):
        if self._finished:
            return
        # do something

    def on_connection_close(self):
        LOG.debug('connection closed')
        self._finished = True
        super().on_connection_close()

#726 转载：Java 判断是否为空

Java 2021-12-13

不要用 xx != null && xx.length() > 0 来判空，可以使用 apache 的 commons 包。

#725 Go: rewrite `interface{}` to `any`

Golang GoGenerics 2021-12-12

Golang GitHub 仓库上的 Issue 49884 all: rewrite interface{} to any 值得吃瓜。

由于新的泛型机制中引入了 any 关键字, 有人提议将代码中的所有 interface{} 替换为 any。

目前这个 Issue 还是 Open 状态。

一	二	三	四	五	六	日

#734 Bing 打不开了

#733 K8S 核心概念

一、K8S 架构概述

二、核心资源对象

三、关键术语与机制

四、新人入门建议

和 Docker 生态的对比

和虚拟化生态（KVM / OpenStack）的对比

一、核心技术定位对比

二、技术架构与实现原理

三、关键特性对比详解

四、适用场景对比

五、技术协同与混合部署

六、技术演进与未来趋势

#732 Tornado 正在死亡

#731 plocate

安装

使用

参考资料与拓展阅读

#730 基于 CentOS Stream 的桌面环境

#729 Node 包管理器

切换源

包管理器

包依赖的语法

参考资料与拓展阅读

#728 DNS_PROBE_FINISHED_NXDOMAIN

#727 Tornado HTTP 服务的 “ACK”

Tornado 实现 ACK 机制

#726 转载：Java 判断是否为空

#725 Go: rewrite interface{} to any

#725 Go: rewrite `interface{}` to `any`