云原生思想 — 关键技术

目录

文章目录

• 目录
• 云原生的表明技术
• 容器
• 基于容器的不可变基础设施
• 微服务
• Kubernetes
• 声明式 API
• 基于 Kubernetes 的云应用编排理论
• 服务网格（Service Mesh）

云原生的表明技术

云原生的技术范畴包括了如下几个方面：

1. 第一部分是云应用定义与开发流程。这包括应用定义与镜像制做、配置 CI/CD、消息和 Streaming 以及数据库等。

2. 第二部分是云应用的编排与管理流程。这也是 Kubernetes 比较关注的一部分，包括了应用编排与调度、服务发现治理、远程调用、API 网关以及 Service Mesh。

3. 第三部分是监控与可观测性。这部分所强调的是云上应用如何进行监控、日志收集、Tracing 以及在云上如何实现破坏性测试，也就是混沌工程的概念。

4. 第四部分就是云原生的底层技术，好比容器运行时、云原生存储技术、云原生网络技术等。

5. 第五部分是云原生工具集，在前面的这些核心技术点之上，还有不少配套的生态或者周边的工具须要使用，好比流程自动化与配置管理、容器镜像仓库、云原生安全技术以及云端密码管理等。

6. 最后则是 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 双剑合璧的微服务管理的利器，而受到了业界的推崇。