云原生关键技术浅析

0. 引言

"云原生"这个词大家或多或少都听过，但要给它下一个准确的定义却比较模糊。一方面，云原生的关键技术近几年在持续演变；另一方面，很多人只关注其中某一部分技术的应用，并不在意整体概念。本文就来梳理云原生的概念演进，并依次讲解云基础设施、DevOps、服务网格、微服务拆分等关键技术。

1. 什么是云原生

云原生并不是一个非常具体的定义，随着云的使用模式、技术差异等因素的影响，不同组织给出的概念也并不相同。

• Pivotal 的定义（2017 年）：云原生主要涵盖四个要点——DevOps、持续交付、微服务和容器。
• CNCF 的定义（2018 年）：在 Pivotal 四点的基础上，把服务网格和声明式 API 加入其中。

如果站在当前视角来概括，云原生可以理解为：基于云基础设施，结合 DevOps 的持续交付能力，以及微服务框架和服务网格，配合云开发模式组成的整套技术体系。

2. 云原生关键技术

2.1 云基础设施

基础设施是云原生的基石。最底层是硬件基础设施，通过虚拟化技术交付 IaaS 资源给上层应用使用，应用层并不关心底层硬件：

• 计算资源：通过 K8s + Docker 方式提供轻量化计算；
• 数据库资源：通过 OpenStack + KVM 或 K8s + Docker 等技术结合到具体的数据库服务供应用层调用；
• 存储资源：通过 GFS、Ceph、NFS 等共享的分布式存储技术供应用调用。

K8s 作为容器管理平台被普遍应用，云原生所依赖的基础设施能力在此基础上不断扩展，比如 Istio 服务网格、Prometheus 监控等组件都围绕 K8s 生态融入云原生核心体系，所以 K8s + Docker 的作用举足轻重。

2.2 DevOps

DevOps 涵盖了开发、测试、部署、运维四大环节，打通了整个开发体系，实现持续交付。在开发层通过 Git 对代码库进行管理，Jenkins 可以完成项目的开发、测试、部署以及对底层依赖的管理，使应用部署发布更加容易。通过这几个关键技术就可以构建一套开源的 DevOps 方案。

2.3 服务网格

服务网格是用于处理服务间通信的基础设施层，它负责为复杂的云原生应用传递可靠的网络请求。在实践中，服务网格的实现通常与应用部署在一起，提供轻量化的网络代理服务，对应用而言是透明的。

在 K8s 中最小单元是 Pod，Pod 内的应用实例对外部目标实例的调用需要经过一个 Sidecar 中间代理：

1. 应用通过 RPC 协议调用 Sidecar；
2. Sidecar 请求统一的服务注册中心，基于应用名称得到目标实例的连接信息；
3. 拿到目标实例信息后再发起实际请求。

注册中心维护可用的实例列表，并通过评级打分策略得出负载均衡权重，实现负载均衡；同时通过熔断的自动隔离机制，自动隔离不健康的实例。

从宏观上看，所有实例的相互调用就形成了一张网格状的结构图，深蓝色代表具体的微服务应用，Sidecar 关联起每个实例应用，形成服务网格。Sidecar 通信的组织框架可以用 K8s 统一管理，常见的开源自实现是 Istio，它由 Google 和 IBM 主导。

整个微服务的层级关系为：底层是基础设施层，上层封装 Docker、rkt 等轻量级容器，再往上是 K8s 容器编排，最上层由服务网格（Istio、Linkerd）提供服务。

2.4 微服务拆分

传统部署模式把应用放到一个单体应用里，比如早期 Java 开发会把所有业务逻辑封装到一个 war 包部署，虽然简单快速，但存在扩展性差、耦合严重等问题。微服务模式强调各个服务组件个体化，通过虚拟化容器技术实现隔离，降低了对环境的依赖。

单体应用向微服务拆分的设计原则：

3. 小结

本文介绍了云原生概念从 Pivotal 四要点到 CNCF 定义的演进，并讲解了云基础设施、DevOps、服务网格三大关键技术，最后总结了单体应用向微服务拆分的五个设计原则。云原生不是单一技术，而是围绕云基础设施、持续交付、微服务与服务网格形成的整套方法论。

至此，部署与运维实践模块的全部课时讲解完毕。从容器化（Docker）、版本管理（Git）、服务器运维（Linux）到监控告警、负载均衡、安全防护、容灾架构与云原生，整个 DevOps 体系已经形成完整闭环，后续可以结合这些知识搭建真正落地的运维自动化平台。