【观点】深入高可用系统原理与设计

一、移动互联网时代的背景与挑战

1. 能力特征：快速变更、高可用、弹性扩展、移动优先

• 移动互联网时代，能够成长并发展起来的公司通常具备以下共性：
1. 快速变更，不断创新，随时调整
2. 持续可用服务，应对错误和中断
3. 弹性可扩展，满足用户规模的快速增长
4. 移动为中心，提供新的用户体验

• 随着用户量和业务规模的不断扩大，软件开发方式也被迫不断演变，首要难题是：“如何在规模越来越大、变更越来越快的情况下保持效率与稳定？”

2. 时代巨变下的技术浪潮

• 软件正在改变世界：几乎每个行业都在经历“软件化”转型。

• 移动互联网扩大了影响面：海量用户催生快速变更与创新需求。

• 传统软件开发受巨大挑战：研发方式需适配高并发、高弹性、高迭代场景。

• 云计算与相关技术的普及：上云成为大势所趋。

• 云计算形态持续演进：从最初的简单虚拟机托管，到当下多云、混合云、Serverless 等多种形态。

3. 大时代下的个体：剧烈革新替代

• 软件行业的技术升级并非线性平缓的升级，而是剧烈的革新与替代：
• 容器替代虚拟机
• 服务网格替代 SpringCloud
• 观测替代监控
• Network Policy 替代 iptables

• 各种新技术不断冲击既有的开发运维假设。每个工程师都需要拥抱变化，持续学习。

4. 思想先行，技术随后

5. 回顾历史的意义

二、云计算的崛起与成熟

1. 虚拟化：云计算基础架构的核心

2. 云计算走向成熟的多个里程碑

1. IaaS（Infrastructure as a Service）
通过按时计费的方式出售“服务器资源”，将企业原本的资本支出转化为运营支出。大规模普及云计算。

2. PaaS（Platform as a Service）
从“卖资源”进阶到“卖服务”，开发者无需关心操作系统或开发工具升级、硬件维护等。

3. 开源 IaaS（OpenStack）
让普通企业可自建私有云，云服务模式更加多样：公有云、私有云、租赁私有云、混合云等。

4. 开源 PaaS（Cloud Foundry、OpenShift）
能在混合云、多云、边缘环境中，加快跨平台的应用交付。促使企业内部云架构不断向行业先进水准演进。

5. FaaS（Function as a Service）
隐藏了底层硬件、虚拟机、操作系统等管理细节，开发者只需关注函数和数据，“无服务器（Serverless）”概念逐渐兴起。无服务器（Serverless）的概念初现，开发者将无需再关注任何服务、资源等基础设施。

三、容器时代的重大变革

1. 容器技术兴起

容器技术无疑是过去十年对软件开发行业影响最深远的技术之一。

• 从虚拟机到容器，云计算经历了一次“洗牌式”变革。

• Mesos、Swarm、Kubernetes 三强角逐：Kubernetes 凭借其设计理念与开放架构，最终成为事实标准。

• Docker：最大的创新在于“容器镜像”，把应用运行所需环境（操作系统文件系统等）进行一致性打包，具有一致性、轻量级、可移植、编程语言无关等特性，实现“一次构建，随处运行”。

• Kubernetes：抽象计算、存储、网络资源为标准 API，对应用和环境解耦，可在不同云上自由迁移。

四、云计算演进：IaaS→PaaS→FaaS 的规律

1. 工作负载、隔离单元、供应商变化

• 工作负载的演进：物理服务器 → 虚拟机 → 容器

• 隔离单元的转变：从“重量级”到“轻量级”

• 供应商生态：从闭源到开源，从单一到多云、混合云

2. XaaS 形态及其发展

• IaaS：用户不关心物理机；只需关注基础架构和应用程序。

• PaaS：用户不关心基础架构；只需关注应用程序。

• FaaS：用户只需关注函数和数据；无服务器模式持续演进。

3. 软件成为“社会基础设施”

4. 过去二十年：云与软件架构的双向匹配

• 通过不可变基础设施（镜像）解决本地和远程一致性问题；

• 通过服务网格（ServiceMesh）将非业务逻辑从应用程序中剥离；

• 通过声明式 API 描述应用程序的状态，而不用管中间的处理过程；

• 通过 DevOps 方法论以及一系列工具来提升研发/运维效率...。

五、云原生的兴起

1. CNCF 最初定义

• 应用容器化：容器是云原生基础。

• 面向微服务架构：构建大规模系统的必备要素。

• 容器编排调度：自动管理容器的部署、扩展、运行和生命周期。

• 并非简单“上云”，而是充分利用云计算优势来设计、实现、部署、交付应用。

2. CNCF v1.0 版本：不可变基础设施、容器、服务网格、微服务、声明式 API

3. 云原生的目标：可用、规模、敏捷、成本

• 可用 (Available)：保证服务连续性。

• 规模 (Scale)：动态适配不同规模及突发流量。

• 敏捷 (Agility)：快速响应市场变化。

• 成本 (Cost)：有效利用资源。

• 规模大 + 敏捷 → “巨人绣花”

• 规模大 + 高可用 → “大象起舞”

• 敏捷 + 高可用 → “空中换发”

六、容器与云原生关键技术

