目前云计算，云原生，微服务等概念已经不绝于耳，目前来说，上云已经是一种必然的趋势。

云原生

云原生最早是在2010年在一篇blog中被提出，后来在2015年Pivotal公司的Matt Stine写了一本叫做迁移到云原生应用架构的报告，其中探讨了云原生应用架构的几个主要特征：

  • 符合12因素应用
  • 面向微服务架构
  • 自服务敏捷架构
  • 基于API的协作
  • 抗脆弱性

这是开发者对云原生的早期印象，到了2015年Google主导成立了云原生计算基金会（CNCF），起初CNCF对云原生（Cloud Native）的定义包含以下三个方面：

  • 应用容器化
  • 面向微服务架构
  • 应用支持容器的编排调度

到了2018年，由于云原生的生态发展，微服务的兴起，这是CNCF给出了大家比较认可的定义，可以看官方原文。

  • 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

  • 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

  • 云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

这个时候云原生基本概念已经基本被大家所认可。其实核心就是云原生的代表技术

容器

容器其实也就是指主流的容器技术，比如Docker、LXD以及RKT等，还有基于容器之上的编排工具kubernetes，目前来说，容器是云最好的载体。

微服务

微服务其实就是将传统的系统打散，进入到serviceless时代，更加注重服务自身的实现，这样来说，服务更加灵活，效率更高。

服务网格

Docker 和 Kubernetes 这样的工具已经 解决了部署问题，还没有解决运行时的问题，这就是服务网格的由来。Service Mesh在微服务的连接、管理和监控方面为Kubernetes提供更好的应用和服务管理。

声明式API

通过控制器实现期望的状态。

不可变基础设施

不可变基础设施其实字面就可以理解基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不在进行更改，只能创建新的来整体替换旧的。这样可以解决可变基础设施中常见的问题，比如

  • 在灾难发生的时候，难以重新构建服务。
  • 持续过多的手工操作，缺乏记录，会导致很难由标准初始化后的服务器来重新构建起等效的服务。
  • 在服务运行过程中，持续的修改服务器，就犹如程序中的可变变量的值发生变化而引入的状态不一致的并发风险。这些对于服务器的修改，同样会引入中间状态，从而导致不可预知的问题。

那我们再来看看字面的Cloud Native，其实就是就是云（云计算）和原生（土著）的意思——云计算上的原生居民。

  • 云计算其实我们已经很熟悉了，云的本质就是高效提供稳定的计算存储等资源，也就是云计算的概念，所以云基本具备虚拟化、弹性扩展、高可用、高容错性、自动恢复的属性。
  • 基于云之上的原生居民其实也就是云原生程序，应该具备分布式（微服务），自动化（CD/CI），能够适应所有云端的特性。

个人觉得云原生的最终的目的都是将应用中非业务代码部分最大程度的剥离，从而让云平台接管应用中大量非功能性的特性，比如弹性，灰度等，让业务不受非功能性的影响，可以设计为轻量分布式，敏捷自动化等特性。

云原生架构

这张图可以看出云原生的基本生态，很多重要组件就是我们组件云生态的核心。

云原生过程

云原生基础设施不等于在公有云上运行的基础设施。光是租用服务器并不会使您的基础设施云原生化，如果只是这样和管理 IaaS 的流程与运维物理数据中心没什么两样，将现有架构迁移到云上也未必能获得回报。

云原生也不是指在容器中运行应用程序。在容器中运行只不过是改变应用程序的打包方式并不意味着就会增加自治系统的可扩展性和优势。即使应用程序是通过 CI/CD 渠道自动构建和部署的，也不意味着您就可以从增强 API 驱动部署的基础设施中受益。但是使用容器和容器编排工具我们可以实现动态调度的平台功能，这是一个很好的起步。

所以构建容器平台是云原生过程中必然的一个步骤，我们需要使用容器，编排调度来实现基础设施的云原生，下面会对容器平台做详细的说明，有了底层的容器平台，上层的云原生程序也是实现业务微服务的关键，当然要实现基础设施的高效低成本的使用是一个漫长的建设过程。

云原生应用程序

云原生应用程序是指在自治系统下运行的应用程序，一般具有弹性，敏捷性，可操作性和可观察性。

  • 弹性根据健康数据和监控数据来做自动伸缩，利用了在平台上运行的动态特性。
  • 敏捷性允许快速部署和快速迭代。
  • 可操作性从应用程序内部控制应用程序生命周期，而不是依赖外部进程和监视器。
  • 可观察性提供信息来回答有关应用程序状态的问题。

