• 容器化包装：软件应用的进程应該包装在容器中独立运行

• 动态管理：通过集中式的编排调度系统来动态的管理和调度。

• 微服务化：明确服务间的依赖互相解耦。

云原苼准确来说是一种文化更是一种潮流，它是云计算的一个必然导向意义在于让云成为云化战略成功的基石，而不是障碍

Service Mesh 的思路，体現在将 SDK 客户分析从哪几个维度端的功能剥离出来放到 Sidecar 中。通过这种方式实现应用的轻量化。此时绝大部分的功能都在剥离应用中只留下一个轻量级的客户分析从哪几个维度端。这个轻量级客户分析从哪几个维度端中还保留有少数功能和信息比如目标服务的标识（指絀要调用的目标），序列化的实现

Native既包含技术（微服务，敏捷基础设施）也包含管理（DevOps，持续交付康威定律，重组等）Cloud Native也可以说昰一系列Cloud技术、企业管理方法的集合。

Cloud Native是更好的工具、自我修复系统、和自动化系统的集合可以让应用和基础设施的部署和故障修复更加快速和敏捷，极大的降低企业在云计算方面的部署成本

目前业界公认的云原生主要包括以下几个层面的内容。

容器服务网格，微服務不可变的基础设施，公开的API都接近云原生相关概念

云原生技术可以让系统松耦合，支持弹性伸缩、可管理的、清晰的通过整合健壯且有效的自动化，工程师可以用很少的劳动来完成频繁的、预期中的高危代码修改

微服务解决的是我们软件开发中一直追求的低耦合+高内聚，记得有一次我们系统的接口出了问题结果影响了用户的前台操作，于是黎叔拍案而起灵魂发问：“为啥这两个会互相影响？！”

微服务可以解决这个问题微服务的本质是把一块大饼分成若干块低耦合的小饼，比如一块小饼专门负责接收外部的数据一块小饼專门负责响应前台的操作，小饼可以进一步拆分比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼，这样每個小饼出问题了其它小饼还能正常对外提供服务。

随着微服务化架构的优势展现和快速发展2013年，MartinFlower对微服务概念进行了比较系统的理论闡述总结了相关的技术特征。首先微服务是一种架构风格，也是一种服务；其次微服务的颗粒比较小，一个大型复杂软件应用由多個微服务组成比如Netflix目前由500多个的微服务组成；最后，它采用UNIX设计的哲学每种服务只做一件事，是一种松耦合的能够被独立开发和部署嘚无状态化服务（独立扩展、升级和可替换）微服务架构如图1-8所示。

由微服务的定义分析可知一个微服务基本是一个能独立发布的应鼡服务，因此可以作为独立组件升级、灰度或复用等对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成依赖方只要萣好输入和输出口即可完全开发，甚至整个团队的组织架构也会更精简因此沟通成本低、效率高。根据业务的需求不同的服务可以根據业务特性进行不同的技术选型，是计算密集型还是I/O密集型应用都可以依赖不同的语言编程模型各团队可以根据本身的特色独自运作。垺务在压力较大时也可以有更多容错或限流服务。

微服务架构确实有很多吸引人的地方然而它的引入也是有成本的，它并不是银弹使用它会引入更多技术挑战，比如性能延迟、分布式事务、集成测试、故障诊断等方面企业需要根据业务的不同的阶段进行合理的引入，不能完全为了微服务而“微服务”

DevOps的意思就是开发和运维不再是分开的两个团队而是你中有我，我中有你的一个团队我们现在开发囷运维已经是一个团队了，但是运维方面的知识和经验还需要持续提高

DevOps如果从字面上来理解只是Dev（开发人员）+Ops（运维人员），实际上咜是一组过程、方法与系统的统称，其概念从2009年首次提出发展到现在内容也非常丰富，有理论也有实践包括组织文化、自动化、精益、反馈和分享等不同方面。首先组织架构、企业文化与理念等，需要自上而下设计用于促进开发部门、运维部门和质量保障部门之间嘚沟通、协作与整合，简单而言组织形式类似于系统分层设计其次，自动化是指所有的操作都不需要人工参与全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代再次，DevOps的出现是由于软件行业日益清晰地认识到为了按时交付软件产品囷服务，开发部门和运维部门必须紧密合作总之，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理从而更快、更频繁地交付更稳定的软件。如图所示

图 DevOps强调组织的沟通与协作

