☁️云原生技术🔥

• ☁️起源
• • ☁️CNCF组织
• ☁️云原生介绍
• • ☁️十二要素
  • ☁️容器化封装
  • ☁️服务编排
  • ☁️微服务架构
  • ☁️小结
• ☁️云原生相关技术图谱
• • ☁️CNCF 的云原生全景图
  • ☁️云原生全景图的 4 层
  • • ☁️供应层 （Provisioning）
    • ☁️运行时层（Runtime）
    • ☁️编排和管理层（Orchestration and Management）
    • ☁️应用定义和开发层 （Application Definition and Developement)
  • ☁️贯穿所有层的工具
  • • ☁️可观察性和分析（Observability and Analysis）
    • ☁️平台类（Platform）
  • ☁️小结
• 参考文献

☁️起源

2014年，谷歌开源了一个主要用于容器编排的Borg内部项目。由于没有机构来管理这个项目，谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而后来Borg项目就更名为Kubernetes，并用Go语言重写了实现部分，成为了CNCF的启动捐赠项目。毫无疑问地讲，Kubernetes只是开始，后续有大批的新项目先后加入到CNCF，围绕着Kubernetes不断地扩展功能。

☁️CNCF组织

CNCF，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多企业与机构，包括亚马逊、微软。思科等巨头。

CNCF在云端的自我使命是通过提供多种选项的开发软件社区，帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作，希望实现完全由CNCF成员项目演化出来的成熟技术栈。

目前共有25个项目已经被CNCF接受，在跟进Kubernetes生态发展。评选通过的项目就叫CNCF成员项目，CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。下图为其公布的Cloud Native Landscape，给出了云原生生态的参考体系。

CNCF成员项目包括12个类别：编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流，下面内容重点介绍前几个类别。

编排：Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置，可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排，而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层，将容器分组运行在Pod中，从而实现容器的编排。

应用程序开发： Helm是程序包管理器，以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用（包括MySQL、Jenkins、Artifactory等）

监控： Prometheus是第二个加入到CNCF的项目，也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案，灵感来自于谷歌的Borgman监控系统。OpenMetrics其实是基于Prometheus的指标格式，而后者又是采用Borgmon的运营经验，Borgmon实现了“白盒监控”和低开销的海量数据收集，有着超过300家的服务输出商。

日志和跟踪： Fluentd采用统一的方法，对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。另外，还有Jaeger是一个开源的分布式跟踪系统解决方案，它与OpenTracing日志跟踪软件兼容。

容器注册：Harbor最初是由VMWare作为开源解决方案开发的，是一个开源可信任的容器注册器，用于存储、标记和扫描Docker镜像，提供了免费的、增强的Docker注册特性和功能。

☁️云原生介绍

CNCF给出了云原生应用的三大特征：

• 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。

• 动态管理：通过集中式的编排调度系统来动态的管理和调度。

• 面向微服务：明确服务间的依赖，互相解耦。

云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成。

这边引用网上关于云原生所需要的能力和特征总结，如下图。

云原生所需要的能力和特征

☁️十二要素

12-Factors经常被直译为12要素，也被称为12原则，12原则由公有云PaaS的先驱Heroku于2012年提出，目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下：

• 基准代码

• 显式声明依赖关系

• 在环境中存储配置

• 把后端服务当作附加资源

• 严格分离构建、发布和运行

• 无状态进程

• 通过端口绑定提供服务

• 通过进程模型进行扩展

• 快速启动和优雅终止

• 开发环境与线上环境等价

• 日志作为事件流

• 管理进程

另外，除了上述的12要素外，还有补充的三点跟API、认证授权和监控告警相关的要素。

• API声明管理

• 认证和授权

• 监控与告警

距离12原则的提出已有五年多，12原则的有些细节可能已经不那么跟得上时代，也有人批评12原则的提出从一开始就有过于依赖Heroku自身特性的倾向。不过不管怎么说，12原则依旧是业界最为系统的云原生应用开发指南。

☁️容器化封装

Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。Docker背后的想法是创建软件程序可移植的轻量容器，让其可以在任何安装了Docker的机器上运行，而不用关心底层操作系统。

Docker可以解决虚拟机能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包括：

• 隔离应用依赖

• 创建应用镜像并进行复制

• 创建容易分发的即启即用的应用

• 允许实例简单、快速地扩展

• 测试应用并随后销毁它们

自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。在看似稳定而成熟的场景下，使用Docker的好处越来越多。

☁️服务编排

Kubernetes——让容器应用进入大规模工业生产。这个总结确实很贴切。编排调度的开源组件还有Kubernetes、Mesos和Docker Swarm。

Kubernetes是目前世界上关注度最高的开源项目，它是一个出色的容器编排系统。Kubernetes出身于互联网行业的巨头Google公司，它借鉴了由上百位工程师花费十多年时间打造Borg系统的理念，通过极其简易的安装，以及灵活的网络层对接方式，提供一站式的服务。