1. Docker 的核心创新：容器镜像

• “Build once，run anywhere”：容器镜像包含容器运行依赖环境，不再依赖宿主机 OS；构建完后即不可变，成为不可变基础设施的一部分。

2. Docker 组件拆分为 containerd

containerd 架构图 (图 7-13)

• Docker 将内部容器执行、分发、监控、网络、构建、日志等模块剥离出来成为 containerd。

• 2016 年将 containerd 捐献给 CNCF 后，它成为最流行容器运行时。

• Docker 进一步拆分出 containerd-shim、runc 等组件，形成分层架构：

Docker 拆分后架构

• 低层运行时 (runc)：关注 namespace、cgroups、镜像拆包等基础功能。

• 高层运行时 (containerd)：提供更多高级功能，如镜像管理、容器应用管理等。

3. 容器编排阶段：Kubernetes

• Kubernetes 在容器基础上，引入“资源”概念，提供可扩展的 API、服务发现、容器网络、调度等特性。

• 对用户而言：docker run 可启动单个容器，而 kubectl apply -f 则可部署分布式集群，无需关心私有云或公有云的差异。

七、微服务与服务网格

1. 微服务架构是一种面向服务的架构，由松耦合的具有有限上下文的元素组成

• 松耦合：每个服务可独立更新，不必修改其他服务。

• 限界上下文：每个服务有清晰边界，通过稳定 API 交互，不共享数据库。

• 服务发现（Service Discovery）问题：解决“我想调用你，如何找到你”的问题。

• 服务熔断（Circuit Breaker）问题：缓解服务之间依赖的不可靠问题。

• 负载均衡（Load Balancing）问题：通过均匀分配流量，让请求处理更加及时。

• 安全通讯问题：包括协议加密（TLS）、身份认证（证书/签名）、访问鉴权（RBAC）等。

在 Kubernetes 环境下的替代方案

• Kubernetes 用 CoreDNS 替代 Spring Cloud Eureka

• Kubernetes 用 Service / LoadBalancer 替代 Ribbon

• Kubernetes 用 ConfigMap 替代 Config Center

• Kubernetes 用 Ingress 替代 Zuul 等网关组件

2. 服务网格的出现

背景：当微服务 A 调用微服务 B 下不同服务（如 B1、B2）时，如果 B2 出现 500 错误，基础设施粒度过粗，无法只熔断 B2 而保持 B1 正常。

Istio 架构

• 数据平面（Data plane）：通常采用轻量级的网络代理（如 Envoy）作为 Sidecar，网络代理负责协调和控制服务之间的通信和流量处理，解决微服务之间服务熔断、负载均衡、安全通讯等问题。

• 控制平面（Control plane）：包含多个控制组件，它们负责配置和管理 Sidecar ，并提供服务发现（Discovery）、配置管理（Configuration）、安全控制（Certificates）等功能。

八、不可变基础设施与声明式设计

1. 不可变基础设施

• 传统做法下，服务器是“可变”的：运维多次手动修改 OS，带来状态不一致、故障难快速重建的问题。

• 容器镜像 一旦构建后即只读，可在任何环境一致部署，是“不可变基础设施”的典型落地。

2. 声明式设计

• 声明式 vs. 命令式：
• 命令式：告诉系统 如何做（How）
• 声明式：描述 想要的目标状态（What），实现细节由系统决定。

九、DevOps 与云原生架构演进

1. DevOps 的提出

瀑布模型

2. 云原生架构的演进

• 为了解决单体架构“复杂度问题”，使用微服务架构。

• 为了解决微服务间“通讯异常问题”，使用治理框架 + 监控。

• 为了解决微服务架构下大量应用“部署问题”，使用容器。

• 为了解决容器的“编排和调度问题”，使用 Kubernetes。

• 为了解决微服务框架的“侵入性问题”，使用服务网格。

• 为了让服务网格有“更好的底层支撑”，将服务网格运行在 Kubernetes 上。

十、云原生代表技术栈

1. 容器运行时：Docker、Containerd、CRI-O、Kata Containers

2. 镜像和仓库：Harbor、Dragonfly、Nydus

3. 应用封装：Kustomize、Helm

4. 持续集成：GitLab、Tekton

5. 持续部署：ArgoCD、FluxCD

6. 容器编排：Kubernetes

7. 服务网格：Istio、Envoy、Linkerd

8. 网关：Ingress-Nginx、Kong、APISIX

9. 日志：Grafana Loki、Elastic Stack、ClickHouse

10. 监控：Prometheus、Grafana

11. 可观测性：OpenTelemetry

12. 机器学习/离在线混合部署：Volcano、Koordinator

十一、结语：云原生的核心思想

• 云原生并非简单地把现有应用部署在云上，也不是任何单个项目、技术的代名词；它是一套指导软件及基础设施架构设计的思想。

• 之所以诞生，根源在于：软件规模越来越大、系统复杂度越来越高，对可靠性、迭代效率、资源成本的要求水涨船高。

• 容器与 Kubernetes 的发展只是提供了一个恰当的“技术抓手”；云原生的真正价值在于同时兼顾“可用性、规模、敏捷性”与“成本”之间的平衡，并在高度自动化、声明式、弹性的基础设施上运行应用。