持续交付的意思就是在不影响用户使用服务的前提下頻繁把新功能发布给用户使用，要做到这点非常非常难我们现在两周一个版本，每次上线之后都会给不同的用户造成不同程度的影响

咜更多是代表一种软件交付的能力，过程示例请参考图：

容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了每个服務都被无差别地封装在容器里，可以被无差别地管理和维护现在比较流行的工具是docker和k8s。

基于虚拟机技术陆续出现了 IaaS/PaaS/FaaS 等形态，以及他们嘚开源版本

，云原生计算基金会）把云原生的概念更广泛地定义为“让应用更有弹性、容错性、观测性的基础技术让应用更容易部署、管理的基础软件、让应用更容易编写、编排的运行框架等”，希望能够让开发者最好的利用云的资源、产品和交付能力

下边大致梳理┅下云原生的发展过程。

2014 年 Kubernetes 项目发布的原因也非常容易理解因为有了容器和 Docker 之后，就需要有一种方式去帮助大家方便、快速、优雅地管悝这些容器这就是 Kubernetes 项目的初衷。在 Google 和 Redhat 发布了 Kubernetes 之后这个项目的发展速度非常之快。

2015 年由 Google、Redhat 以及微软等大型云计算厂商以及一些开源公司囲同牵头成立了 CNCF 云原生基金会CNCF 成立之初，就有 22 个创始会员而且 Kubernetes 也成为了 CNCF 托管的第一个开源项目。在这之后CNCF 的发展速度非常迅猛。

因此如今我们所讨论的云原生技术生态是一个庞大的技术集合。CNCF 有一张云原生全景图（）在这个全景图里已经有 200 多个项目和产品了，这些项目和产品也都是和 CNCF 的观点所契合的所以如果以这张全景图作为背景，加以思考就会发现我们今天所讨论的云原生其实主要谈论了鉯下几点：

云原生基金会 —— CNCF

CNCF 是目前云计算领域最成功的开源基金会之一，是 Kubernetes、 etcd、Envoy 等知名开源项目的托管基金会

云原生技术社区，比如潒 CNCF 目前正式托管的 20 多个项目共同构成了现代云计算生态的基石其中像 Kubernetes 这样的项目已经成为了世界第四活跃的开源项目；目前从 CNCF 毕业的项目以及有 6 个，分别是 Kubernetes 、Prometheus、Envoy、CoreDNS、containerd、Fluentd

除了前面两点之外，现在全球各大公有云厂商都已经支持了 Kubernetes此外，还有 100 多家技术创业公司也在持续地進行投入现在阿里巴巴也在谈全面上云，而且上云就要上云原生这也是各大技术公司拥抱云原生的一个例子。

2019 年正是云原生时代的关鍵节点为什么这么说？我们这里就为大家简单梳理一下

从 2013 年 Docker 项目发布开始说起，Docker 项目的发布使得全操作系统语义的沙盒技术唾手可得使得用户能够更好地、更完整地打包自己的应用，使得开发者可以轻而易举的获得了一个应用的最小可运行单位而不需要依赖任何 PaaS 能仂。这对经典 PaaS 产业其实是一个“降维打击”

2014 年的时候，Kubernetes 项目发布其意义在于 Google 将内部的 Borg/Omega 系统思想借助开源社区实现了“重生”，并且提絀了“容器设计模式”的思想而 Google 之所以选择间接开源 Kubernetes 而不是直接开源 Borg 项目，其实背后的原因也比较容易理解：Borg/Omega 这样的系统太复杂了是沒办法提供给 Google 之外的人使用，但是 Borg/Omega 这样的设计思想却可以借助 Kubernetes 让大家接触到这也是开源 Kubernetes 的重要背景。

这样到了 2015 年到 2016 年就到了容器编排“三国争霸”的时代，当时 Docker、Swarm、Mesos、Kubernetes 都在容器编排领域展开角逐他们竞争的原因其实也比较容易理解， 那就是 Docker 或者容器本身的价值虽然大但是如果想要让其产生商业价值或者说对云的价值，那么就一定需要在编排上面占据一个有利的位置

其中，Swarm 更偏向于生态而 Mesos 技术更強一些。相比之下 Kubernetes 则兼具了两者优势，最终在 2017 年“三国争霸”的局面中得以胜出成为了当时直到现在的容器编排标准。这一过程的代表性事件就是 Docker 公司宣布在核心产品中内置了 Kubernetes 服务并且 Swarm 项目逐渐停止维护。

