From aa35d03f862ac78ac9c723e4c6447e0fd9f7ac41 Mon Sep 17 00:00:00 2001 From: isno Date: Fri, 31 Jan 2025 23:11:41 +0800 Subject: [PATCH] fix typo --- application-centric/application-centric.md | 12 +++++------- http/conclusion.md | 2 +- 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/application-centric/application-centric.md b/application-centric/application-centric.md index 05d680f6..fbf566cd 100644 --- a/application-centric/application-centric.md +++ b/application-centric/application-centric.md @@ -1,15 +1,13 @@ # 10.1 “以应用为中心”的设计思想 -回顾过去十几年的技术架构演进，精彩纷呈！ +回顾过去十几年间的技术演进历程，精彩纷呈！ -从单体应用到分布式架构，能力大幅提升，但也引入了更多的不确定性，比如节点可能随时宕机、网络有不等的延迟、消息可能丢失。为了解决这些不确定性，业界提出了诸多的分布式理论和协议，如 CAP 定理、BASE 理论以及共识算法（Paxos、Raft 等），以保障系统稳定运行。 +从单体应用到分布式架构，系统能力大幅提升，但也引入了更多的不确定性，比如节点可能随时宕机、网络有不等的延迟、消息可能丢失。为了解决这些不确定性，业界提出了诸多的分布式理论和协议，如 CAP 定理、BASE 理论以及共识算法（Paxos、Raft 等），以保障系统稳定运行。 -进入微服务时代，这些理论推动基础设施能力开始演进，这些能力（服务发现、负载均衡、故障转移、动态扩容）从业务逻辑中抽象出来，以 SDK（中间件）方式提供给应用开发者。中间件的出现其实体现了一种朴素的“关注点分离”的思想，使得你可以在不需要深入了解具体基础设施能力细节的前提下，以最小的代价学习和使用这些基础设施能力！ +进入微服务时代，这些理论推动基础设施能力演进，这些能力（服务发现、负载均衡、故障转移、动态扩容）从业务逻辑中抽象出来，以 SDK（中间件）形式提供给应用开发者。中间件的出现其实体现了一种朴素的“关注点分离”的思想，使得你可以在不需要深入了解具体基础设施能力细节的前提下，以最小的代价学习和使用这些基础设施能力！ -不过，基础设施能力的演进，也伴随着云计算和开源社区的发展，带来了全新的升级。这个变化，正是从云原生技术改变中间件格局开始。更确切地说，原先通过中间件提供和封装的各种基础设施能力，现在全部被 kubernetes 从应用层拽到基础设施层。比如，Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，其实把构建分布式应用最迫切的需求，利用 Replication Controller、kube-proxy 和 etcd “下沉”到基础设施中，也就是 kubernetes 中。 +不过，基础设施能力的演进，也伴随着云计算和开源社区的发展，带来了全新的升级。这个变化，正是从云原生技术改变中间件格局开始。更确切地说，原先通过中间件提供和封装的能力，现在全部被 kubernetes 从应用层拽到基础设施层。比如，Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，其实把构建分布式应用最迫切的需求，利用 Replication Controller、kube-proxy 和 etcd “下沉”到基础设施中，也就是 kubernetes 中。 -值得注意的是，kubernetes 不直接提供这些能力，它的角色定位是通过声明式 API 和控制器模式对用户暴露更底层基础设施的能力。从这个角度来看，Kubernetes 设计的重点在于“如何标准化地接入底层资源，无论是容器、虚拟机、负载均衡等，并通过声明式 API 将这些能力暴露给用户”。从这一点讲，Kubernetes 从来就不是一个简单的容器平台或者资源管理项目，它是一个分量十足的“接入层”，是云原生时代真正意义上的“操作系统”！ - -所以说，Kubernetes 的核心价值不在于容器编排或资源调度，而在于声明式 API。声明式 API 的最大优势是将“简单的交给用户，将复杂的留给系统”。通过声明式 API，Kubernetes 用户只需关心应用的最终状态，而无需关注底层基础设施的配置和实现细节。 +值得注意的是，kubernetes 不直接提供这些能力，它的角色定位是通过声明式 API 和控制器模式对用户暴露更底层基础设施的能力。从这个角度来看，Kubernetes 设计的重点在于“如何标准化地接入底层资源，无论是容器、虚拟机、负载均衡等，并通过声明式 API 将这些能力暴露给用户”。所以说，Kubernetes 的核心价值不在于容器编排或资源调度，而在于声明式 API。声明式 API 的最大优势是将“简单的交给用户，将复杂的留给系统”。通过声明式 API，Kubernetes 用户只需关心应用的最终状态，而无需关注底层基础设施的配置和实现细节。 这种设计理念，以一言蔽之，就是以应用中心。正是因为以应用为中心，整个云原生技术体系无限强调基础设施更好地服务于应用，以更高效的方式为应用提供基础设施能力，而不是反其道行之。而相应的，Kubernetes 也好、Docker 也好、Istio 也好，这些在云原生生态中起到了关键作用的开源项目，就是让这种思想落地的技术手段。 \ No newline at end of file diff --git a/http/conclusion.md b/http/conclusion.md index 8bb0e9a2..8cc6a5d6 100644 --- a/http/conclusion.md +++ b/http/conclusion.md @@ -2,4 +2,4 @@ 本章，我们详细分析了 HTTPS 的请求过程，讲解了其中域名解析、内容压缩、SSL 层加密、网络拥塞控制等主要的环节的原理和优化操作。相信你对于构建足够快的网络服务，有了足够的认识。 -总体而言，要构建“足够快”的网络服务，首先是保证域名解析不能失败，然后请求要足够快（使用 QUIC、Brotli 压缩）、足够安全（使用 TLS1.3 协议 + ECC 证书，即快又安全）、还要充分利用带宽（使用 BBR 提高网络吞吐率）。最后，技术无法解决的（长链路、弱网、海外网络），那就得花钱（CDN、边缘节点加速、建当地数据中心）。 +总体而言，要构建“足够快”的网络服务，首先是保证域名解析不能失败，然后请求要足够快（使用 QUIC、Brotli 压缩）、足够安全（使用 TLS1.3 协议 + ECC 证书，即快又安全）、还要充分利用带宽（使用 BBR 提高网络吞吐率）。最后，技术无法解决的（长链路、弱网、海外网络），那就得花钱（CDN、边缘节点加速、建立当地数据中心）。