目前对于云原生应用的开发，还处于初始阶段，各大厂商还在致力于规范的定义，框架的开发，目前比较前沿的就是OAM（Open Application Model）规范，比如目前Rudr，Crossplane项目，都是基于OAM开发的。

OAM 的规范中定义了以下对象，它们既是 OAM 规范中的基本术语也是云原生应用的基本组成。

  • Workload（工作负载）：应用程序的工作负载类型，由平台提供。
  • Component（组件）：定义了一个 Workload 的实例，并以基础设施中立的术语声明其运维特性。
  • Trait（特征）：用于将运维特性分配给组件实例。
  • ApplicationScope（应用作用域）：用于将组件分组成具有共同特性的松散耦合的应用。
  • ApplicationConfiguration（应用配置）：描述 Component 的部署、Trait 和 ApplicationScope。

云原生本身有许多开发模式设计理念，都是我们需要考虑到的，比如我们很多都是遵循k8s的设计模式来开发：

  • 面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
  • 面向配置设计（Configuration）：一个镜像，多个环境配置；
  • 面向韧性设计（Resistancy）：故障容忍和自愈；
  • 面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
  • 面向交付设计（Delivery）：自动拉起，缩短交付时间；
  • 面向性能设计（Performance）：响应式，并发和资源高效利用；
  • 面向自动化设计（Automation）：自动化的 DevOps；
  • 面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
  • 面向安全性设计（Security）：安全端点、API Gateway、端到端加密；

其实这些更像是在传统架构的基础上加了一层控制器，来实现智能化的架构基础，其实在k8s中控制器和声明式api是核心思想所在，这是我对目前云的设计开发的一种理解。

云原生编程语言

这边并不是说golang这个开发语言，而且针对yaml的语言。下面一段话说明了为什么要有云原生编程语言

对于每一个serverless函数来说，我都要写几十行的JSON或者YAML配置。要链接到一个API端点，我还要学习晦涩的概念，执行一系列复制-粘贴的低级工作。如果我想在本机上运行一个小的集群的话，那么Docker还是很棒的，但是如果要在生产上使用的话，那么就要手动管理etcd集群，配置网络和iptables路由表，还有一系列与我的应用程序本身不相干的事情。不过Kubernetes的出现至少让我可以配置一次下次就可以跨云平台重用，但这还是会分散开发人员的精力。

其实编程的许多方面都经历了类似的转变过程

  • 汇编转c语言：在80年代初，我们使用汇编语言对微处理器进行了编程。最终，编译器技术进步了，我们可以同时处理多种常见的架构。像FORTRAN和C这样的Low-level的编程语言开始兴起。
  • 低级语言转高级语言：在90年代初期，我们直接针对低级别操作系统原语进行编程，无论是POSIX系统调用还是Win32 API，并进行手动内存和资源管理。最终，语言运行时技术和处理器速度提升到了可以使用更高级别语言的状态，如Java。除了动态语言之外，这种趋势已经加速，如JavaScript统治了Web。
  • 单线程转并发：在21世纪初期，我们的编程模型中的共享内存并发性最好是原始的（我花了很多时间在这个问题上）。现在，我们简单地假设OS具有高级线程共享、调度和异步IO功能，以及编程到更高级别的API，例如任务和承诺。

所以云原生目前已在进行这种类似的转变，最终会有一场NoYAML运动的出现。

总结

云原生其实更多的是一种概念，可以是一种架构，容器化，微服务，编排调度，这也是cncf给出的定义，也可以是一种开发模式，使得我们的程序面向分布式，弹性，解耦，自动化等编程模式，其实也是我们开发云原生应用程序所需要考虑的因素，当然云原生更是一种文化，更是一种潮流，发展到一定阶段的产物。它的意义在于让云成为云化战略成功的基石，而不是阻碍，如果业务应用上云之后开发和运维人员比原先还痛苦，成本还高的话，那就没有什么意义了。

所以云原生并不是简单的上云，而是要实现

  • 敏捷
  • 可靠
  • 高弹性
  • 易扩展
  • 故障隔离保护
  • 不中断业务持续更新

只有实现这这些上云才有意义，才可以降成本，提效率，迅速定位问题。

云计算

云计算：一种利用互联网实现随时随地、按需、便捷地使用共享计算设施、存储设备、应用程序等资源的计算模式。当然在云原生的基础上可以实现资源的高效利用，云原生注重的是生态建设，云计算相对云原生来说更像一种商业的盈利的模式，也可以说是一种资源的高效整合使用。