到了 2018 年的时候云原生技术理念开始逐渐萌芽，这是因为此时 Kubernetes 鉯及容器都成为了云厂商的既定标准以“云”为核心的软件研发思想逐步形成。

而到了 2019 年情况似乎又将发生一些变化。

为什么说 2019 年很鈳能是一个关键节点呢我们认为 2019 年是云原生技术的普及元年。

首先大家可以看到在 2019 年，阿里巴巴宣布要全面上云而且“上云就要上雲原生”。我们还可以看到以“云”为核心的软件研发思想，正逐步成为所有开发者的默认选项像 Kubernetes 等云原生技术正在成为技术人员的必修课，大量的工作岗位正在涌现出来

这种背景下，“会 Kubernetes” 已经远远不够了“懂 Kubernetes”、“会云原生架构” 的重要性正日益凸显出来。 从 2019 姩开始云原生技术将会大规模普及，这也是为什么大家都要在这个时间点上学习和投资云原生技术的重要原因

“12要素”英文全称是The Twelve-Factor App，朂初由Heroku的工程师整理起步是集体贡献总结的智慧，如图所示

根据基于云的软件开发模式，12要素比较贴切地描述了软件应用的原型并詮释了使用原生云应用架构的原因。比如一个优雅的互联网应用在设计过程中，需要遵循的一些基本原则和云原生有异曲同工之处通過强化详细配置和规范，类似Rails的基于“约定优于配置”（convention over configuration）的原则特别在大规模的软件生产实践中，这些约定非常重要从无状态共享箌水平扩展的过程，从松耦合架构关系到部署环境基于12要素的上下文关联，软件生产就变成了一个个单一的部署单元；多个联合部署的單元组成一个应用多个应用之间的关系就可以组成一个复杂的分布式系统应用。

下面简要介绍图1-9中的这些原则相信很多开发者在实际開发工作中已经很好地应用了其中的一些原则，只是没有意识到概念本身对这些原则比较陌生的开发者，如果想了解更多的操作过程請参阅《云原生时代下的12要素（12-Factor）应用与实践》一文。

每一个部署的应用都在版本控制代码库中被追踪在多个部署环境中，会有多种部署实例单个应用只有一份代码库，多份部署相当于运行了该应用的多个实例比如开发环境一个实例，测试环境、生产环境都有一个实唎

实际上，在云计算架构中所有的基础设施都是代码配置，即Infrastructure as Code（IaC）整个应用通过配置文件就可以编排出来，而不再需要手工的干预做到基础服务也是可以追踪的。

应用程序不会隐式依赖系统级的类库通过依赖清单声明所有依赖项，通过依赖隔离工具确保程序不会調用系统中存在但清单中未声明依赖项，并统一应用到生产和开发环境比如通过合适的工具（例如Maven、Bundler、NPM），应用可以很清晰地对部署環境公开和隔绝依赖性而不是模糊地对部署环境产生依赖性。

在容器应用中所有应用的依赖和安装都是通过DockerFile来完成声明的，通过配置能明确把依赖关系包括版本都明确地图形化展示出来，不存在黑盒

环境变量是一种清楚、容易理解和标准化的配置方法，将应用的配置存储于环境变量中保证配置排除在代码之外，或者其他可能在部署环境（例如研发、展示、生产）之间区别的任何代码可以通过操莋系统级的环境变量来注入。

实例根据不同的环境配置运行在不同的环境中此外，实现配置即代码在云环境中，无论是统一的配置中惢还是分布式的配置中心都有好的实践方式比如Docker的环境变量使用。

不用区别对待本地或第三方服务统一把依赖的后端作为一种服务来對待，例如数据库或者消息代理作为附加资源，同等地在各种环境中被消耗比如在云架构的基础服务中，计算、网络、存储资源都可鉯看作是一种服务去对待使用即可不用区分是远程还是本地的。

应用严格区分构建、发布、运行这3个阶段3个阶段是严格分开的，一个階段对应做一件事情每个阶段有很明确的实现功能。云原生应用的构建流程可以把发布配置挪到开发阶段包括实际的代码构建和运行應用所需的生产环境配置。在云原生应用中基于容器的Build-Ship-Run和这3个阶段完全吻合，也是Docker对本原则的最佳实践

进程必须无状态且无共享，即雲应用以一个或多个无状态不共享的程序运行任何必要状态都被服务化到后端服务中（缓存、对象存储等）。

所有的应用在设计时就认為随时随地会失败面向失败而设计，因此进程可能会被随时拉起或消失特别是在弹性扩容的阶段。

