开启云原生之门

什么是云原生

CNCF组织

在讲云原生之前，我们先了解一下 CNCF ，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多企业与机构，包括亚马逊、微软。思科等巨头。目前 CNCF 所托管的应用已达14个，下图为其公布的Cloud Native Landscape，给出了云原生生态的参考体系：

云原生(Cloud Native)

CNCF 给出了云原生应用的三大特征：

容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
动态管理：通过集中式的编排调度系统来动态的管理和调度。
面向微服务：明确服务间的依赖，互相解耦。

云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成。这边引用网上关于云原生所需要的能力和特征总结：

应用部署运行模式的变迁

学习一个新事物之前呢，我们应该先了解该事物发展的历程和规律，Kubernetes 的出现就是应用部署运行模式在外部条件需求变更的情况下，演化出来的结果

物理机模式(物理机-操作系统-应用)

虚拟化模式(虚拟机-应用)

容器化模式

以 Docker为代表的内核容器技术不是新技术,而是将已有技术(LXC、 groups、 Union fs)进行了更好的整合和包装,并形成了
一种标准镜像格式
与VM相比,容器具有开发交付流程操作对象同步、执行更为高效资源占用更为集约等优势。
计算基本单元由虚拟机变为了容器,越来越多应用的构建、部署与运行选择在容器中进行。

云原生模式

随着容器技术的岀现以及应用所面临的外部环境的变化,云原生逐渐成为一种应用云化开发、部署和运行的主流方式
基础前提:应用的容器化和微服务化。容器,作为应用部署、运行和管理的基本单元
核心:借助容器管理自动化平台进行动态编排和资源优化利用

云原生应用的三大特征

容器化封装

最近几年Docker容器化技术很火，经常在各种场合能够听到关于 Docker 的分享。Docker 让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。Docker 背后的想法是创建软件程序可移植的轻量容器，让其可以在任何安装了 Docker 的机器上运行，而不用关心底层操作系统。

Docker 可以解决虚拟机能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包1括：

隔离应用依赖
创建应用镜像并进行复制
创建容易分发的即启即用的应用
允许实例简单、快速地扩展
测试应用并随后销毁它们

自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。在看似稳定而成熟的场景下，使用 Docker 的好处越来越多。

服务编排动态管理

Jimmy Song 对云原生架构中运用服务编排的总结是：

Kubernetes——让容器应用进入大规模工业生产

编排调度的开源组件还有：Kubernetes、Mesos 和 Docker Swarm;

他们为云原生应用提供的强有力的编排和调度能力，它们是云平台上的分布式操作系统。在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势

微服务架构

近几年微服务架构（Micro-Service，Archeticture）是最流行的架构风格，旨在通过将功能模块分解到各个独立的子系统中以实现解耦，它并没有一成不变的规定，而是需要根据业务来做设计。微服务架构是对SOA的传承，是SOA的具体实践方法。微服务架构中，每个微服务模块只是对简单、独立、明确的任务进行处理，通过REST API返回处理结果给外部。在微服务推广实践角度来看，微服务将整个系统进行拆分，拆分成更小的粒度，保持这些服务独立运行，应用容器化技术将微服务独立运行在容器中。过去设计架构时，是在内存中以参数或对象的方式实现粒度细化。微服务使用各个子服务控制模块的思想代替总线。不同的业务要求，服务控制模块至少包含服务的发布、注册、路由、代理功能。

容器化的出现，一定程度上带动了微服务架构。架构演化从单体式应用到分布式，再从分布式架构到云原生架构，微服务在其中有着不可或缺的角色。微服务带给我们很多开发和部署上的灵活性和技术多样性，但是也增加了服务调用的开销、分布式系事务、调试与服务治理方面的难题。