如今谈及技术，就是云，就是云原生，所闻的不谈，仅我亲眼所见，真可谓百花齐放，有人把k8s称为云，有人把docker称为云，有人把微服务甚至spring boot称为云，更有甚者将web服务乃至java称为云。
而打开搜索引擎，以"云原生"为关键词检索，所得也是百家争鸣，但是归纳之下也无非就是以下模板的实例化，1. 国外引入听不懂的概念 + 2. 开源技术名词的罗列 + 3. 贩卖焦虑 + 4. 广告、加微信或者九块九卖课
所以，到底什么是云原生?
个人拙见，云原生既不是硬件，也不是软件，而是一种人为归纳的理念。因为这个概念是人归纳或者说创造的，故在这上面充分展示人主观意志的多样性就不足为奇了。
常见对云原生的解释
十二要素(太长不用记)
众所周知，四大天王有五个，依次类推，云原生十二要素也有十五个
在超越十二要素应用一书中，作者 Kevin Hoffman 详细介绍了原始的所有 12 个要素（于 2011 年撰写）。 此外，他讨论了反映当今新式云应用程序设计的三个额外要素。
1 - 基本代码
每个微服务都有单个基本代码，存储在其自己的存储库中。 它通过版本控制进行跟踪，可以部署到多个环境（QA、暂存、生产）。
2 - 依赖项
每个微服务都隔离并打包其自己的依赖项，以在不影响整个系统的情况下进行更改。
3 - 配置
配置信息通过代码之外的配置管理工具移出微服务和实现外部化。 在应用了正确配置的情况下，相同部署可以在环境间传播。
4 - 支持服务
辅助资源（数据存储、缓存、消息中转站）应通过可寻址 URL 进行公开。 这样做可使资源与应用程序分离，使其可以互换。
5 - 生成、发布、运行
每个版本都必须在生成、发布和运行阶段执行严格的分离。 各自都应使用唯一 ID 进行标记，并支持回滚功能。 新式 CI/CD 系统有助于实现此原则。
6 - 进程
每个微服务应在其自己的进程中执行，与其他正在运行的服务隔离。 将所需状态外部化到支持服务，如分布式缓存或数据存储。
7 - 端口绑定
每个微服务都应是独立的，其接口和功能在自己的端口上公开。 这样做可与其他微服务隔离。
8 - 并发
当容量需要增加时，跨多个相同进程（副本）横向扩展服务，而不是在功能最强大的可用计算机上纵向扩展单个大型实例。 将应用程序开发为并发应用程序，从而无缝地在云环境中横向扩展。
9 - 可处置性
服务实例应是可处置的。 支持快速启动以增加可伸缩性机会，以及支持正常关闭以使系统保持正确状态。 Docker 容器以及业务流程协调程序本质上满足此要求。
10 - 开发/生产等同
使整个应用程序生命周期中的各个环境尽可能相似，避免使用成本高昂的快捷方式。 在这里，通过促进相同的执行环境，容器的采用可以做出很大贡献。
11 - 日志记录
将微服务生成的日志视为事件流。 使用事件聚合器处理它们。 将日志数据传播到数据挖掘/日志管理工具（如 Azure Monitor 或 Splunk）并最终传播到长期存档。
12 - 管理员进程
以一次性进程形式运行管理性/管理任务，例如数据清理或计算分析。 使用独立工具从生产环境调用这些任务，但独立于应用程序。
新要素:
13 - API 优先
使一切成为服务。 假设前端客户端、网关或其他服务会使用你的代码。
14 - 遥测
在工作站上，你可深入了解应用程序及其行为。 在云中，你无法这样。 确保设计包括监视、特定于域和运行状况/系统数据的集合。
15 - 身份验证/授权
从开始便实现标识。 请考虑公有云中提供的 RBAC（基于角色的访问控制）功能。 我们将在本章和整本书中涉及超过 12 个要素中的许多要素。
六个特质(记住标题即可)
Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理 六个特质
四个要点
而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器
- 微服务
- 应用间通过RESTful API通讯
- 可以被独立的部署、更新、scale和重启
- DevOps
- 自动化发布管理、CI工具
- 快速部署到生产环境
- 开发、运维协同合作
- 持续交付
- 频繁发布、快速交付、快速反馈、降低发布风险
- 容器化
- 微服务最佳载体
宠物 (Pets) 与牲畜 (Cattle) ☆
在传统数据中心内，服务器被视为“宠物”：一台物理计算机，被赋予有意义的名称，并受到照料。 你通过将更多资源添加到相同计算机（纵向扩展）来进行缩放。如果服务器出现问题，你会进行修复，使它恢复正常运行状况。如果服务器不可用，则每个人都会注意到。
“牲畜”服务模型有所不同。你会将每个实例预配为虚拟机或容器。它们是相同的，并分配有系统标识符（如服务01、服务02 等等）。你通过创建更多实例（横向扩展）来进行缩放。当一个实例不可用时，无人会注意到。
牲畜模型采用不可变基础结构。服务器不会进行修复或修改。如果一台服务器发生故障或需要更新，则会销毁它并预配新服务器 – 所有操作都通过自动化完成。
这个概念是我最喜欢的，个人认为这个比喻最能体现出云原生时代的目标、理念和挑战。理解这背后的深意，远比死记硬背教条概念更重要。"纸上得来终觉浅，绝知此事要躬行"，在没有办法在现实世界中构建自己的云原生平台的前提下，在脑海中思考才是最低成本、最可行的躬行方案。
只是从一个家庭宠物饲养者转变为一个大牧场主对所有人来说都是一个艰巨的挑战，更何况放牧的还是赛博电子羊。所以请跟随我一起，去思考牧场主的挑战吧。
如何成为一个合格的赛博农场主
我在乎什么?
- 所有羊群的整体状态(多少只、健康状态、多少肥的、多少瘦的)。关键点: 可观察、可测试
- 羊群减员后可以快速补充。关键词: 模块化、可替换、可处理
- 最大可能避免羊群减员。关键词: 模块化、可观察
我不在乎什么?
- 单只羊的健康与死活
电子羊和普通羊区别是什么?
- 编号100的羊基本上和编号101、编号102的羊毫无差别，可以被无差别替换。但是在不做额外管理的前提下，编号100服务挂了，服务绝对会受影响。关键点: 将电子羊变成普通羊(模块化、可替换)
好了，当你成功的转换成了农场主思维后，我想你也应该能够轻松理解云原生到底想要什么了，我总结如下:
- 物理资源可以在虚拟化后被拆分，且虚拟化后资源具备等价性，可以被替换
- 资源之上的业务应用也随之做出拆分
- 拆分后业务应用的状态可以被良好监控，失效后可以被即使处理，根据业务量动态扩容和缩容
- 应用开发小步快走，逐步开发、交付、更新
所以这正好和云原生的四个要点相对应
- 容器化
- 微服务
- devops
- 持续交付
所以你应该可以理解什么是云原生了吧，云原生是种组织管理资源的理念，以及配套这种理念生长出的配套工具
什么是云?
既然大家理解了什么是云原生，那我们回归一个更加基本的概念，什么是云?
云不是云原生，云原生不是云，概念不要混淆。
正如我们上面所说的，云原生是种组织管理资源的理念，那么什么是资源呢?答案很明确，云就是被组织管理的资源，中国“十四五”规划中将云也认作是一个基础设施。
那么云是机房吗?答案很显然，不是?但是两者是有联系的，规模小的时候只是机房，当规模足够大的时候，就是云。
- 云相较于传统的IDC机房，有着额外的(或者说更加苛刻的)虚拟化需求(以及配套工具的需求)
- 规模足够大的前提下，又有着虚拟化的要求，意味着网络、存储、计算等基础设施层的需求都需要新的解决方案(这种解决方案需要全新的、相配套的软件和硬件)
云的分层
IaaS 基础设施即服务(Infrastructure-as-a-Service)
在国内，IaaS是大家最认可，也是最喜欢的方式，对于使用者而言，所购买的是一台台虚拟计算机，这些虚机在使用体验上和物理计算机一样。在这种情况下，使用者所有用到的组件，例如数据库、消息队列、缓存等都需要使用者手动搭建和维护。
至于虚机是如何被虚拟化出来的，如何管理的，占用多少物理资源，都是云厂商给提供的，使用者则不需要考虑。
但是很遗憾，如果如果云仅仅停留在这个层次，云在成本的优势没有办法发挥，这样基本上就是一个由云厂商维护的远程IDC而已。
PaaS 平台即服务(Platform-as-a-Service)
在这个层次，用户已经不需要手动搭建组件了，常用的组件，例如数据库、缓存、消息队列、对象存储、容器编排、日志服务、调度系统等，都由云服务供应商提供，这些组件一般都是业内知名的、客户端固定且被广泛认可(当然也有一些云服务供应商妄图提供一些完全自己定义的东西，很可惜大家不怎么认可)，使用这些服务和使用自建组件没有区别，且可以基本无成本的切换。
理论上我买一个裸机，自己安装运维数据库，成本一定是比使用PaaS服务要高很多的。但是大部分人使用下来感觉是成本很高，我认为这是由两部分原因造成的:
- 用户总是忽略一个关键事实，稳定性是要付钱购买的，且价值不菲。
- 服务提供商前期成本投入高，现阶段远远看不到收回成本的希望，所以只能想办法转嫁给使用者。
SaaS 软件即服务(Software-as-a-Service)
PaaS只提供给用户组件，基于组件构建应用程序的时候，还是需要使用者自己coding。但是很多功能在不同业务中是通用的，比如地图服务、身份验证、图像处理等，那是不是可以把这些通用的服务统一做出来，然后以API的方式暴露给使用者，这样就可以大大降低产品开发的成本。没错，这就是SaaS的产品思路。
但是，理想分丰满，现实很骨干。除了地图这种开发难度高，相对不关键的功能外，大家基本上都不认可，大家总能找出奇奇怪怪，合理或者不合理的理由:
- 数据安全、信息安全 (考虑政策风险，这个的确是风险)
- 有开源的实现方案
- 如果功能简单，自己可以雇人实现(其实更多是近似实现)
- 担心被服务商绑架，鬼知道他们每年会不涨价或者倒闭
FaaS 函数即服务(Function-as-a-Service)
即使是SaaS，仍然需要构建一个"主进程"，其它无论是API也好，组件也好，都是为整个"主进程"服务的。当然这个"主进程"可能是单体服务，也可以是一堆微服务。
这样没有什么问题，但是组织维护一个这样的应用程序，即使对于成熟的开发者来说都是一种不可忽视的负担。那么如何减轻这种负担，很简单，化整为零。
将整体功能拆分为一个一个的函数，每个函数的管辖范围要尽可能小。函数之间不再是通过主动调用其他函数的方式传递数据，构建应用，而是通过事件(event)驱动实现。
事件包括定时任务、请求、数据流、报警等等，函数的执行结果也可以作为事件传递出去。
函数被注册托管后，事件是通过框架作为函数入参注入到函数中，以及作为函数返回值被提取。函数的调用关系，组织关系都是通过框架实现的。
虚拟机和容器之争
虚拟化有两种方案，操作系统之上，即容器，操作系统之下，即虚拟机。
| 优点 | 缺点 | |
|---|---|---|
| 容器 | 轻量级 | 不够安全 |
| 虚拟机 | 足够安全 | 太重了 |
容器之间是共用os的，可以认为只是在os之上包了一层，而虚拟机则是先模拟物理层，然后运行单独的os。正可谓成也萧何败也萧何，所以这两者的优缺点都是互为镜像。
当然，当下在云原生概念下，容器是大占上风的，甚至K8S已经快成为了云原生的代名词了，这并不是意味着虚拟机一败涂地，因为它已经沉到了最底层。