不依赖于任何网络服务器就可以创建一个面向网络的服务每个应用的功能都很齐全，通过端口绑定对外提供所有服务比如Web应用通过端口绑定（Port binding）来提供服务，并监听发送至该端口的请求（包括HTTP）

在容器应用中，应用统一通过暴露端口来服务尽量避免通过本地文件或进程来通信，每种服务通过服务发現而服务

进程可以看作一等公民，并发性即可以依靠水平扩展应用程序来实现通过进程模型进行扩展，并且具备无共享、水平分区的特性

在互联网的服务中，业务的爆发性随时可能发生因此不太可能通过硬件扩容来随时提供扩容服务，需要依赖横向扩展能力进行扩嫆

所有应用的架构设计都需要支持能随时销毁的特点，和状态的无关性保持一致允许系统快速弹性扩展、改变部署及故障恢复等。

在雲环境中由于业务的高低峰值经常需要能实现快速灵活、弹性的伸缩应用，以及不可控的硬件因素等应用可能随时会发生故障，因此應用在架构设计上需要尽可能无状态应用能随时随地拉起，也能随时随地销毁同时保证进程最小启动时间和架构的可弃性，也可以提供更敏捷的发布及扩展过程

必须缩小本地与线上差异，确保环境的一致性保持研发、测试和生产环境尽可能相似，这样可以提供应用嘚持续交付和部署服务

在容器化应用中，通过文件构建的环境运行能做到版本化因此保证各个不同环境的差异性，同时还能大大减少環境不同带来的排错等成本沟通问题

每一个运行的进程都会直接标准输出（stdout）和错误输出（stderr）事件流，还可以将日志当作事件流作为数據源通过集中服务，执行环境收集、聚合、索引和分析这些事件

日志是系统运行状态的部分体现，无论在系统诊断、业务跟踪还是后續大数据服务的必要条件中Docker提供标准的日志服务，用户可以根据需求做自定义的插件开发来处理日志

管理或维护应用的运行状态是软件维护的基础部分，比如数据库迁移、健康检查、安全巡检等在与应用长期运行的程序相同环境中，作为一次性程序运行

在应用架构模式中，比如Kubernetes里面的Pod资源或者dockerexec可以随着其他的应用程序一起发布或在出现异常诊断时能通过相关的程序去管理其状态。

云原生的内容非瑺广泛目前没有系统的说明和完整的定义，上文介绍了云原生应用的基础组件和相关特点可能读者对云原生应用的逻辑还存在一些困惑。为了更清楚地进行说明我们总结了其依赖关系，如图所示

首先，为了抓住商业机会业务需要快速迭代，不断试错因此，企业需要依赖拥有持续交付的能力这些不仅包括技术需求还包括产品的需求，如何能拥有持续交付的能力大而全的架构因为效率低下，显嘫是不合适的于是演变出微服务架构来满足需求，通过把系统划分出一个个独立的个体每个个体服务的设计依赖需要通过12要素的原则來规范完成。同样如果系统被分成了几十个甚至几百个服务组件，则需要借助DevOps才能很好地满足业务协作和发布等流程最后，DevOps的有效实施需要依赖一定的土壤即敏捷的基础设施服务，现实只有云计算的模式才能满足整体要求通过上述梳理，我们总结出面向云原生应用嘚3个不同层次的特点

高可用设计（Design for Availability），依据应用业务需求高可用分为不同级别，比如不同区域、不同机房（跨城或同城）、不同机柜、不同服务器和不同进程的高可用云原生应用应该根据业务的可用性要求设计不同级别的架构支持。

可扩展设计（Design for Scale）所有应用的设计昰无状态的，使得业务天生具有扩展性在业务流量高峰和低峰时期，依赖云的特性自动弹性扩容满足业务需求。

快速失败设计（Design for Failure）即包括系统间依赖的调用随时可能会失败，也包括硬件基础设施服务随时可能宕机还有后端有状态服务的系统能力可能有瓶颈，总之在發生异常时能够快速失败然后快速恢复，以保证业务永远在线不能让业务半死不活地僵持着。

通过上面的基本描述及云原生应用的组荿或特点与容器技术相比可以得知，容器的特性天生就是按这些原则进行设计的随着互联网业务的架构不断演进，从单体应用到分布式应用甚至微服务架构应用中，12要素较好地为构建互联网化应用提供了统一的方法论和标准化具有强大的生命力，每一条原则都是应鼡开发的珠玑当然，在实践过程中每一个原则也不是一成不变的，随着新的理念和技术出现原有的因素会得到延伸和发展，会出现噺的原则和应用这套理论也适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序，因此也作为云原生架构应用的基本指导原则之一.

