2019 年 6 月 24 日至 26 日, 由 Cloud Native Computing Foundation (CNCF) 主办的云原生技术大会 KubeCon + CloudNativeCon + Open Source Summit（上海）即将在中国上海盛装启幕。本届 KubeCon 将吸引来自全世界数千名技术人员参加此次盛会，参与CNCF全部项目和话题的深度探讨，以及案例分析，聆听 CNCF 项目的运维者和用户的分享。
在本次KubeCon上，京东云将在大会上为对云原生感兴趣的研发和运维人员带来《利用延迟加载快速启动 Docker 容器》的话题分享。
看完这些，是不是有点晕了？怎么那么多东西啊！
为了让大家更好地了解云原生，我们特别开设了“云原生系列内容”，今天将是该系列内容的最后一篇。不论你之前了不了解云原生或者CNCF，看完这篇内容，希望都能让大家对于云原生有着从0到1的全方位深入了解。
什么是云原生？
计算机领域每过几年都会产生一些新的概念出来，网格计算、云计算、物联网、微服务、区块链、边缘计算…… 每一个新概念都很难从名称直接看出来它的含义，所以一开始大家都会问到底什么是X计算，几年后再说起X计算大家却似乎都知道了，但是如果让他们解释一下，大多数人还是会解释不清楚。今天聊的主角“云原生”（Cloud Native）也是一样。
(关于云原生的定义众说纷纭，本文的介绍仅代表个人理解，欢迎指正。)
01
云原生是利用云
快速交付应用的一种方式
Pivotal公司是云原生概念的早期推广者，同时也是Spring框架和Spring Cloud的主要贡献者，它对云原生的定义是：
同时，他还补充道：
简单总结一下，也就会说云原生的目的是为了充分利用云的能力使应用交付更快。为了达到这个目的，将用到DevOps、持续交付、微服务和容器等理念和技术。
此外，提起云原生，业内人士还会提到另一个词：云原生基金会。那么云原生和云原生基金会（Cloud Native Computing Foundation，简称CNCF）又是什么关系呢？
云原生基金会致力于推广云原生计算模式，并维护一个厂商中立的开源生态系统来普惠大众。云原生计算使用开源软件栈来构建微服务，打包为容器，并且动态编排容器来最大化资源利用。CNCF孵化了软件容器领域的一个值得关注的Kubernetes项目以及围绕它的很多其他项目，而Kubernetes目前已经成为云原生应用的重要基石。
所以，云原生是一种理念和应用交付模式，云原生基金会是以推广这种理念和模式，孵化支撑这种模式的开源项目。注意，这里的“云”并不特指公有云，而是泛指可动态提供资源的各种平台。要应用云原生，会涉及到一些核心的技术：微服务、容器、交付。下面看一下为什么云原生会强依赖这些技术。
02
/ 微服务、容器、交付/
微服务简单来说就是将应用所需要的功能拆分成一个个小型独立的软件服务，即“微服务”。每个微服务专注于自己的任务，可被独立部署、更新、伸缩和重启，同时基于API彼此通讯来进行协同工作，以形成大型可伸缩应用程序。微服务最重要的点不是把服务拆的有多小，而是把除了应用本身关注的业务以外的其他逻辑都拆除出去。应用开发者不用去关心其他应用在哪里，不用去实现其他应用失效了怎么去重试怎么容错的逻辑，不用去为灰度和AB测试等需求开发代码，也不需要去实现逻辑来监控应用运行状态… …应用开发者就只专注于实现业务逻辑。同时，每个服务要实现的业务逻辑尽可能清晰，尽可能是高内聚的一组功能。
容器是应用的运行环境，是微服务的最佳载体。运行在容器而不是虚拟机，性能上的优势是一方面，更重要的是关注主体发生了变化。当运行一个虚拟机时，值得关注的主体是这台虚拟机，里边到底有多少种应用、具体是什么应用这并不是重点。而当运行一个容器时，关注点是放在容器中打包的那个应用，应用是整个动作的中心。但是也不能说用了虚拟机就一定不是云原生，利用虚拟机实现基于云的快速交付，也是云原生的另一种最佳实践。
交付是将容器中的服务真正用起来的过程。传统运维关注点在于一个一个的运维动作，而面向交付的运维重点在应用本身。关注的是应用最终需要提供多少个实例或者支持多少并发调用，这些运维的动作不应该是应用的关注点，应该全由底层平台解决。因此，有了声明式模型，应用只说需要几个实例，平台自己想着怎么启动，当有设备故障时怎么恢复；有了无服务器架构，应用根本不关注实例个数和启停逻辑，平台根据调用压力动态分配计算资源。
之所以很多人一提到云原生就想到Kubernetes，一方面因为Kubernetes是云原生基金会孵化的代表作，另外一方面也和它的能力有很大关系。作为市场领先的编排解决方案，Kubernetes正是实现了将应用以容器的方式快速交付，让应用不用再关注系统和网络差别，不用再关注部署和伸缩细节，并且具备丰富的生态（如Istio，Envoy，Prometheus，Jaeger等），提供应用的微服务治理能力，解决应用上云这个难题。
03
/ 构建云原生的应用 /
知道了什么是云原生，那要如何让应用更好地符合云原生的交付模式呢？
首先，你需要有一个云。这个云不一定是公有云，也可以是私有云，混合云，甚至是区块链服务，也可以是任何其他形式动态提供资源的平台。这个云需要具体如下基本能力：管理程序包/容器镜像/虚机镜像的能力；弹性将应用通过容器/虚拟机等方式交付的能力；对应用进行灵活的服务治理的能力；对应用的各种状态进行临时/永久存储的能力，以及对应用的安全性提供保障的能力。
其次，你要有用云的能力，不要在应用里去实现应该云平台提供的功能。有些团队用云服务只敢用云主机和存储，担心使用云的其他能力会被这个云服务绑定。有这个担心是对的，但是更好的方式应该是选择更开放、更兼容的云产品来使用。例如京东云的Kubernetes集群、微服务平台都是与开源项目完全兼容的，可以放心使用，不喜欢了也可随时切换到自己运维的开源项目上。
同时，你还需要改造你的应用，使之能更好的适用于在各种云平台上快速交付。关于云原生应用该如何设计，Heroku团队提出的十二要素（Twelve-Factor）提供了很多非常有价值的建议。十二要素包含：
按照十二要素的要求，编码、开发、构建、运维等操作都需要被清晰界定和规范，应用需要专注在业务逻辑，将部署环境、运行依赖，状态保存、并发、日志等问题都交给云平台来处理。云原生应用的开发过程变成：快速响应业务需求开发精简的应用构建标准包，然后在不同的环境以不同配置动态部署，运行的各种依赖利用云平台解决。按照这些原则去设计自己的应用，应用会更易于使用云服务提供的标准能力，会更易于实现快速交付，更易于进行灵活扩展。
在十二要素发布后，Pivotal公司的Kevin Hoffman编写的Beyond the Twelve-Factor App一书中，又增加了三个新要素作为补充：
最后，要构建云原生的应用，下面是在应用研发上线过程中的一些建议：
·代码里应该重点关注业务逻辑而不是其他
· 代码尽量不要有任何状态，状态都存到云服务里
· 代码里不要有和本应用无关的业务逻辑，它应该在其他应用里通过API调用
·不要实现用于运维和服务治理和观测的具体逻辑，要依赖第三方库和云服务
· 不要硬编码地址等任何配置，这段代码要运行在很多环境
· 不要假定这段代码会部署在什么地址，会部署几个实例
· 不要假定程序永远不死，要保证单个实例的死去不要影响其他实例
· 构建结果是一个整体，不能把构建的代码部署后再去改动代码包里的内容
关于云原生
我们在做什么？
云原生聚焦的是如何在IaaS基础构建之上创建有效的应用平台，而为企业级信息应用提供更好的技术环境也正是京东云的使命。
京东云，作为具有强产业属性的云智能厂商，在云原生技术的大量投入来自于自身业务的需求，从电商的前端网站、订单、结 算、支付、搜索、推荐，到后端的仓储、配送、客服、售后，以及采销人员使用的各种业务 系统都面临前所未有的挑战。京东几千个系统，几万个应用，每一个环节正常工作才能保证 整体业务顺利运行。云原生技术正是承载京东零售科技的技术基石。
经过多年的实践，京东构建了全球最大的Kubernetes集群，积累了大量的云原生开发和运维经验，并且加入云原生计算基金会成为最高等级的白金会员。
作为社区一员，京东云也会积极采用CNCF的项目、参与开发贡献并与其他成员一同合作共建社区。在即将开始的KubeCon+CloudNativeCon和Open Source Summit（China，2019）活动中，我们的技术专家在现场将为大家带来《利用延迟加载快速启动 Docker 容器》话题分享，通过京东云研发的容器镜像延迟加载技术，优化 Docker 镜像的加载过程，显著提高容器的启动速度。同时，还有《Kubernetes 中 MySQL 容器的正确大小和自动扩展》、《使用 Vitess 的两年:京东如何运行全球最大的 Vitess》、《在 Kubernetes 中经济高效地调度大量容器》的主题演讲。
京东云2016年开始对集团外部提供服务以来，逐渐将集团内部多年积累的云原生开发和运维能力标准化为Kubernetes集群、微服务平台、Devops、函数服务、云安全、API网关等上百种标准的云服务，方便客户利用京东云服务的强大能力，快速、安全、高可靠地交付产品。
欢迎点击“链接”了解更多精彩内容