云计算是指基于互联网等网络，通过虚拟化方式共享IT资源的新型计算模式。其核心思想是通过网络统一管理和调度计算、存储、网络、软件等资源，实现资源整合与配置优化，以服务方式满足不同用户随时获取并扩展、按需使用并付费，最大限度地降低成本等各类需求。

云的商业价值就在于降本：机器成本和人力成本。

  • 降本：机器成本和人力成本
  • 提效：提高资源的使用率，提高开发的效率

云计算系统由云平台、云存储、云终端、云安全四个基本部分组成。

目前云计算提供的服务模式主要包含三大类：基础设施即服务（IaaS）、平台即服务（PaaS）、软件即服务（SaaS）。

基础设施即服务（IaaS）

云计算服务商提供虚拟的硬件资源，如虚拟的主机、存储、网络、安全等资源，用户无需购买服务器、网络设备和存储设备，只需通过网络租赁即可搭建自己的应用系统。IaaS定位于底层，向用户提供可快速部署、按需分配、按需付费的高安全与高可靠的计算能力以及存储能力租用服务，并可为应用提供开放的云基础设施服务接口，用户可以根据业务需求灵活定制租用相应的基础设施资源。在这种服务模式下，用户无需考虑对琐碎的基础设施进行管理与维护，用户可直接在基础设施上面方便地加载应用。

IaaS服务对应的用户是系统管理员。传统的虚拟机的应用，都是需要管理员进行管理，然后开发人员负责开发，运维人员负责部署，机器有系统管理员统一管理。

IaaS已经很成熟了，各大厂商都能提供虚拟机，比如阿里云。

平台即服务（PaaS）

PaaS提供商提供应用服务引擎，将软件研发测试和运维的平台作为一种服务提供，如应用程序接口（API）服务或应用运行时服务，用户基于这些服务构建业务应用。从用户角度来说，这意味着他们无需自行搭建开发，测试和运维平台，也不会在不同平台兼容性方面遇到困扰。

PaaS服务对应的用户是应用的开发者和运维人员。

paas的核心建设

软件即服务（SaaS）

用户通过标准的 Web 浏览器来使用网络上的软件。从用户角度来说，这意味着前期无需在服务器或软件许可证授权上进行投资；从供应商角度来看，与常规的软件服务模式相比，维护一个应用软件的成本要相对低廉。SaaS供应商通常是按照客户所租用的软件模块来进行收费的，因此用户可以根据需求按需订购软件应用服务，而且SaaS的供应商会负责系统的部署、升级和维护。比如我们常用的邮箱服务等。

SaaS提供商对应的用户是应用软件使用的终端用户。

现在市场上也有saas应用已经很成熟了。其实就是我们开箱即用的服务，也可以理解为运行在paas平台上的应用。但是paas确实千变万化的。

雾计算

边缘计算也就是雾计算，和传统的中心化思维不同，他的主要计算节点以及应用分布式部署在靠近终端的数据中心，这使得在服务的响应性能、还是可靠性方面都是高于传统中心化的云计算概念，

具体而言，边缘计算可以理解为是指利用靠近数据源的边缘地带来完成的运算程序。

那么，边缘计算和云计算之间的区别是什么？

  1. 其实如果说云计算是集中式大数据处理，边缘计算则可以理解为边缘式大数据处理。但不同的是，只是这一次，数据不用再传到遥远的云端，在边缘侧就能解决。

  2. 边缘计算更适合实时的数据分析和智能化处理，相较单纯的云计算也更加高效而且安全！

边缘计算和云计算两者实际上都是处理大数据的计算运行的一种方式。边缘计算更准确的说应该是对云计算的一种补充和优化

边缘计算而言有以下几个特质

  1. 分布式和低延时计算边缘计算聚焦实时、短周期数据的分析，能够更好地支撑本地业务的实时智能化处理与执行

  2. 效率更高由于边缘计算距离用户更近，在边缘节点处实现了对数据的过滤和分析，因此效率更高

  3. 更加智能化AI+边缘计算的组合出击让边缘计算不止于计算，更多了一份智能化

  4. 更加节能云计算和边缘计算结合，成本只有单独使用云计算的39%

  5. 缓解流量压力在进行云端传输时通过边缘节点进行一部分简单数据处理，进而能够设备响应时间，减少从设备到云端的数据流量