Introduction
近几年互联中有一个非常热门的词叫云原生（Cloud Native），许多平台、应用、组件都说自己是云原生的，有些应用也说是云原生应用。那么这个到底是一个什么概念呢？在这篇博客我将和大家分享一下这方面的内容。
What is Cloud Native?
什么是云原生？云原生是一种构建和运行程序的方法论。它是一种充分利用云计算能力，在现代的、动态的环境中（包括公有云、私有云、混合云）去构建可扩展应用的一种方法论。好吧，上面这句定义不是人话，我们换个说法。云原生Cloud Native分开看，Cloud就是云，意思是在远端的，并不是在本地的，也不是具体某一个机器；Native就是原生，意思是天生的，两个合一起的意思就是某个东西天生就是为了云所设计的，为了充分利用云计算的特性，去设计这种东西。
比如说某款应用，它的架构设计的时候就是为了利用云计算而设计，比如它使用微服务的架构，通过容器进行部署等等，这些都是云计算的基本架构，那么我们就会说这个应用是一个云原生的应用。
云原生的目的就是在设计的时候，让整个架构能够利用好分布式云平台的特点，通常来说，这些分布式云平台是由大量的、松散的、独立的微服务构成，它们各自独立工作，每个服务都只负责某个或某几个数据模型，提供少量简单的接口。
一般来说，云原生的应用并没有对硬件或者操作系统的特殊要求，它们一般通过容器的方式进行部署，这使得这类应用非常容易扩展。
在2015年Cloud Native Computing Foundation（CNCF）成立，最初他们把云原生定义为：容器化封装+自动化管理+面向微服务，后来在2018年，又加入了服务网格和声明式API。借用别人一句比较直观的话去概括云原生架构：采用开源堆栈（k8s+Docker）进行容器化封装，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续交付和运维自动化，借助云平台设施实现弹性伸缩、动态调度和优化资源利用率。
Detail for Cloud Native
四要素
- 微服务（Microservice）：云原生应用都基于微服务架构，微服务是解耦的，相对独立的一系列小型的服务；而与之相对的是大型单体服务。使用微服务的好处是服务便于拓展、灵活性高。
- 容器化（Container）：Docker是主流的容器引擎，k8s是容器编排系统，两者配合使用能够使得运维人员便于管理大量的微服务，实现容器间的负载均衡。
- DevOps：开发+运维，开发和运维是一个紧密相关长期的工作，并不是说开发完了就到运维。真实情况下，开发完就需要测试，然后灰度发布，如果运维过程中发现了问题，可能需要二次开发等，所以这是一个复杂的迭代沟通过程。
- 持续交付（CI/CD）：持续交付最好的理解就是小步快跑，而不是一下一个大步。快跑的问题是开发版本和稳定版本的共存问题，这需要有足够的流程和工具支撑。
云原生应用 vs 传统应用
- 本地应用一般采用C/C++语言编写，而云原生应用则需要使用对网络比较友好的语言如Go、Nodejs等语言，这里有一个例外就是java，许多传统应用和云原生应用都使用java写（可能这个就是java强大之处）；
- 本地应用的采用的是传统瀑布式开发模型，更新的时候需要停机更新，而云原生应用需要支持频繁变更、持续交付、蓝绿部署；
- 本地应用的扩展性差，需要冗余资源来应对流量高峰，根据二八定律，每天的高峰流量只有20%的时间，而其余的时间都是低峰流量，所以会浪费大量的资源；而云原生应用可以弹性自动伸缩，通过共享降本增效；
- 本地应用对网络资源有书的配置要求，比如ip、port等；而云原生应用对网络和存储都没有这种限制；
- 本地应用的部署都是需要手工运维；云原生应用则是自动化部署；
上面5点是两种应用的一些明显的差一点，当然还有其他很多不一样的地方。
Summary
云原生这个方法论目前已成为业界主流的开发指导理论，这种模式能够大大提高服务的开发速度和稳定性，但是这并不说明这就是最优的方法。微服务架构下也存在这诸多问题，后续也通过引入service mesh等方式加以解决，至于未来会不会有更好的开发方式，谁也说不清。