Mesos则更善于构建一个可靠的平台，用以运行多任务关键工作负载，包括Docker容器、遗留应用程序（例如Java）和分布式数据服务（例如Spark、Kafka、Cassandra、Elastic）。Mesos采用两级调度的架构，开发人员可以很方便的结合公司业务场景自定制MesosFramework。

他们为云原生应用提供的强有力的编排和调度能力，它们是云平台上的分布式操作系统。在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势，而对于容器的编排管理，Swarm、Mesos和Kubernetes的大战已经基本宣告结束，Kubernetes成为了无可争议的赢家。

☁️微服务架构

传统的Web开发方式，一般被称为单体架构所有的功能打包在一个WAR包里，基本没有外部依赖(除了容器)，部署在一个JEE容器里，包含了DO/DAO，Service，UI等所有逻辑。其架构如下图所示。

传统的单体架构

单体架构进行演化升级之后，过渡到SOA架构，即面向服务架构。近几年微服务架构是最流行的架构风格，旨在通过将功能模块分解到各个独立的子系统中以实现解耦，它并没有一成不变的规定，而是需要根据业务来做设计。微服务架构是对SOA的传承，是SOA的具体实践方法。微服务架构中，每个微服务模块只是对简单、独立、明确的任务进行处理，通过REST API返回处理结果给外部。

在微服务推广实践角度来看，微服务将整个系统进行拆分，拆分成更小的粒度，保持这些服务独立运行，应用容器化技术将微服务独立运行在容器中。过去设计架构时，是在内存中以参数或对象的方式实现粒度细化。微服务使用各个子服务控制模块的思想代替总线。不同的业务要求，服务控制模块至少包含服务的发布、注册、路由、代理功能。

容器化的出现，一定程度上带动了微服务架构。架构演化从单体式应用到分布式，再从分布式架构到云原生架构，微服务在其中有着不可或缺的角色。微服务带给我们很多开发和部署上的灵活性和技术多样性，但是也增加了服务调用的开销、分布式系事务、调试与服务治理方面的难题。

Spring Cloud整体架构图

从上图Spring Cloud组件的架构可以看出在微服务架构中所必须的组件，包括：服务发现与注册、熔断机制、路由、全局锁、中心配置管理、控制总线、决策竞选、分布式会话和集群状态管理等基础组件。

Spring Cloud VS Kubernetes

Spring Cloud和Kubernetes有很大的不同，Spring Cloud和Kubernetes处理了不同范围的微服务架构技术点，而且是用了不同的方法。Spring Cloud方法是试图解决在JVM中的微服务架构要点，而Kubernetes方法是试图让问题消失，为开发者在平台层解决。Spring Cloud在JVM中非常强大，Kubernetes管理那些JVM很强大。看起来各取所长，充分利用这两者的优势是自然而然的趋势了。

☁️小结

技术架构的演变非常快，各种新的名词也是层出不穷。本文主要是对云原生的概述。云原生应用的三大特征：容器化封装、动态管理、面向微服务。首先由CNCF组织介绍了云原生的概念，然后分别对这三个特征进行详述。云原生架构是当下很火的讨论话题，是不同思想的集合，集目前各种热门技术之大成。

☁️云原生相关技术图谱

☁️CNCF 的云原生全景图

☁️云原生全景图的 4 层

剥离掉所有单个的技术，仅查看类别（如下图）。

图中有不同的“行”，像建筑的不同层，每层都有自己的子类别。最底层提供了构建云原生基础设施的工具。往上，你可以开始添加运行和管理应用程序所需的工具，比如运行时和调度层。在最上层，有定义和开发应用程序的工具，比如数据库、镜像构建和 CI/CD 工具。

☁️供应层 （Provisioning）

供应指的是为云原生应用准备标准基础环境所涉及的工具。它包含了基础设施的创建、管理、配置流程的自动化，以及容器镜像的扫描、签名和存储等。供应层通过提供设置和实施策略，在应用程序和平台中构建身份验证和授权，以及处理密钥分发等等的工具，也拓展到了安全领域。

供应层包括：

• 自动化和部署工具： 帮助工程师在无需人工干预情况下即可构建计算环境；

• 容器注册表： 存储应用程序的可执行文件；

• 不同安全领域的安全和合规框架；

• 密钥管理解决方案： 通过加密确保只有授权的用户才能访问特定的应用程序。

这些工具使工程师可以编写基础设施参数，使系统可以按需搭建新环境，确保了一致性和安全性。

☁️运行时层（Runtime）

接下来是运行时层。这个词可能会让你感到迷惑。像很多 IT 术语一样，运行时没有严格的定义，且可以根据语境有不同的用法。狭义上讲，运行时是特定机器上准备运行应用程序的沙盒——也就是保障应用程序正常运行所需的最低配置。广义上讲，运行时是运行一个应用程序所需的所有工具。

在 CNCF 云原生全景图中，运行时保障了容器化应用程序组件的运行和通信， 包括：

• 云原生存储： 为容器化应用提供虚拟磁盘或持久化存储；

• 容器运行时： 为容器提供隔离、资源和安全；

• 云网络： 分布式系统的节点（机器或进程）通过其连接和通信。

