云原生技术概谈
说起“云原生技术”，大家可能有点懵，只闻其声，不明其意。然而云原生背地典型的几个公司或者技术产品的名称可能大家常常听到：
比方容器技术的代表公司docker；容器编排技术开源产品kubernetes（因为K和S之间有8个字母简称K8S）；服务网格Service Mesh；
无服务器架构Serverless；云原生基金会（CNCF）；以及这些技术背地的驰名公司Google，IBM，Redhat，VMWare，等。
本文尝试从以下几个方面来“扒一扒”云原生，帮忙大家从各个不同的维度来了解云原生这个形象的概念。
云原生的定义
Pivotal：云原生的提出者
2015年来自Pivotal公司的Matt Stine编写了一本名为《迁徙到云原生利用架构》的电子书，提出云原生利用架构应该具备的几个次要特色：
a、合乎12因素利用(Twelve-Factor Applications)
b、面向微服务架构(Microservices)
c、自服务麻利架构(Self-Service Agile Infrastructure)
d、基于API的合作(API-Based Collaboration)
e、抗脆弱性(Antifragility)
在2017年10月，也是Matt Stine，在承受InfoQ采访时，则对云原生的定义做了小幅调整，将Cloud Native Architectures定义为具备以下六个特质：
a、模块化(Modularity):（通过微服务）
b、可观测性(Observability)
c、可部署性(Deployability)
d、可测试性(Testability)
e、可解决性(Disposability)
f、可替换性(Replaceability)
CNCF：云原生计算基金会
谈到云原生，就不得不说CNCF，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多企业与机构，包含亚马逊、微软、思科
等巨头，我国也有泛滥企业参加其中，包含华为、阿里、腾讯等。
目前CNCF所托管的我的项目已达24个，包含大家耳熟能详的Kubernetes、etcd、gRPC、Prometheus等。下图为其颁布的Cloud Native Landscape，给
出了云原生生态的参考体系。更具体的信息请参见https://landscape.cncf.io/
CNCF对云原生的定义，也经验了几个阶段，起初CNCF对云原生的定义蕴含以下三个方面：
a、利用容器化(software stack to be Containerized)
b、面向微服务架构(Microservices oriented)
c、利用反对容器的编排调度(Dynamically Orchestrated)
到了2018年，随着近几年来云原生生态的一直壮大，所有支流云计算供应商都退出了该基金会，且从Cloud Native Landscape中能够看出云原生无意蚕
食原先非云原生利用的局部。CNCF基金会中的会员以及包容的我的项目越来越多，该定义曾经限度了云原生生态的倒退，CNCF为云原生进行了从新定位。
2018年6月，CNCF正式对外颁布了更新之后的云原生的定义（蕴含中文版本）v1.0版本：
a、云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微
服务、不可变基础设施和申明式API。
b、这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩，云原生技术使工程师可能轻松地对系统作出频繁和可预测
的重大变更。
c、 云原生计算基金会（CNCF）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为
公众所用。
下图从工夫上展现了CNCF对云原生定义的变动：
云原生技术的前世今生
Docker“横空出世”
1、2010年几个大胡子年轻人在旧金山成立了一家做 PaaS 平台的公司，起名为dotCloud，尽管dotCloud期间取得过一些融资，但随着大厂商（微软、谷歌、亚
马逊等）杀入PaaS平台，dotCloud举步维艰。
2、2013年的IT技术，AWS和openstack如日中天，过后是IAAS的天下，云里雾里的云计算最终都落地成了虚拟机以及私有云的资源账单！
3、2013年开源的paas我的项目Cloud Foundry却属于云计算中的一股清流，在经验了艰巨的paas概念遍及阶段后，吸引了少量国内外厂商参加paas开源平台的建
设。
4、而2013年之前“Docker”这个词还只是dotCloud这个公司外部的一个容器我的项目的名称，dotCloud这个公司的创业者们也是Paas热潮中的一份子，然而dotCloud
微不足道，小的可怜，他主打的产品和Cloud Foundry社区脱节，长期无人问津，眼看着就要被PAAS潮流有情的摈弃！
5、2013年dotCloud公司决定开源本人的容器我的项目“Docker”，显然这在过后没人Care，因为“容器”不是陈腐玩意，大家都晓得他是基于linux的内核技术（namespace
和cgroupe）实现，这和Cloud Foundry底层技术大部分都一样。然而恰好是那一小部分的不一样（docker的镜像打包技术）造就了Docker的雄起。
6、2013年，Docker我的项目开源后短短几个月内迅速崛起，红遍大江南北，以秋风扫落叶之势迅速干掉其余paas社区，他们甚至都没资格成为Docker的竞争对手就
曾经出局，Docker雄心勃勃大有对立容器江湖之势。
7、Docker崛起的时候CoreOS也是其中的一员，在容器生态圈中CoreOS的标签就是：专为容器设计的操作系统。作为互补，CoreOS+Docker已经也是容器部署
的明星套餐。CoreOS为Docker的推广和源码社区都做出了微小的奉献。
8、2014年随着Docker通过开发或者收买，逐步完善容器云平台的各个组件，筹备打造Docker本人的生态圈当前，CoreOS发现docker想摈弃本人，docker的一
系列布局与本人有间接竞争关系，因而CoreOS也愤恨的公布了另一个开源容器引擎Rocket简称rkt作为两家的离别宣言，至此两家各奔前程！
“江湖大佬”出山
Google公司秘而不宣的应用容器曾经有十几年了，本想要害时候做杀手锏，没想到docker竟然搞出了docker容器还开源了，且发展势头极其迅猛。Google坐不
住了，放心本人的江湖位置受到挑战。于是财大气粗的Google就鼎力搀扶docker的“反对派”营垒-CoreOS，kubernetes一经推出就原生反对rkt容器引擎，并且在
2015年4月Google还给CoreOS投资了1200万美刀，而CoreOS也公布了Tectonic，成为首个反对企业版本kubernetes的公司。从此容器生态江湖分为两大阵营
Google和Docker。
“容器编排”群雄逐鹿
2014年，当Google发现CoreOS在容器生态畛域切实不是Docker的竞争对手之后，决定换道超车，于当年发表推出kubernetes容器集群编排工具，并在2014
年6月7日将初始版本代码提交到Github上齐全开源，当年7 月 10 日微软、RedHat、IBM、Docker 退出Kubernetes 开源社区。
2014年的Docker公司雄心勃勃，于2014年底在DockerCon上公布了本人研发的“Docker原生”容器集群治理我的项目DockerSwarm，并想与kubernetes一较高下。
Mesosphere公司的Mesos + Marathon（马拉松）的我的项目更是晚期容器编排解决方案的领头羊，像是有3亿用户的Twitter以及苹果语音助手Siri就是应用mesos作为
后端集群管理工具。
但因为kubernetes基于Google外部应用的容器集群管理系统Borg+Omega，在谷歌曾经安稳运行了15年，Google将他们本人超大范畴的技术教训带到了容器
编排中，该填的坑早曾经被谷歌的技术大神们填了，因而推出后不到三年横扫docker swarm和mesos marathon容器编排工具。
CNCF的成立
2015年7月，由Google牵头并联结linux基金会以及一大票牛掰的技术公司（IBM、microsoft、redhat等等）成立了CNCF（Cloud Native Computing Foundation）
，紧接着就把kubernetes1.0版本的源代码募捐给CNCF。
这给大家传递的信息就是K8S是大家的，因而K8S一入世就让大家趋之若鹜，而借着CNCF，谷歌纠集了除了docker以外容器畛域的简直全副力量，此时docker
如果不退出CNCF就会被CNCF摈弃掉。
起初CNCF就提出，如果容器要疾速倒退就必须要标准化，不能受控于一家公司，由谁来制作容器的一系列标准化？为了给docker机会，就让docker去制订规范
化（OCI），毕竟在容器畛域Docker的技术还是当先的，因而docker的容器运行时（runtime）从一开始的LXC进化到libcontainer，再到最初的runC，完全符合OCI规范！
尘埃落定
2017年10月17日，随着docker发表反对kubernetes开始，容器编排的和平发表完结，整个行业曾经聚焦到K8S家门前！截止2017年6月，据CNCF统计：K8S
占据着77%的市场份额；docker swarm则只有21%，远远落后；而第三名Mesos则是13%。
云计算的演进历史
谈到Cloud Native，就不得不谈一谈Cloud，疾速回顾一下云计算的历史，来帮忙咱们对云有个更理性的意识。
虚拟化技术的成熟
云计算的呈现和虚拟化技术的倒退和成熟密切相关，2000 年前后 x86 的虚拟机技术成熟后，云计算逐步倒退起来。
基于虚拟机的云计算
基于虚拟机技术，陆续呈现了 IaaS/PaaS/FaaS 等状态，以及他们的开源版本。
容器的衰亡和编排大战
2013 年 docker 呈现，容器技术成熟，而后围绕容器编排一场大战，最初在 2017 年底，kubernetes 胜出。2015 年 CNCF 成立，并在近年造成了 cloud native 生态。
云的状态变动
这是云的状态变动，能够看到：供应商提供的性能越来越多，而客户或者说利用须要本人治理的性能越来越少。
云计算历史回顾小结
云原生的利用是什么样子
微服务架构中的痛点
在当下的微服务实际中，Spring Cloud，Dubbo作为支流的落地计划，在企业应用架构中施展越来越重要的作用。须要明确的是，
企业应用肯定是围绕业务进行的。无论采纳什么的架构落地，都是为了更好的为利用业务进行服务。从企业应用的个性思考，次要包含：
稳定性，安全性，扩展性，容错性。围绕着企业应用的这些特点，咱们来看一个典型的微服务企业架构模型，如图所示：
从这个典型的服务架构体系中，可能清晰的表明层级架构以及各层涵盖的职责。然而，恰好是这个看似清晰的微服务架构中，
暗藏着一个最大的痛点：业务性能与非业务性能耦合在一起。
当咱们的利用和非性能需要（基础设施）耦合在一起的时候，基础设施要进行降级的时候，就须要所有的利用一起来降级，这对于
利用来讲也是一个很大的苦楚。对于基础设施来讲，如果利用不降级的话，你就无奈实现基础设施能力的晋升。
微服务往云原生架构的演进
第一阶段：管制逻辑和业务逻辑耦合
为了实现业务逻辑，须要编写大量的管制逻辑，来解决服务发现，熔断等各种非性能逻辑，不仅效率低下，容易出错，而且节约人力。
第二阶段：类库或框架
应用类库或框架，将服务发现，熔断等各种非性能需要进行下沉，这打消了这部分性能的反复，提供了复用能力。但类库或框架个别
是语言绑定的，无奈提供平台无关的能力，并且无论是类库还是框架，和利用个别还是运行在一个过程内的，这也给性能降级带来了极大的麻烦。
第三阶段：代理
应用代理来进一步下沉非性能需要，这个方向是正确的，只是性能较为简陋，运维老本较高。
第四阶段：Sidecar
Sidecar pattern，即容器设计模式，利用同一Pod中容器能够共享各种namespace的能力，将利用容器与工具容器解耦，在POD启动
的时候主动的将Sidecar容器注入到POD中，应用程序无需感知。
举个简略的例子：实现利用日志收集
1、 业务容器将日志写在一个 Volume 外面。
2、 因为 Volume 在 Pod 外面是被共享的，所以日志容器，即 Sidecar 容器肯定能够通过共享该 Volume，间接把日志文件读出来，然
后存到近程存储外面。当初业界罕用的 Fluentd 日志过程或日志组件，基本上都是这样的工作形式。
Sidecar pattern及Mesh化
Sidecar pattern，实质上体现了一种关注点拆散的思维，当应用程序无需关怀网络（服务发现/编解码/负载平衡）、流量配置（服务路由
/熔断/限流）、平安、可观测（指标、日志、追踪）等非性能个性的时候，此时咱们认为整个零碎曾经实现了Mesh化。当Mesh化实现的时候，
才真正做到了基础设施和利用能够独立的演进，能够在悄无声息中实现基础设施的降级，就像一架正在航行中的客机一样，能够在航行的过
程中实现引擎的替换，而乘客却不必感知。
更进一步的是，与业务环境相干的一些根底的runtime（比方：CDB云数据库，CMQ音讯队列，等）再进一步进行下沉，成为云基础设施的
一部分的时候，这样就演进成一个更充沛的解耦的架构，咱们称之为无服务器架构Serverless。
图：利用基础设施全面解耦
图：Service Mesh
云原生为什么要和云计算联合
置信不少研发人员会认为，云原生不就是应用k8s作为底座，将一些公共能力一直下沉，让下层利用专一于本身业务，而不必关怀底层基础设施
的一种架构思维和一系列组件么，这些我在Local IDC也能玩得起来，为什么必须要上云呢，上云到底有什么劣势呢？
要解释这种疑难，那么就必须要理解，上云和自建IDC相比，到底有哪些劣势？
云上弹性裸金属服务器 + k8s为利用提供最佳计算基础设施
在云原生时代，传统的物理机+虚机模式曾经不适应高速增长的计算需要，因为传统虚构机会带来额定8% - 10%的性能损耗，这对于大规模散布
式零碎而言，无疑是一笔微小的资金节约；而POD带来的应用层隔离性，曾经和虚机十分靠近，因而在将来的大规模计算场景中，倒退的方向肯定是
裸金属+容器。
而大部分中小公司，都是没有自主弹性裸金属研发实力的，从这方面来说，上云的劣势比拟显著。上面是阿里神龙裸金属+容器服务的几大劣势，
可参考。
云上存储与计算拆散为利用开发带来微小收益
传统的服务器存储和计算部署在同一个物理服务器上，会存在一个资源节约的问题。比方，计算密集型服务对对磁盘的利用率低，导致存储资源
节约；存储密集型利用又会导致计算资源节约；计算与存储各自不能独立的扩大，导致运维效率低下，等。
云化存储正好解决了这几个痛点，利用只须要关怀CPU和内存，存储能够按需扩大；存储和计算不在同一个物理空间内，减速扩容变更效率，无
需本地数据迁徙。这些都是自建IDC很难做到的。
高速混合云网络的撑持
自建IDC往往只有很无限的1个或几个地区，无奈满足业务高速增长对流量在各区域自在调配的需要，比方当某地区热点暴发的时候，云上网络
能够疾速将网络流量引流到热点地区，而不会影响到整个零碎的稳固运行。
云原生时代对开发人员的要求
云原生时代，我认为对于开发人员，最重要的两个要求：拥抱云计算，拥抱kubernetes。
拥抱云计算
云计算是云原生的载体，是云原生可能取得高可用性，高弹性，低成本的首选平台。
拥抱kubernetes
Kubernetes 是云原生的关键所在，怎么强调都不为过。这里有一个被越来越多人认可的说法：Kubernetes是云原生时代的Linux。
对这句话，这里有两个重要的意识：
1、应该以 kubernetes 为底座进行能力建设：简略说就是如果是 kubernetes 已有的能力则间接应用，如果 k8s 的能力有余，则在 kubernetes
上做改良和加强，充分利用k8s的能力，而不是抉择忽视。
2、把kubernetes当kubernetes用：即要合乎 kubernetes 的理念和设计，遵循kubernetes的游戏规则。
谈到遵循kubernetes的游戏规则，外围在于遵循kubernetes的 CRD + Controller 模型：
- 如果k8s底座的能力不够：则应该去补充和增强k8s的能力，体现为实现新的Controller。
- 如果k8s的形象不够：比如说对于某些简单场景，现有CRD不实用或不够用，则应该定义新的形象，体现为增加新的CRD。
两者联合起来，加固k8s底座（Controller）+ 扩大k8s形象（CRD），就能够失去新的云原生基础设施。
总结
云原生是一系列技术或理念的汇合，包含但不限于容器、服务网格、微服务、不可变基础设施和申明式API，云原生是构建和运行可
弹性扩大、容错性好、易于治理的零碎的最佳实际。
a、容器和资源编排带来效率和资源利用率晋升：弹性裸金属服务器+容器编排。
b、 分布式系统的可弹性扩大与可靠性：存储与计算拆散+高速混合云网络的撑持。
c、凋谢规范带来的无供应商锁定：面向k8s编程，而不是面向AWS，GCP编程。
d、继续的交付带来的翻新迭代速度晋升：基础设施和利用独立演进，利用轻装前行，交付和翻新迭代速度失去大幅晋升。
说到底，技术是为了业务服务，任何技术的倒退，都是为了撑持业务疾速的试错，一直晋升业务零碎的交付效率，来满足市场的需要。
在这个VUCA时代，任何商业机会都会昙花一现，谁能最疾速的提供市场须要的产品或服务，谁就能在这个残暴的商业世界中存活下来。
这是最好的时代，也是最坏的时代，在这样不确定的时代，让咱们增强学习，拥抱云计算，拥抱云原生，用这样弱小的武器来武装自
己，一直开辟新的国土。
参考资料
https://landscape.cncf.io
https://github.com/cncf/toc/blob/master/DEFINITION.md
https://jimmysong.io/kubernetes-handbook/cloud-native/cloud-n...
https://www.kubernetes.org.cn/2250.html
https://www.infoq.cn/article/fA42rfjV*dYGAvRANFqE
https://www.infoq.cn/article/5HN5rqFE0K026pFXu8hX
https://juejin.im/post/5d42945ff265da03a715b2f0
https://www.infoq.cn/article/kJQXGx4Qs7m6qqBI1r9u
https://tanzu.vmware.com/cn/cloud-native
https://www.infoq.cn/article/xyxNdh6OiooK75vo4ZiE
本文由mdnice多平台公布