Skip to content

Commit

Permalink
fix typo
Browse files Browse the repository at this point in the history
  • Loading branch information
@isno
isno committed Nov 1, 2024
1 parent 16e2b8c commit f9675e4
Show file tree
Hide file tree
Showing 3 changed files with 12 additions and 12 deletions.
2 changes: 1 addition & 1 deletion architecture/Immutable.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@

## 1.可变的基础设施

从基础设施的管理角度看，“可变”的基础实施与传统运维操作相关。例如，有一台服务器部署的是 Apache，现在想换成 Nginx，则需要先卸载掉 Apache，重新安装一个 Nginx，再进行重启让系统对这次变更生效。
从管理基础设施的层面看，“可变”的基础实施与传统运维操作相关。例如，有一台服务器部署的是 Apache，现在想换成 Nginx，则需要先卸载掉 Apache，重新安装一个 Nginx，再进行重启让系统对这次变更生效。

上述的过程中，基础设施为了满足业务需求，进行了一次或多次变更，装有 Apache 的 Linux 系统就是一个可变的基础设施。可变的基础设施通常会导致以下问题：

Expand Down
2 changes: 1 addition & 1 deletion consensus/raft.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ Raft 是由 Re{liable|plicated|dundant} And Fault-Tolerant 组合起来的单词

Raft 出现之前，绝大多数共识系统都是基于 Paxos 或者受其影响，同时 Paxos 也成为了教学领域里讲解共识问题时的示例。但不幸的是，Paxos 理解起来非常晦涩。此外，虽然论文中提到了 Multi Paxos，但缺少实现细节的描述。因此，无论是学术界还是工业界普遍对 Paxos 算法感到十分头疼。

那段时期，虽然所有的共识系统都是从 Paxos 开始的，但工程师在实现过程中，发现有很多难以逾越的难题，往往不得已又开发出与 Paxos 完全不一样的算法，这导致 Lamport 的证明并没有太大价值。所以，在很长的一段时间内，实际上并没有一个被大众所认同的 Paxos 算法。
那段时期，虽然所有的共识系统都是从 Paxos 开始的。但工程师们发现：实现过程中很多难以逾越的难题，往往不得已又开发出与 Paxos 完全不一样的算法。这导致 Lamport 的证明并没有太大价值。所以，在很长的一段时间内，实际上并没有一个被大众所认同的 Paxos 算法。

:::tip Chubby 作者评论 Paxos
Paxos 算法描述与工程实现之间存在巨大的鸿沟，最终实现的系统往往建立在一个还未被证明的算法之上。
Expand Down
20 changes: 10 additions & 10 deletions container/borg-omega-k8s.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,7 @@ Google 开发的第三套容器管理系统是 Kubernetes，其背景如下：
- 全球越来越多的开发者开始对 Linux 容器产生兴趣（尽管 Linux 容器是 Google 的技术基础，但开发者们首先想到的是 Docker，Google 并没有吃到红利）。
- 同时，Google 已将公有云基础设施作为业务重点并实现持续增长（虽然 Google 提出了云计算的概念，但市场领先者已被 AWS 和阿里云占据，Google 起了大早赶了个晚集）。

2013 年夏，Google 的工程师们开始讨论如何借鉴 Borg 的经验开发新一代容器编排系统。并希望通过十几年的技术积累影响云计算市场格局。Kubernetes 项目获批后，Google 于 2014 年 6 月的 DockerCon 大会上正式宣布将其开源。
2013 年夏，Google 的工程师们开始讨论借鉴 Borg 的经验开发新一代容器编排系统，希望通过十几年的技术积累影响云计算市场格局。Kubernetes 项目获批后， 2014 年 6 月，Google 在 DockerCon 大会上宣布将其开源。

通过图 7-3 观察 Kubernetes 架构，能看出大量设计来源于 Borg/Omega 系统：

Expand All @@ -76,7 +76,7 @@ Google 开发的第三套容器管理系统是 Kubernetes，其背景如下：

出于降低用户使用的门槛，并最终达成 Google 从底层进军云计算市场意图，Kubernetes 定下的设计目标是**享受容器带来的资源利用率提升的同时，让部署和管理复杂分布式系统的基础设施标准化且更简单**。

为了进一步理解基础设施的标准化，来看 Kubernetes 从一开始就提供的东西——用于描述各种资源需求的标准 API：
为了进一步理解基础设施的标准化，来看 Kubernetes 从一开始就提供的东西 —— 用于描述各种资源需求的标准 API：

- 描述 Pod、Container 等计算资源需求的 API；
- 描述 Service、Ingress 等网络功能的 API；
Expand All @@ -93,18 +93,18 @@ Google 开发的第三套容器管理系统是 Kubernetes，其背景如下：

## 7.1.4 以应用为中心的转变

从最初的 Borg 到 Kubernetes，**容器化技术的最大的益处早就超越了单纯提高资源使用率的范畴**；**更大的变化在于，系统开发和运营的理念从以机器为中心迁移到了以应用程序为中心**。
从最初的 Borg 到 Kubernetes，容器化技术的最大的益处早就超越了单纯提高资源使用率的范畴。更大的变化在于，**系统开发和运营的理念从以机器为中心迁移到了以应用程序为中心**。

容器化使系统运营观念从原来的面向机器向了面向应用程序：
容器化使运营数据中心的观念从原来的面向机器转向了应用程序：

1. 容器封装了应用程序运行的环境，屏蔽了操作系统和机器的细节，使业务开发者和基础设施管理者不再关注底层细节；
2. 每个设计良好的容器或容器镜像通常对应一个应用，管理容器即是管理应用，而非管理机器。
- 容器封装了应用程序运行的环境，屏蔽了操作系统和机器的细节，使业务开发者和基础设施管理者不再关注底层细节；
- 每个设计良好的容器或容器镜像通常对应一个应用，管理容器即是管理应用，而非管理机器。

正是因为以应用为中心，云原生技术体系才会无限强调让基础设施能更好的配合应用、以更高效方式为应用输送基础设施能力：
正是以应用为中心，云原生技术体系才会无限强调让基础设施能更好的配合应用、以更高效方式为应用输送基础设施能力：

1. 开发者和运维团队无需再关心机器、操作系统等底层细节；
2. 基础设施团队引入新硬件和升级操作系统更加灵活，最大限度减少对线上应用和应用开发者的影响；
3. 将收集到的各类关键性能指标（如 CPU 使用率、内存用量、每秒查询率 QPS 等）与应用程序而非物理机器关联起来，显著提高了应用监控的精确度和可观测性，尤其是在系统垂直扩容、机器故障或主动运维等场景。这直接促使软件可观测性领域应运而生。
- 开发者和运维团队无需再关心机器、操作系统等底层细节；
- 基础设施团队引入新硬件和升级操作系统更加灵活，最大限度减少对线上应用和应用开发者的影响；
- 将收集到的各类关键性能指标（如 CPU 使用率、内存用量、每秒查询率 QPS 等）与应用程序而非物理机器关联，显著提高了应用监控的精确度和可观测性，尤其是在系统垂直扩容、机器故障或主动运维等场景。这直接促使软件可观测性领域应运而生。


[^1]: 在 Kubernetes 中的 Workload 资源包括多种类型，例如 Deployment、StatefulSet、DaemonSet、ReplicaSet 等等

0 comments on commit f9675e4

Please sign in to comment.