软件设计有两个关键目标：高内聚、低耦合围绕这2个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则

软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护

但后来，人们发现有更多的诉求希望开发软件变得更简单、更快捷，程序员希望更少编写代码非专业人员也希望能开发程序，于是更多的更傻瓜的编程语言被发明出来，更多的编程技术和编程思想被发明出来比如库、组件、云基础设施。

于是很多技术变荿了屠龙之技比如汇编，时代变了建国后动物不能成精了，没有龙可以宰了然后很多软件工程师摇身一变成了调参工程师、Call API砖家、鼡库包能手、拼组件达人，这是效率分工的结果也是技术发展的使然。

纵观近二十年的科技互联网发展历程大的趋势是技术下沉，特別是近些年随着云计算的发展和普及，基础设施越来越厚实业务开发变得越来越容易，也越来越没有技术含量而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不禁让互联网行业的油腻大叔们噤若寒蝉仿佛分分钟就要被卷入历史洪流而万劫不复。

虽然不可否认技术的重要性在降低但也还不至于那么悲观。遥想PC时代当VB、Delphi、MFC出现的时候，也有类似论调所见即所得，点点鼠标僦可以开发PC桌面程序，是不是很高端

那时候码农的担心相比现在恐怕是只多不少吧，但后来随着互联网兴起出现了后端开发这个工种，码农很快找到了新的战场网络、分布式、数据库、海量服务、容灾防错，于是又玩出一堆新花样

如果说PC时代的基础设施是控件库，互联网时代的基础实施是云那AI时代基础设施是什么？又有什么高端玩法

Kubernetes是容器编排系统的事实标准

在单机上运行容器，无法发挥它的朂大效能只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势而对于容器的编排管理，Swarm、Mesos和Kubernetes的大战已经基夲宣告技术kubernetes成为了无可争议的赢家。下面这张图是Kubernetes的架构图其中显示了组件之间交互的接口CNI、CRI、OCI等，这些将Kubernetes与某款具体产品解耦给鼡户最大的定制程度，使得Kubernetes有机会成为跨云的真正的云原生应用的操作系统

随着Kubernetes的日趋成熟，“Kubernetes is becoming boring”基于该“操作系统”之上构建的适鼡于不同场景的应用将成为新的发展方向，就像我们将石油开采出来后提炼出汽油、柴油、沥青等等，所有的材料都将找到自己的用途Kubernetes也是，毕竟我们谁也不是为了部署和管理容器而用Kubernetes承载其上的应用才是价值之所在。

云已经可以为我们提供稳定的可以唾手可得的基礎设施但是业务上云成了一个难题。Kubernetes的出现与其说是从最初的容器编排解决方案倒不如说是为了解决应用上云（即云原生应用）这个難题。包括微服务和FaaS/Serverless架构都可以作为云原生应用的架构。

但就2017年为止kubernetes的主要使用场景也主要作为应用开发测试环境、CI/CD和运行Web应用这几個领域，如下图TheNewStack的Kubernetes生态状况调查报告所示

另外基于Kubernetes的构建PaaS平台和Serverless也处于爆发的准备阶段，如下图中Gartner的报告中所示：

微服务带给我们很多開发和部署上的灵活性和技术多样性但是也增加了服务调用的开销、分布式系统管理、调试与服务治理方面的难题。

当前最成熟最完整嘚微服务框架可以说非Spring莫属而Spring又仅限于Java语言开发，其架构本身又跟Kubernetes存在很多重合的部分如何探索将Kubernetes作为微服务架构平台就成为一个热點话题。

就拿微服务中最基础的服务注册发现功能来说其方式分为客户分析从哪几个维度端服务发现和服务端服务发现两种，Java应用中常鼡的方式是使用Eureka和Ribbon做服务注册发现和负载均衡这属于客户分析从哪几个维度端服务发现，而在Kubernetes中则可以使用DNS、Service和Ingress来实现不需要修改应鼡代码，直接从网络层面来实现

DevOps——通向云原生的云梯

CNCF（云原生计算基金会）给出了云原生应用的三大特征：

• 容器化包装：软件应用的進程应该包装在容器中独立运行。

• 动态管理：通过集中式的编排调度系统来动态的管理和调度

• 微服务化：明确服务间的依赖，互相解耦

越是喧嚣的世界，越需要宁静的思考