云原生思想 — 关键技术
目录
文章目录
- 目录
- 云原生的代表技术
- 容器
- 基于容器的不可变基础设施
- 微服务
- Kubernetes
- 声明式 API
- 基于 Kubernetes 的云应用编排理论
- 服务网格（Service Mesh）
云原生的代表技术
云原生的技术范畴包括了以下几个方面：
-
第一部分是云应用定义与开发流程。这包括应用定义与镜像制作、配置 CI/CD、消息和 Streaming 以及数据库等。
-
第二部分是云应用的编排与管理流程。这也是 Kubernetes 比较关注的一部分，包括了应用编排与调度、服务发现治理、远程调用、API 网关以及 Service Mesh。
-
第三部分是监控与可观测性。这部分所强调的是云上应用如何进行监控、日志收集、Tracing 以及在云上如何实现破坏性测试，也就是混沌工程的概念。
-
第四部分就是云原生的底层技术，比如容器运行时、云原生存储技术、云原生网络技术等。
-
第五部分是云原生工具集，在前面的这些核心技术点之上，还有很多配套的生态或者周边的工具需要使用，比如流程自动化与配置管理、容器镜像仓库、云原生安全技术以及云端密码管理等。
-
最后则是 Serverless。Serverless 是一种 PaaS 的特殊形态，它定义了一种更为 “极端抽象” 的应用编写方式，包含了 FaaS 和 BaaS 这样的概念。而无论是 FaaS 还是 BaaS，其最为典型的特点就是按实际使用计费（Pay as you go），因此 Serverless 计费也是重要的知识和概念。
容器
容器提供进程级的隔离，可以将操作系统管理的资源划分到相互隔离的组中，在相互隔离的组之间解决资源使用存在冲突的问题。
容器为 IT 历史带来的显着影响莫过于：改变了代码交付的方式。它包含了一个应用运行所需的完整环境（整个操作系统的文件系统），具有一致性、轻量级、可移植、语言无关等特性，实现 “一次发布，随处运行”（开发、测试、生产），使应用的构建、分发和交付完全标准化。它也是 “不可变基础设施” 的核心基础。
基于容器的不可变基础设施
不可变基础设施，是相对于可变基础设施而言的。
-
可变基础设施：在传统的可变服务器基础架构中，物理服务器会不断更新和修改。使用此类基础架构的工程师和管理员需要通过 SSH 连接到他们的物理服务器，手动升级或降级软件包，逐个服务器地调整配置文件，以及将新代码直接部署到现有服务器上。所有说，这些服务器是可变的。它们可以在创建后进行更改。
-
不可变基础架构：是另一种基础架构范例，其中的物理服务器在部署后永远不会被修改。程序设计中不可变变量（ImmutableVariable）就是在完成赋值后就不能发生更改，只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性，最基本的就是指运行服务的物理服务器在完成部署后，就不在进行更改。
不可变基础架构的好处，包括：基础架构中更高的一致性和可靠性，以及更简单，更可预测的部署过程。它可以缓解或完全防止可变基础架构中常见的问题，例如：配置漂移和雪花服务器。但是，有效地使用它通常包括全面的部署自动化，云计算环境中的快速服务器配置，以及处理状态或短暂数据（如日志）的解决方案。
微服务
微服务需要从两个方面去理解：“微” 和 “服务”。
对此，亚马逊 CEO Bezos 给出了一个很好的诠释：单个服务的实现，所有参与人从设计、开发、测试、运维所有人加起来只需要 2 个披萨就够了（2 pizza 定律）。
所谓服务，一定要区别于系统，服务是一个或一组相对较小且独立的功能单元，是用户可以感知最小功能集。传统的单体架构，以整个系统为单位进行部署。而微服务，则是以每一个独立组件为单位进行部署。
可以使用 Martin Fowler 的这张图来解释，图中左边是单体架构的集群，右边是微服务集群。
Kubernetes
有了容器，就需要编排管理容器的生命周期，Kubernetes 则是这方面的事实标准。Kubernetes 这个单词来自于希腊语，含义是舵手或领航员。Kubernetes 并不是一件全新的发明，它是谷歌根据其内部使用的 Borg 改造成的一个通用容器编排调度器，于 2014 年 6 月开源。可以说，Kubernetes 是云计算和云原生时代的 Linux。
Kubernetes 采用声明式的 API 与可扩展（CRD + Controller）的编程接口，先进的设计思想使其在容器编排大战中（Kubernetes、Swarm、Mesos）处于王者地位，成为容器编排系统的事实标准。
Kubernetes 作为云应用的部署标准，直接面向业务应用，大大提高了云应用的可移植性，解决云厂商锁定的问题，让云应用可以在跨云之间无缝迁移，甚至用来管理混合云，成为企业 IT 云平台的新标准。
通过采用 Kubernetes 平台，用户不必操心资源管理问题，使基础设施更加标准化，复杂度降低，资源使用率提升。同时 Kubernetes 也简化了混合云，多云，边缘云等跨数据中心的部署成本。
声明式 API
声明式（Declarative）的编程方式一直都会被工程师们拿来与命令式（Imperative）进行对比。命令式编程：要求我们描述为了达到某一个效果或者目标所需要完成的指令，常见的编程语言：Go、Ruby、C++ 都是命令式的编程方法。
声明式 API 和命令式 API 是两种截然不同的编程方式：
- 命令式 API：我们可以直接发出服务器要执行的命令，例如：“运行容器”、“停止容器” 等。
- 声明式 API：我们声明系统要执行的操作，系统将不断向该状态驱动。
简而言之，命令式编程是第一人称，我要做什么，我要怎么做，是单纯的被动执行；而声明式编程则类似于 “第二人称”，也就是：你要做什么，是一种主动向目前前进的执行方式。
基于 Kubernetes 的云应用编排理论
云应用编排理论，当前的实现方式就是 Google 所提出来的 “容器设计模式”。
服务网格（Service Mesh）
对许多公司来说，Docker 和 Kubernetes 这样的工具已经解决了云原生应用部署的问题，但他们还没有解决微服务运行时的问题，这就是服务网格（Service Mesh）的由来。
Service Mesh 一般用于微服务应用的可配置基础架构层（Configurable infrastructure layer），以处理服务与服务之间通信。最早与 2016 年 9 月由 Buoyant 公司提出。而 Istio（由 Google、IBM、Lyft 支持）则是目前最广为人知的一款服务网格架构。Kubernetes 是目前 Istio 唯一支持的容器组织框架。
Service Mesh 核心是业务逻辑与非业务逻辑解耦，实现开发只需关注业务逻辑的伟大目标。将一大堆和业务逻辑无关的客户端 SDK，如：服务发现，路由，负载均衡，限流降级等从业务应用中剥离出来，放到单独的 Proxy（Sidecar） 进程中，之后下沉到基础设施中间件 Mesh（类似 TDDL 到 DRDS 的模式）。针对应用减少了系统框架变更带来的风险、瘦身后变的干净和轻量化，加快了应用的启动速度，使得应用往 Serverless 架构迁移变得轻松。针对 Mesh 可以根据自身需求自行迭代和升级功能，更加利于全局服务治理、灰度发布、监控等。同时，Mesh 边界可以扩展到 DB Mesh，Cache Mesh、Msg Mesh等，真正做到服务通信的标准化即服务之间通信的 TCP/IP。
Service Mesh 的出现，弥补了 Kubernetes 在微服务的连接、管理和监控方面的短板，为 Kubernetes 提供更好的应用和服务管理。因此，Istio 一经推出，就被认为是可以和 Kubernetes 双剑合璧的微服务管理的利器，而受到了业界的推崇。