☁️编排和管理层（Orchestration and Management）

一旦按照安全和合规性标准（供应层）自动化基础设施供应，并安装了应用程序运行所需的工具（运行时层），工程师就需要弄清楚如何编排和管理应用程序。

编排和管理层将所有容器化服务（应用程序组件）作为一个群组管理。这些容器化服务需要相互识别和通信，并需要进行协调。这一层可为云原生应用提供自动化和弹性能力，使云原生应用天然具有可扩展性。

这一层包含：

• 编排和调度： 部署和管理容器集群，确保它们具有弹性伸缩能力，相互之间低耦合，并且可扩展。事实上，编排工具（绝大多数情况下就是 Kubernetes）通过管理容器和操作环境构成了集群；

• 协调和服务发现： 使得服务（应用程序组件）之间可以相互定位和通信；

• 远程进程调用（RPC）： 使跨节点服务间通信的技术；

• 服务代理： 服务间通信的中介。服务代理的唯一目的就是对服务之间的通信进行更多控制，而不会对通信本身添加任何内容。服务代理对下面将提到的服务网格（service mesh）至关重要。

• API 网关： 一个抽象层，外部应用可通过 API 网关进行通信；

• Service Mesh： 某种程度上类似于 API 网关，它是应用程序进行通信的专用基础架构层，提供基于策略的内部服务间通信。此外，它还可能包含流量加密、服务发现、应用程序监控等内容。

☁️应用定义和开发层 （Application Definition and Developement)

现在，我们来到了最顶层。应用定义和开发层，顾名思义，聚集了让工程师构建和运行应用程序的工具。上述所有内容都是关于构建可靠、安全的环境，以及提供全部所需的应用程序依赖。

这一层包括：

• 数据库： 使应用程序能以有序的方式收集数据；

• 流和消息传递： 使应用程序能发送和接收消息（事件和流）。它不是网络层，而是让消息成为队列并处理消息的工具；

• 应用程序定义和镜像构建： 用于配置、维护和运行容器镜像（应用程序的可执行文件）的服务；

• 持续集成和持续交付（CI/CD）： 使开发者可自动测试代码是否与代码库（应用程序的其余部分）兼容。如果团队足够成熟，甚至可以自动部署代码到生产环境。

☁️贯穿所有层的工具

可观察性和分析（Observability&analysis）是监控各层的工具，平台则将各层中不同的技术捆绑为一个解决方案。

☁️可观察性和分析（Observability and Analysis）

为了限制服务中断并降低解决问题的平均时间（MRRT），你需要监控和分析应用层序的方方面面，以便在出现异常时可立即发现并纠正。复杂环境中容易出现故障，这些工具可快速识别并解决故障，从而降低故障带来的影响。由于这一类别贯穿并监控各层，因此它在侧面，而不是嵌入到某一层中。

这这一类别你将发现：

• 日志工具： 收集事件日志（有关进程的信息）；

• 监控方案： 收集指标（以数字表示的系统参数，例如 RAM 可用性）；

• 追踪工具： 追踪比监控更进了一步，它们监控用户请求的传播，与服务网格相关。

• 混沌工程（Chaos Engineering）： 在生产环境中测试软件的工具，可识别缺陷并进行修复，减少其对服务交付的影响。

☁️平台类（Platform）

每一个模块解决一个特定的问题。仅有存储并不能提供应用程序所需的全部功能。还需要编排工具，容器运行时，服务发现，网络，API 网关等等。平台覆盖多层，将不同的工具组合在一起，以解决更大的问题。

配置和微调不同的模块使其安全可靠，并确保它利用的技术都能及时更新、所有漏洞都打了补丁，这并不是一件容易的事情。使用平台时，用户不用额外担心这些细节问题。

你可能会注意到，所有的类别都围绕着 Kubernetes 展开。这是因为 Kubernetes 虽然只是云原生景观图这张拼图中的一块，但它却是云原生技术栈的核心。顺便说一下，CNCF 刚创建时，Kubernetes 就是其中的第一个种子项目，后来才有了其他项目。

平台可分为四类：

• Kubernetes 发行版： 采用未经修改的开放源代码（尽管有人对其进行了修改），并根据市场需要增加了其他功能；

• 托管的 Kubernetes： 类似于 Kubernetes 发行版，但是由提供商托管；

• Kubernetes 安装程序： 自动执行 Kubernetes 的安装和配置过程；

• PaaS/容器服务： 类似于托管的 Kubernetes，但是包含了一套更广泛的应用部署工具（通常是来自云原生景观图）。

☁️小结

在选择技术栈时，工程师必须仔细考虑每种能力和需要权衡取舍的地方，以确定最合适的选项。
虽然这样会让情况变得更复杂，但在选择应用程序所需的最适合的数据存储、基础设施管理、消息系统等方案时，这样做是最可行的办法。现在，构建一个系统比云原生之前的时代容易多了。如果构建恰当，云原生技术将提供更强大的灵活性。

参考文献

云原生技术的前世今生
关于云原生，这是最详细的技术知识
云原生生态中的技术栈