浅谈云原生
目录
3.4 不可变基础设施 (Immutable Infrastructure)
1. 云原生是什么？
可以把云原生拆分为云和原生。
云：就指云服务器，代替本地服务器。
在云服务器流行起来之前，我们都是通过自己购买物理服务器的方式把我们的项目部署起来的。我们需要购买物理机器，要向网络运行商购买公网 IP 服务，还要在公司找个地方放这些机器，作为服务器机房。
有了云服务器之后，公司不再需要购买物理设备了，我们想要上线部署自己的项目，只需要向云服务器提供商购买，就能拥有自己的服务器了，而云服务器和传统服务器相比，有很多传统服务器无法比拟的优点。比如弹性、分布式等等。
原生：指土生土长。我们程序在开发设计的时候，在本地自建服务器运行和在云服务器运行，项目的架构设计等方面，都是完全不一样的。
而原生，就是指，应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，要充分利用云上资源的优点，从而使我们的的应用更强大，更迅速、更稳定。
云 + 原生
所以，云原生指的并不是某个技术，它更像是一个技术体系。
就举个例子，云原生你不熟悉，那大数据总该熟悉了吧？而大数据，里面包括的 Spark、Hadoop 等技术。
云原生也是这样，也是由一些我们经常熟知的技术所组成的。我们接着往下看。
怎么让云原生的概念落地呢，比如之前提出了一个 devops 的概念，到底什么是 devops 呢？于是就有人开始落地方案，只有落地了才能有更多人用，环境更完善。
云原生落地的定义
来自一个红帽的技术大牛提出了一个概念：基于微服务原理而开发应用，以容器方式打包 *,（到这里，就是原生的概念）* 在运行时，容器基于云基础设施之上的平台进行调度，应用开发采用持续交付和 DevOps 实践（到这里就是云的概念）两个概念加起来就是云原生。
云原生技术有利于各组织在公有云，私有云和混合云等新型动态环境中，构建运行可弹性扩展应用，这些技术构建起来容错性高，易于管理，便于观察的松耦合系统。让工程师轻松的对系统作出频繁和可预测的变更。
综上所述，云原生本质上就是用容器化封装 + 自动化管理 + 微服务 + 服务网格 + 声明式 API 实现的。
2. 云原生四要素
云原生这个概念的提出来源于谷歌主导的一个基金会原原生计算基金会简称是 CNCF。
CNCF 在经过了好几代的更新之后，他给出了一个回答， 云原生的四要素包括：
2.1 微服务
几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，大概意思是组织架构决定产品形态。微服务架构的好处就是按 function 切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据 DDD 来搞。
2.2 容器化
Docker 是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于 LXC 技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S 是容器编排系统，用于容器理，容器间的负载均衡，谷歌搞的，Docker 和 K8S 都采用 Go 编写，都是好东西。
2.3 DevOps
这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上 DevOps 应该还包括测试，DevOps 是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。
2.4 持续交付
持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。
这几个要素还是有点抽象啊。其实业界最有共识的，符合云原生架构的落地应用体系是采用 k8s+docker 进行容器化部署，基于微服务架构开发前后端完全分离的应用，提高灵活性和可维护性，借助敏捷迭代方法支持功能持续迭代完善的对方工具，支持上线发布自动化利用云平台设施实现弹性伸缩，动态调整，最优化资源利用率，这样的架构共建应用简便快捷，部署应用轻松自如，运行应用 5G 流量分布秒杀传统的为应用架构，吊打以往的 IT 建设模式，是整个互联网技术发展到今日的集大成体系。
3. 具体的云原生技术有哪些？
云原生技术有很多，大体可以分为以下 5 种：容器、服务网格、声明书 API、不可变基础设施、微服务。
3.1 容器 (Containers)
终端容器化封装是指以容器为基础，应用程序封装在容器之中，在容器里运行，实现资源的相对隔离与容器镜像的重复使用，因为使用的容器化技术应用运行于容器之中，就不需要考虑底层硬件的差异，这大大简化了开发的工作量，同时对于运维人员也极为友好，不需要再为环境问题而苦恼。使用到的技术包括 Docker 和 k8s。
3.2 微服务 (Microservices)
面向微服务是指把一个大的功能应用拆分成一个个功能单一，相对独立，相互解耦的微应用。微应用之间通过接口进行通讯，使用的的微服务技术比如 SpirngCloud
3.3 服务网格 (Service Meshes)
服务网格（Service Mesh）是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。
服务网格的目的，就是去中心化的服务治理框架。
以往对微服务或者 api 接口做治理和管控会用类似 ESB 服务总线或者 API 网关，把 API 接口注册接入到 APi 网关，API 网关本身是一个中心化的结构，所有请求流量都可以通过 API 网关，它来实现流量拦截，同时对拦截后的流量进行安全，日志，限流熔断，链路监控等各种管控治理，去中心化之后就没有这种集中化流量管理点了，对流量的拦截就下沉到各种微服务中了，这就是我们为什么要在微服务端增加一个代理包的原因，通过这个代理包做流量拦截，同时实现对流量的管控，服务网格也是用同样的思想来治理的。
3.4 不可变基础设施 (Immutable Infrastructure)
在传统的开发中，如果做一个软件的部署，部署到一个生产环境之后再去做一个变更，不管是应用程序或者配置变更，都需要在原来的环境重新部署，在云原生应用中，你部署一个应用，它会自动生成实例，这个实例不应该再做任何改变，如果要重新配置或者修改的话可以用基础容器镜像重新生成实例，同时把旧的容器销毁，这就是云原生中的不可变技术点。
3.5 声明式 API (Deciarative API)
声明式 API 是 Kubernetes 的技术点，它的核心原理，就是当用户向 Kubernetes 提交了一个 API 对象的描述之后，Kubernetes 会负责为你保证整个集群里各项资源的状态，都与你的 API 对象描述的需求相一致。更重要的是，这个保证是一项 “无条件的”、“没有期限” 的承诺：对于每个保存在 etcd 里的 API 对象，Kubernetes 都通过启动一种叫做 “控制器模式”（Controller Pattern）的无限循环，不断检查，然后调谐，最后确保整个集群的状态与这个 API 对象的描述一致。简单理解就是对象的声明与对象的创建相解耦，在普通程序中创建对象需要向操作系统申请资源，相似的，在容器云平台上创建对象，需要向 k8s 申请资源。但 k8s 更进一步的是，你只需要提交一个申请单，然后由 k8s 系统完成对象的创建。
这些技术只是云原生组成的一部分，但是，这些技术，我们自己机房服务器，也能使用，换句话来说，如果不是云环境，就算有了这些技术，这不是云原生，云原生，一定是基于云服务器的。
4. 云服务器优势
4.1 灵活性
云服务器采用虚拟化技术，整合了大量集群主机的计算、网络与存储资源，其 CPU、内存、硬盘、带宽等资源都可以弹性扩容，按需取用；公司的项目，都有一个特点，就是访问量不是固定的，在做活动的时候，访问量会是日常流量的几倍，为了应对这种情况，如果是物理服务器，公司就必须随时准备能应对流量最高峰的物理设备，但在流量高峰过后，这些物理设备不能像云服务器那样释放，不灵活。
4.2 安全稳定性
基于集群服务器，云服务器拥有更强的主机性能，运行更安全、稳定；
4.3 方便性
云服务器操作及升级更方便，传统服务器中的资源都是有限的，如果想要获得更好的技能，只能升级云服务器，所谓 “云”，就是网络、互联网的意思，云服务器就是一种简单高效、安全可靠、处理能力可弹性伸缩的计算服务。其操作起来更加简便，如果原来使用的配置过低，完全可以在不重装系统的情况下升级 CPU、硬盘、内存等，不会影响之前的使用；
4.4 低成本
云服务器有更高的性价比，云服务器是按需付费的，与传统服务器相比，用多少买多少，而且并不会造成资源浪费，而传统物理服务器，必须准备满足流量高峰的设备数量。
5. 云原生的好处
- 快速云原生架构使用敏捷开发和迭代，不但可以让企业快速的进行开发，同时还能持续地更新产品，让产品跟得上需求，甚至是引导需求，让企业立于不败之地。
- 弹性扩展云原生架构天生具有云计算的特点，资源可以按需进行伸缩，这样不单提高资源的利用率，也大大降低了企业成本。
- 强壮云原生架构依托于容器编排工去 k8s 与微服务的组合应用，就拥有了自动恢复能力，容错能力，故障隔离能力，让应用更强。
- 屏蔽底层差异，因为使用的容器化技术应用运行于容器之中，就不需要考虑底层硬件的差异，这大大简化了开发的工作量，同时对于运维人员也极为友好，不需要再为环境问题而苦恼。
6. 总结
说了这么多，你可以简单的理解为，云原生就是换了个开发环境，由物理服务器换到了云服务器，然后为了适应这个云服务器的环境做了一些技术架构调整，这就是云原生。