云原生应用
在我们的互联网应用当中，有一个词想必大家都很熟悉，叫做云原生，或者云原生应用。
那什么才是云原生呢？
在云原生概念中，有一个叫做云原生15原则，这15个原则我们可以分成四类：
- CICD
- 弹性
- 解耦
- 中台
CICD是和软件发布相关，弹性是和应用的特性相关，解耦是应用与应用之间的关系，最后一个中台是对外服务的形式。
只有说满足了15原则，我们才能说是一个很好的云原生应用了。
这里我们为什么来通过这个15原则来聊云原生呢？
很多人盲目上云，不是所有的应用都适合云，也不是所有应用都能叫云原生。
正是因为业界很多滥用名词，随便下定义，通常会给我们一些工程师造成误区。
现在市面上也有一些不好的习惯，说到云原生就是容器，只要把一个SpringBoot应用打包成一个Docker或者用K8s一编排就是云原生平台了。
其实远远不仅于此，云原生的概念远远不止于容器，也远远不止于K8S。
我们废话不多说，我们就看看到底什么才是小编心目当中的云原生。
Cloud Native
云原生的英文单词叫做 Cloud Native，这个Cloud Native大家首先想到的是什么，是不是用Kuberneties做容器化部署呢？
这里我们要阐明几个误区，Kuberneties不代表容器化，它只是容器化过程当中的一个编排环节的一个产品，容器化有很多，有容器化本身的隔离，也有容器的编排，还有容器的平台管理等等。编排只是一项，而编排技术也有很多，像Messos、swarm、Cloud Fountry、Kuberneties等等，Kuberneties只不过是当前的当红。这个当红也只是当前时代，将来时和过去时未必都是Kuberneties，所以也不能一叶障目。不能因为Kuberneties就认为所有容器就都只能用Kuberneties，也不能因为用了容器化我们就认为所有云原生都必须容器化，云原生有它自己真正的定位。
在以前大家可能都说12-Factor，也叫12因素，只要满足了12-Factor就是Cloud Native，12-Factor固然很不错，但是这只是2012年的概念，到现在都马上2022年了，已经过去了10年了，12因素其实已经淘汰了，各种因素的描述其实已经不太精准了，所以当前我们不叫12因素，而称为15原则。其中增加了3个原则，同时也调整了几个因素，到底哪些精髓让它保留了呢？
其中有一个就是持续交付即CICD，持续交付、持续集成、持续部署等，这种能力是上云的一个关键能力，当你上云的时候是不是希望你的应用快捷，是不是希望你的应用能全自动的流程化的处理，所以这种能力是Cloud Native本身必须具备的。
除此以外是DevOps，这个概念就是一个团队从头到尾，也就是从开发到测试到部署到运维，一个人可以完成整个微服务的全盘管理，一个人完成这种全生命周期管理的形态，就是DevOps，它也是和Cloud Native非常配合的一个名词。
还有就是微服务，其实所有的应用服务都是在做拆分的，有合必有分，有分必有合，我们把一个应用服务拆分成一个个小的微服务，然后让微服务之间通过服务治理，通过服务发现等等功能互相关联起来，最终体现出一种平台化的特质。所以当今时代微服务是主流，而Cloud Native恰恰可以满足微服务的需要，同时也希望你的应用变成微服务，这样的应用才是属于Cloud Native的范畴。
除了这些还有一个纽带性的内容，叫做康威定律，微服务要求我们把应用做的足够小，DevOps又要求一个人完成整个服务从前到后的完整流程，这个时候康威定律就能把两个串联起来，足够小的服务就希望我们有足够小的组织，而DevOps里面刚好是小组织，这样一个组织、这样一个服务、这样一个发布流程，希望你的代码写成Cloud Native的样子，就刚好满足了康威定律、微服务、DevOps和CICD持续交付。