CloudNative：云原生(分布式云)的简介(开展&演变/为什么需要/优势&价值/安全/对比传统企业应用)、四大核心...

CloudNative：云原生(分布式云)的简介(开展&演变/为什么需要/优势&价值/安全/对比传统企业应用)、四大核心技术、CNCF云原生交互景观、云原生技术的使用经历及方法之详细攻略

导读：从“软件正在吞噬世界”到“开源正在吞噬软件”，到如今“云原生吞噬开源”，开源项目正在有条不紊地向云化演进。近年来，IT软件技术架构进入云化时代—软件云化和微效劳化，容器虚拟化、DevOps等技术快速开展，将整个开发过程、开发流程带入云端，迎来了开发范式上的革命。PaaS、SaaS以及IaaS效劳都已进化到更加原生(Native)的状态，全面云化势不可挡。同时，微效劳、K8S、Service Mesh等一系列新技术规范涌现，开发工具也都在迭代晋级。将来，云原生将会成为新一代数字化的技术根底设备。云原生赋能企业也开端风生水起，一方面，云原生等新技术顺应市场与企业的需求而生，另一方面，越来越多的企业正在借助云原生应用架构助力业务的数字化转型。云原生计算提供统一的技术栈，动态、混合、分布式的云原生环境将成为新常态。
关键词：微效劳架构、容器、Docker、K8S、PaaS平台、DevOps、云原生

目录
云原生的简介—技术的革新，一定是思想先行
1、百家之言
(1)、通俗理解云原生——云亲生、换个开发环境
(2)、云原生—花钱买肃静，自己不搭机房就需要购置云效劳
(3)、云原生—也是一场内卷，但先卷者得利
(4)、当前云原生的推介文档有引导之嫌
(5)、从云原生看软件设计的技术趋势和影响
软件设计的目的→诉求带来傻瓜式编程→软件工程师不再底层→技术下沉→后端开发
2、云原生的开展、演变
(1)、云原生的开展—开源社区(Docker/K8S)加速了转向云原生应用的步伐
(2)、云原生的演变—应用上云趋势+云计算三层的技术土壤→催云原生应用→但上云的应用需修改自身去适应“云”特点
(3)、基于“云原生架构”应用程序的指导思想
3、为什么会呈现云原生—软件应用要上云
(1)、软件应用要上云
(2)、软件设计的技术趋势和影响
4、云原生的优势/价值—转型利器(快速迭代/高效运维)、无需考虑底层技术(快速部署/按需伸缩/不停机交付)、更关注业务价值(向下封装资源/向上支撑应用)、应用法宝(构建应用简便快捷/部署应用轻松自如/运行应用按需伸缩)
(1)、可轻松应对频繁和可预测的严重变卦——源自CNCF
(2)、降低风险、按需计算、更快交付(拓展业务)——源自Pivotal
(3)、为什么云原生应用如此重要—竞争优势、灵敏性、更加专注代码、自动化
5、云原生的安全
(1)、根底设备安全、镜像安全、运行时安全、生态安全
(2)、平台提供安全防护机制、制定安全配置、可视化判断安全性、异常行为检测、网络隔离与网络入侵检测、全生命周期安全防护
6、传统企业应用VS云原生应用
(1)、积累总结
(2)、源自Pivotal官网
云原生核心技术—DevOps+持续交付+微效劳+容器+云安全
1、云原生体系的四要素—微效劳+容器+DevOps+持续交付
(1)、微效劳
(1.1)、SOA对比微效劳
(1.2)、腾讯开源的微效劳框架TARS
(2)、容器
(3)、DevOps
(4)、持续交付
2、效劳网格Service Mesh
3、不可变的根底设备—传统可变的根底设备(需人工维护/不可预测/易出错)→效率/扩展/更新
4、声明式API
5、K8S
(1)、基于Docker镜像的分布式应用
(2)、分布式集群运行分布式应用的复杂性——分布式容器应用的可靠性、可扩展性
6、云原生、微效劳、容器、K8S、SOA、PaaS平台、DevOps 之间的关系——互相促进、互相依赖、互相关联
CNCF简介及其云原生交互景观
CNCF简介
CNCF Cloud Native Interactive Landscape
云原生技术的使用经历及方法
1、当前业务是否要立即切换到云原生架？
2、云原生时代的开发者具备的才干
云原生的简介—技术的革新，一定是思想先行

          云原生(CloudNative)是构建和运行应用程序的一套技术体系和方法论。它是基于分布部署和统一运管的分布式云 ，以容器化、微效劳、DevOps等三大技术为根底，而建立的一套云技术产品体系。云原生是一种新型技术体系，是云计算将来的开展方向。
           云原生，Cloud Native，假设拆开来解释的话，其中Cloud表示应用程序位于云中，即分布式云环境中，而不是传统的数据中心；Native表示应用程序在设计之初，就考虑到云的环境，即云平台的弹性和分布式特性，原生为云而设计。
           实际上，云原生并不是简单地使用云平台运行现有的应用程序，云原生的核心原理是，充沛利用和发挥云计算优势—云平台的弹性、分布式的优势，在云上以最佳姿势运行。是一种对应用程序停止设计、实现、部署、交付和操作的应用架构方法。
           云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。通过将最前沿的形式民主化，让这些创新为群众所用。CNCF官网论述了云原生的代表技术包括：容器、效劳网格、微效劳、不可变根底设备、声明式API。利用这些技术可以构建出容错性更好、更易于管理和观察的松耦合系统，再加上一些可靠的自动化技术及完备的监控预警体系，云原生技术将使开发人员能更快速、轻松地迭代和交付软件系统。
           云原生代表性的公司是Snowflake，是一家目前最火的云原生数仓公司。2020年9月16日，Snowflake胜利IPO，交易首日市值到达704亿美圆，最顶峰曾突破1200亿美圆。它是全球领先的云计算效劳商，主要提供云原生的数据仓库效劳，打造数据时代根底设备。
           根据中国信通院的相关调研数据，2019年云原生市场规模已高达350.2亿，且以年均增速超越30%的势头迅猛开展。根据IDC研究，2020年传统行业对云原生技术投入最多的五个行业分别是：金融、政府、制造、通信以及效劳。将来五年，复合增长率最快的五个行业分别是通信、制造、交通运输、政府和金融。
           2021年伊始，云原生的规划开端加速。华为云结合CNCF（云原生计算基金会）、中国信通院成立创原会，加速云原消费业落地；金山云发布云原生全景图、云原消费品矩阵和最新的Serverless产品；诺基亚宣布与谷歌云合作开发云原生5G技术；几乎所有云厂商新发布的云计算产品，都已打上了云原生的标签。
CNCF官网：https://www.cncf.io
CNCF官网定义云原生：FAQ | Cloud Native Computing Foundation
Pivotal官网定义云原生：What are Cloud Native Applications? | VMware Tanzu
1、百家之言

(1)、通俗理解云原生——云亲生、换个开发环境

云原生即云亲生；
云原生其实就是，对软件应用换了个开发环境，然后为了适应这个环境做了一些技术调整；
(2)、云原生—花钱买肃静，自己不搭机房就需要购置云效劳

          云原生的呈现，就是将云计算的方向从此前的资源型转为了效劳型，因而它们都在应用效劳层，而不再是根底资源了。所以，有人戏称，只要软件架构做的好，根底资源就变得不那么重要了。
           云端环境就是要使用云效劳器，对于大部分公司来说，就是使用阿里云、腾讯云等云计算厂商的公有云效劳来部署应用，而不是自己在额外维护一套复杂的效劳器机房。
           当然，他的优势也是显而易见，可以充沛利用云效劳的弹性及分布式优势，可以大大降低运维本钱，并且提升效劳的稳定性，但是，假设数据出本地，那么数据上云的安全性就值得商榷了。

(3)、云原生—也是一场内卷，但先卷者得利

          云原生是对老程序员的降维打击，整套环境和思维方式都改变了，卷起来；

(4)、当前云原生的推介文档有引导之嫌

          虽然，云原生的推介文档有引导之嫌，但它的优点确实也是有目共睹。但是，这样的好东西，是不是就要，立即把当前的应用改换到基于云原生的架构？详细方法，参考—云原生技术的使用经历及方法
(5)、从云原生看软件设计的技术趋势和影响

          软件设计有两个关键目的：高内聚、低耦合；围绕这2个核心目的，又提出了七大原则：开闭原则、依赖倒置、单一职责、接口隔离、最少知识、里氏交换、合成复用。
●  开闭原则：是总纲，要对扩展开放，对修改关闭；
●  依赖倒置原则：要面向接口编程；
●  单一职责原则：实现类要职责单一；
●  接口隔离原则：在设计接口时要精简单一；
●  最少知识原则/迪米特法原则：要降低耦合度；
●  里氏交换原则：不能破坏继承体系；
●  合成复用原则：优先使用组合或聚合关系复用，少用继承关系复用；
软件设计的目的→诉求带来傻瓜式编程→软件工程师不再底层→技术下沉→后端开发

扩展和维护——软件设计的目的	软件工程师不时都在为这两个目的而努力奋斗—高内聚、低耦合，以求把软件编写得更加明晰、更加强健、更加易于扩展和维护。
库/组件——诉求带来傻瓜式编程	但后来，人们发现有更多的诉求，希望开发软件变得更简单、更快捷，程序员希望更少编写代码，非专业人员也希望能开发程序，于是，更多的更傻瓜式的编程语言被发明出来，更多的编程技术和编程思想被发明出来，比如库、组件、云根底设备。
调参侠/用包能手/组装达人——软件工程师不再底层	于是很多技术变成了屠龙之技，比如汇编，时代变了，建国后动物不能成精了，没有龙可以宰了，然后很多软件工程师摇身一变成了调参工程师、Call API砖家、用库包能手、拼组件达人，这是效率分工的结果，也是技术开展的使然
技术下沉——降低业务开发技术含量	纵观近二十年的科技互联网开展历程，大的趋势是技术下沉。 特别是近些年，随着云计算的开展和普及，根底设备越来越厚实，业务开发变得越来越容易，也越来越没有技术含量。 而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不由让互联网行业的油腻大叔们噤若寒蝉，仿佛分分钟就要被卷入历史洪流而万劫不复。
降生新工种—后端开发	虽然不可否认技术的重要性在降低，但也还不至于那么悲观。 遐想PC时代，当VB、Delphi、MFC呈现的时候，也有类似论调，所见即所得，点点鼠标，就可以开发PC桌面程序，是不是很高端？那时候码农的担忧相比如今恐怕是只多不少吧。 但后来随着互联网兴起，呈现了后端开发这个工种，码农很快找到了新的战场，网络、分布式、数据库、海量效劳、容灾防错，于是又玩出一堆新把戏。
一个时代总有一个时代的活法	假设说PC时代的根底设备是控件库，互联网时代的根底施行是云，那AI时代根底设备是什么？又会有什么高端玩法？ 我们需要加深对根底知识的理解，以不变应万变，深耕一个领域，同时也需要多去尝试新技术，扩宽自己的眼界，增加处置问题的思路

参考文章：后端技术趋势指南|如何选择自己的技术方向_极客重生的博客-网站博客
2、云原生的开展、演变

(1)、云原生的开展—开源社区(Docker/K8S)加速了转向云原生应用的步伐

          转向云原生应用需要以新的云原生方法开展工作，云原生包括很多方面：根底架构效劳、虚拟化、容器化、容器编排、微效劳。在云原生的开展道路上，开源社区在云原生应用方面做出了大量行之有效的工作，很多开源的框架和设备可以通过拿来主义直接用。开源推动了云原生的开展，同时，云原生也为开源带来了最好的商业化开展。
2008年，Solomon Hykes(2018年已从Docker的管理人员退居为董事)，和Kamel Founadi、Sebastien Pahl共同创建了DotCloud的公司，目的是利用一种叫做容器的技术来创建他们称作是“大规模的创新工具”——一种任何人都可以使用的编程工具。
2013年3月，DotCloud 变成 Docker。DotCloud 发布了Docker的首个开源版本0.1.0(https://github.com/Docker)，并很快成为容器事实规范。
2013年9月，Red Hat成为Docker的主要合作伙伴，利用Docker来驱动他的OpenShift云业务；
2013年，Pivotal公司的Matt Stine首次提出云原生（CloudNative）的概念；
2014年6月，DockerCon大会上Docker正式发布了Docker 1.0 版本；
2014年6月，基于谷歌内部强大的Borg系统而开发出来的K8S横空处世，刷新了人们对容器的理解；
2014年12月，DockerConEU大会上，Docker Swarm(集群管理工具)和Docker Machine(部署Docker主机的命令工具)同时面世；
2014年12月，CoreOS宣布开发自家的容器运行环境Rocket以及应用容器规范Appc，早期阶段Google曾参与投资；
2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：符合12因素、微效劳、自敏捷架构、基于API协作、扛脆弱性；
2015年，云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微效劳；
2017年，Matt Stine在接受InfoQ采访时重新定义了云原生，将云原生架构归纳为六个特点：模块化、可观察、可部署、可测试、可交换、可处置；
2017年，是容器成为主流技术的一年。在容器编排的混战中，K8S脱颖而出。后来，Google的K8S一家独大，经过2017年后，容器市场根本趋于稳定，一切都向着优化改进方向开展；无形中，这些技术极大的降低了开发云原生应用的技术门槛。
2018年11月，CNCF重新定义云原生，把效劳网格(Service Mesh)和声明式API给加了进来。云原生的代表技术包括容器、效劳网格、微效劳、不可变根底设备和声明式API。
截止2022年，Pivotal官网对云原生概括为四要素：DevOps+持续交付+微效劳+容器。

(2)、云原生的演变—应用上云趋势+云计算三层的技术土壤→催云原生应用→但上云的应用需修改自身去适应“云”特点

          随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微效劳等开发理念的带动下，应用上云已经是不可逆转的趋势。
           云原生属于云计算的PaaS层效劳，主要是面向开发者的一类应用。云原生必需在云上装置，是一种基于云计算的软件开发应用方式。
           云原生借了云计算的东风，没有云计算，自然没有云原生，云计算是云原生的根底。云计算的三层划分(IaaS、PaaS、SaaS)为云原生提供了技术根底和方向指引。
           真正的云化不只仅是根底设备和平台的变化，应用也需要做出改变，抛弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建立全新的云化的应用，即云原生应用。
(3)、基于“云原生架构”应用程序的指导思想

          符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）停止容器化，基于微效劳架构进步灵敏性和可维护性，借助敏捷方法、DevOps支持持续迭代和自动化运维，利用云平台设备实现弹性伸缩、动态调度、优化资源利用率。
3、为什么会呈现云原生—软件应用要上云

虚拟化技术的成熟和分布式框架的普及，使应用上云不再是企业转型难题。
(1)、软件应用要上云

          云原生，是软件应用在上云过程，为了适应云、用好云的一种技术架构；
(2)、软件设计的技术趋势和影响

参考—1、(5)、从云原生看软件设计的技术趋势和影响
4、云原生的优势/价值—转型利器(快速迭代/高效运维)、无需考虑底层技术(快速部署/按需伸缩/不停机交付)、更关注业务价值(向下封装资源/向上支撑应用)、应用法宝(构建应用简便快捷/部署应用轻松自如/运行应用按需伸缩)

          云原生技术带来应用快速迭代和高效运维才干，成为金融行业向"互联网+"转型的利器。云原生强调自动化以提升开发效率和运维效率。
           云原生应用，也就是面向“云”而设计的应用，在使用云原生技术后，开发者无需考虑底层的技术实现，可以充沛发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等。
           云原生计算加速了应用与根底设备资源之间的解耦，通过定义开放规范，向下封装资源—将复杂性下沉到根底设备层，向上支撑应用—让开发者更关注业务价值。
K8S的结合开创人Joe Beda曾说：“Cloud native is structuring teams, culture, and technology to utilize automation and architectures to manage complexity and unlock velocity.”“云原生正在构建团队、文化和技术，以利用自动化和体系构造来管理复杂性和释放速度。”
           云原生构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩。云原生毕竟是集各家之长，几乎没有什么缺点，秒杀传统Web框架，吊打祖传IT形式，是当代评优晋级不可多得的终极绝密武器。
(1)、可轻松应对频繁和可预测的严重变卦——源自CNCF

          CNCF认为，云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、效劳网格、微效劳、不可变根底设备和声明式API。这些技术可以构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手腕，云原生技术使工程师可以轻松地对系统作出频繁和可预测的严重变卦。
(2)、降低风险、按需计算、更快交付(拓展业务)——源自Pivotal

          云原生是一种方法，用于构建和运行充沛利用云计算模型优势的应用。
           云原生应用：更快交付，降低风险，拓展业务。
           云计算不再将重点放在资本投资和员工上来运行企业数据中心，而是提供无限制的按需计算才干和根据使用情况付费的功能，从而重新定义了几乎所有行业的竞争格局。
           IT 本钱减少意味着入行的壁垒更低，这一竞争优势使得各团队可以快速将新想法推向市场，这就是软件正在占据世界，并且初创公司正在使用云原生方法来颠覆传统行业的原因。  
(3)、为什么云原生应用如此重要—竞争优势、灵敏性、更加专注代码、自动化

          云原生应用专为云模型而开发。小的专用功能团队快速将这些应用构建和部署到可提供轻松的横向扩展和硬件解耦的平台，为企业提供更高的敏捷性、弹性和云间的可移植性。
           企业需要一个用于构建和运行云原生应用和效劳的平台，来自动执行并集成DevOps、持续交付、微效劳和容器等概念。

竞争优势	云是一种竞争优势，云原生意味着将云目的从节约 IT 本钱转变为推动企业开展。在软件时代，假设企业可以根据客户需求快速构建和交付应用，那么该企业将在其行业中占据主导地位。一旦交付，应用必需像永远在线的弹性扩展效劳一样运行。
灵敏性	企业可以构建无需修改便可在任何云上运行的应用。团队可以保留跨多个云供给商和一个私有云迁移或分发应用的才干，以匹配自己的业务优先级并优化云定价。
更加专注代码	让开发人员以最好的状态工作 采用云原生应用的团队可为开发人员省去为了在各种云根底架构间运行和扩展而编写代码所产生的开销，让他们专注于编写可以交付客户价值的代码。规范化开发人员体系上的12因素应用需要一套规范的效劳，从而提供规范的开发人员“合同”，确保其应用充沛利用底层的云原生平台。
自动化	通过实现自动化 IT 运营，企业可以转变为一个重点明确的精益团队，与推动业务优先事项坚持一致。由于员工专注于流程改进，而不是日常的普通管理任务，他们可以消除由于人为错误导致的故障风险。通过在体系的所有层面停止自动化的实时修补和晋级，他们可以消除停机时间，并且不再需要具有“传承”专业知识的运营专家。

5、云原生的安全

(1)、根底设备安全、镜像安全、运行时安全、生态安全

云原生安全的核心问题有四个：根底设备安全、镜像安全、运行时安全和生态安全。

根底设备安全	(1)、主机上的安全配置是否会影响容器？ (2)、主机上的安全破绽，恶意进程是否会影响容器？ (3)、容器内的进程是否可以利用主机上的安全破绽？ (4)、容器和主机的权限是否相通？
镜像安全	(1)、镜像中的软件是否存在安全破绽？ (2)、镜像在构建的过程中是否会带来安全问题? (3)、镜像运行后是否会产生安全问题？ (4)、镜像传输过程中能否被窜改?
运行时安全	(1)、容器间的隔离是否充沛? (2)、容器间的通信是否是安全的？ (3)、容器内的恶盒程序是香会影响宿主机?是否会影响其它容器？ (4)、容器的资源使用是否安全? (5)、容器的安全策觞怎样来制定?
生态安全	(1)、Docker、K8S自身的安全性如何? (2)、Service Mesh/Service less对容器安全有什么影响? (3)、容器中安全密明的管理和传统环境有什么不同? (4)、容器化后的致据隐私维护跟传统的数据隐私维护是否一致?

(2)、平台提供安全防护机制、制定安全配置、可视化判断安全性、异常行为检测、网络隔离与网络入侵检测、全生命周期安全防护

(1)、平台提供安全防护机制：K8S就提供了包括TLS、SecretsManagemenAdmission Control在内的多个安全机制。
(2)、制定安全配置：Docker公司与美国互联网安全中心(CIS）合作，制定了Docker的最佳安全理论，包括主机安全配置、Docker守护进程配置、Docker守护程序配置文件、容器镜像和构建、容器运行安全、Docker安全操作六大项，99个控制点。
(3)、可视化判断安全性：云原生系统的行为可视化判断安全性，晓得系统里如今都在做什么，包括监控进程行为、监控网络行为等等。只要晓得了在发生什么，才可以判断哪些行为是安全，哪些是不安全的。
(4)、异常行为检测：云原生系统的异常行为检测则可以晓得发现系统里如今有什么异常的行为，根据容器环境的攻击模型，确定异常检测规则，基于内核行为数据确定异常。
(5)、网络隔离与网络入侵检测：云原生网络安全则要实现微效劳间的网络隔离与网络入侵检测。API安全在微效劳架构中尤为重要，包括身份管理、访问控制、通信安全、消息限制等等。
(6)、全生命周期安全防护：容器安全做全生命周期安全防护，要停止安全建立规划包括根底设备安全、软件供给链安全、运行时安全等等。
参考文章
绿盟科技江国龙：金融领域云原生技术与安全研究_POS机办理中心
6、传统企业应用VS云原生应用

          传统的应用开发方式都是闷头开发，不论应用跑在哪个根底设备环境中，也不用考虑根底设备提供的各种才干，我虽然让我的应用能正常运行就好。
           云原生，就是应用在开发的时候就考虑到云上提供的各种效劳，充沛利用云的动态调度、自恢复、通过 API 访问效劳等根本特性，以及敏捷高效的特性。
(1)、积累总结

	本地部署的传统企业应用	云原生应用
采用的编程语言	往往采用c/c++、企业级java编写	采用以网络为中心的go、node.js等新兴语言编写
效劳方式	有些是单体(巨石)应用，或者强依赖	纵向划分效劳，模块化更合理
应用更新方式	可能需要停机更新	始终是最新的，需要支持频繁变卦，持续交付，蓝绿部署。
扩展方式	手动扩展，无法动态扩展，往往需要冗余资源以抵抗流量顶峰	自动动态扩展，利用云的弹性自动伸缩，通过共享降本增效。
运维方式	通常人工部署手工运维	一切自动化运维
网络资源依赖性	对网络资源，比如ip、端口等有依赖，甚至是硬编码	对网络和存储都没有这种限制
系统环境依赖性	通常依赖系统环境	不会硬连接到任何系统环境，而是依赖笼统的根底架构，从而获得良好移植性。

参考文章
什么是云原生？这回终于有人讲明白了 - 网站
(2)、源自Pivotal官网

	传统的企业应用	云原生应用
项目可预测性	不可预测：传统应用的架构或开发方式使其无法实如今云原生平台上运行的所有优势。此类应用通常构建时间更长，大批量发布，只能逐步扩展，并且会发生更多的单点故障。	可预测：云原生应用符合旨在通过可预测行为最大限度进步弹性的框架或“合同”。云平台中使用的高度自动化的容器驱动的根底架构推动着软件编写方式的开展。第一次作为 12 因素应用记录的 12 个原则就是阐释此类“合同”的良好示例。
操作系统依赖性	依赖操作系统：传统的应用架构允许开发人员在应用和底层操作系统、硬件、存储和支持效劳之间建立严密的依赖关系。这些依赖关系使应用在新根底架构间的迁移和扩展变得复杂且充溢风险，与云模型相背而驰。	操作系统笼统化：云原生应用架构要求开发人员使用平台作为一种方法，从底层根底架构依赖关系中笼统出来，从而实现应用的简单迁移和扩展。实现云原生应用架构最有效的笼统方法是提供一个形式化的平台。Tanzu 非常适用于在谷歌云端平台 、微软 Azure 或亚马逊云效劳等基于云的根底架构上运行。
容量分配机制	过多容量：传统 IT 会为应用设计专用的自定义根底架构处置方案，这延迟了应用的部署。由于基于最坏情况估算容量，处置方案通常容量过大，同时几乎没有才干继续扩展以满足需求。	适宜的容量：云原生应用平台可自动停止根底架构调配和配置，根据应用的日常需求在部署时动态分配和重新分配资源。基于云原生运行时的构建方式可优化应用生命周期管理，包括扩展以满足需求、资源利用率、可用资源编排，以及从故障中恢复，最大水平减少停机时间。
协作方式	孤立：传统 IT 将完成的应用代码从开发人员“隔墙”交接到运营，然后由运营人员在消费中运行此代码。企业的内部问题之严重以致于无暇顾及客户，导致内部抵触产生，交付缓慢折中，员工士气低落。	协作：云原生可协助DevOps，从而在开发和运营职能部门之间建立亲密协作，将完成的应用代码快速顺畅地转入消费。
开发方式	瀑布式开发：IT 团队定期发布软件，通常间隔几周或几个月，事实上，当代码构建至发布版本时，该版本的许多组件已提早准备就绪，并且除了人工发布工具之外没有依赖关系。假设客户需要的功能被延迟发布，那企业将会错失赢得客户和增加收入的时机。	持续交付：IT 团队可以在单个软件更新准备就绪后立即将其发布进来。快速发布软件的企业可获得更严密的反响循环，并能更有效地响应客户需求。持续交付最适用于其他相关方法，包括测试驱动型开发和持续集成。
效劳独立性	依赖性：一体化架构将许多分散的效劳捆绑在一个部署包中，使效劳之间呈现不用要的依赖关系，导致开发和部署过程丧失敏捷性。	独立性：微效劳架构将应用分解成小型松懈耦合的独立运行的效劳。这些效劳映射到更小的独立开发团队，可以频繁停止独立的更新、扩展和故障转移/重新启动操作，而不影响其他效劳。
扩展性	手动扩展：手动根底架构包括人工运营人员，他们负责手动构建和管理效劳器、网络及存储配置。由于复杂水平较高，运营人员无法快速地大规模正确诊断问题，并且很容易执行错误施行。手动构建的自动化方法可能会将人为错误的硬编码到根底架构中。	自动化可扩展性：大规模根底架构自动化可消除因人为错误形成的停机。计算机自动化无需面对此类挑战，可以在任何规模的部署中始终如一地应用同一组规则。云原生还超越了基于以虚拟化为导向的传统编排而构建的专用自动化。全面的云原生架构包括适用于团队的自动化和编排，而不要求他们将自动化作为自定义方法来编写。换句话说，自动化可轻松构建和运行易于管理的应用。
恢复速度	恢复缓慢：基于虚拟机的根底架构对于基于微效劳的应用来说是一个缓慢而低效的根底，因为单个虚拟机启动或关闭的速度很慢，甚至在向其部署应用代码之前就存在很大的开销。	快速恢复：容器运行时和编排程序可在虚拟机上提供动态的高密度虚拟化覆盖，与托管微效劳非常匹配。编排可动态管理容器在虚拟机群集间的放置，以便在发生故障时提供弹性扩展和恢复/重新启动功能。

云原生核心技术—DevOps+持续交付+微效劳+容器+云安全

          云原生几乎就是一个技术大杂烩，它几乎囊括目前大部分流行的后端技术，近些年，还逐步延伸到了AI、机器学习、边缘计算等领域。
           通过这些技术，为软件应用在架构、支撑效劳和支持组件、基准平台上停止了规范化；同时也处置了晋级、扩容、稳定性、私有云/公有云/混合云统一根底架构等问题。

1、云原生体系的四要素—微效劳+容器+DevOps+持续交付

(1)、微效劳

          Sam Newman在Building Mircroservices书中定义微效劳：Microservices are small, autonomous services that work together.
           Netflix云架构负责人Adrian Cockcroft的定义微效劳：Loosely coupled service-oriented architecture with bounded contexts.
           可知，微效劳是可以独立部署的、小的、自治的业务组件，业务组件彼此之间通过消息停止交互。微效劳的组件可以按需独立伸缩，具备容错和故障恢复才干。

简介	Microservice，面向微效劳，明确效劳间的依赖，互相解耦。 微效劳架构是随着云计算的开展而产生的一种软件架构风格，采用多个松耦合的效劳(微效劳)构建一个应用系统。 微效劳是将应用作为小型效劳集合停止开发的架构方法； 微效劳，这是应用开发的一种理念，将单体应用拆分为微效劳才干更好的实现云原生，才干独立的部署、扩展和更新。 (1)、与跟微效劳相对的是单体应用，微效劳有理论根底—Conway’s law康威定律(指导效劳怎么切分)；
核心功能组件	微效劳架构中的核心功能组件，包括网关、微效劳治理、效劳注册、配置管理、限流和熔断、负载平衡、自动扩容、自动故障隔离、自动业务恢复、监控和日志组件等。
特点	微效劳架构是一个“重平台、轻应用”的架构，从应用软件整体来看，相比较传统架构，平台的研发投入比重占的很大。利用成熟稳定的商业化PaaS平台是本钱最优的方案。 (1)、可独立性存在：每个效劳都可以被独立的部署、更新、scale和重启；每个微效劳都可以独立于应用中的其他效劳停止部署、晋级、扩展和重新启动； (2)、基于HTTP API 停止通信：不同微效劳之间通过轻量级的交互机制实现通信，应用间通过RESTful API通信；每个效劳都可施行业务功能，在自己的流程中运行并通过 REST架构设计形式的HTTP API 停止通信； (3)、不停机频繁更新：通常作为自动化系统的一部分运行，可以在不影响最终客户的情况下频繁更新正在使用中的应用； (4)、每个微效劳可采用任何语言实现；
微效劳与Spring Cloud	Java体系的Spring Cloud提供了诸如网关Zuul组件、Ribbon负载平衡组件、Eureka效劳注册组件、LCM扩容组件、Hystrix业务恢复组件。利用Spring Cloud的才干可以实现一套完善的微效劳架构。 Spring Cloud有大量的java开发人员所拥护，这是它的优势。但是Spring Cloud的优势很突出，那就是限制编程语言和编程技术。
优缺点	(1)、内聚更强、变卦更易：微效劳架构的优势，依照function切分之后，效劳解耦、内聚更强、变卦更易； (2)、采用微效劳架构体系的应用在开发效率、稳定性、可扩展性上具备了无可比较的优势，使其成为云化应用的规范架构。 ● 支持快速上线—意味着速度和效率：由于业务组件的自治性和独立性，新的功能和应用可以迅速的发布上线，而不用担忧对系统其他功能带来大范围的影响和涉及。可以通过效劳组件重用重组，快速的形成和发布新的应用。 ● 支持独立扩容和恢复—意味着系统的安全、稳定、可扩展：针对性的对应用中的某些效劳停止扩容，处置性能的瓶颈。可以独立交换或恢复微效劳中的某个组件。
	(1)、微效劳的分布式带来的复杂性：开发人员需要基于RPC或者消息实现微效劳之间的调用和通信，而这就使得效劳之间的发现、效劳调用链的跟踪和质量问题变得的相当棘手。
开展趋势	在已经过去的 2020，微效劳可以说有坚守也有破局，有对效劳微化共识的形成，也有对特殊场景的理性考虑。我们可以看到效劳框架仍然在持续演进，奔向云原生，拥抱云化。越来越多的企业开端跟上效劳化云化步伐。
关联	微效劳与PaaS：微效劳架构对应用运行平台的依赖性很强，一个好的、功能全面、易用、稳定的PaaS平台才干发挥出微效劳架构的优势。反之，假设没有一个好的PaaS平台，应用开发团队的大部分精神消耗在平台的搭建、利用，以及微效劳架构的设计和应用维护上。那样的话，不只没有得到利用微效劳架构的好处，反而沉陷于利用微效劳架构所带来的技术挑战和优势当中。 所以可以讲，K8S和PaaS平台是微效劳技术的运行平台。微效劳架构实质上与容器及K8S技术无关。

(1.1)、SOA对比微效劳

          在新型数字化转型需求的大潮下，整个行业也正从传统的单体应用/集中式的SOA架构，走向更为松懈化、分布式、规范化的微效劳架构。微效劳架构，从万能中间件ESB(EntERPrise Service Bus,企业效劳总线)的中心化架构，转变成了将控制逻辑以SDK的方式置于效劳的去中心化架构，后又演变成控制逻辑与业务逻辑解耦，以Service Mesh为架构的云原生效劳化架构。这种演变就是为理处置一个问题：分布式微效劳架构极度复杂，对运维才干提出高度挑战。
           因而，需要一整套技术门槛很高的控制系统、调度系统以及全面的观测性系统。这些系统不应该再耦合或是侵人到业务逻辑中。
           SOA（Service-Oriented-Architecture）面向效劳的架构，是把效劳拼装形成应用整体的架构。SOA中的效劳是指“可重用的业务模块”。

微效劳架构与SOA很像，同样都是将整个应用拆分，形成独立的业务模块的思路。但在许多关键点上，微效劳架构与SOA不同。

	SOA	微效劳
设计思路	SOA的设计思路是把一些组件和效劳，通过效劳总线组装，形成更大的应用系统（从小到大）；	而微效劳的设计思路是把应用拆分成独立自治的小的效劳（从大到小）。
架构特点	SOA设计架构强调分层，通常会分为展示层、业务层、总线层和数据层。	微效劳架构中的效劳更松懈。
领域自治性	SOA中的效劳不强调业务领域的自治性。	微效劳架构强调基于领域的效劳自治性。
WebService应用通信	SOA很大水平上依赖于基于XML的消息格式和基于SOAP的通信协议；	微效劳架构大量的依赖于REST和JSON；
ESB对比API网关	SOA架构中有ESB（效劳总线）的概念 ESB负责效劳之间的通信转发和接口适配，在SOA实现中，ESB处于核心地位，有很多专业的ESB厂商提供ESB中间件，例如WebSphere ESB、Oracle ESB、Dubbo等。 ESB自身是非常“重”的技术，在云化软件体系和微效劳架构中，强调更轻量级、更迅速、去中心化的技术，所以在微效劳架构中，不需要ESB。	在微效劳架构中，不需要ESB，而通过API网关这样的技术来负责效劳接口转发。（由于软件全面云化是一个过程、需要适配、调整来全面完成转变，所以在一段时间内，面对大量的遗留系统，ESB仍然会充任微效劳改造过程中用来适配老系统的一个重要组件。）
过去在容器、K8S技术没有呈现的年代，培养了SOA的实现方式。二者的区别根本上都在实现方式上。微效劳与SOA实质上是同一种设计思想在不同时代的不同实现。

(1.2)、腾讯开源的微效劳框架TARS

(2)、容器

简介	容器作为应用包装的载体，容器化是指根底设备容器化。 容器和主机共享硬件资源及操作系统，通过对CPU、内存等资源的隔离、划分和控制，实现进程之间透明的资源使用。
功能/价值	容器化封装，以容器为根底，进步整体开发水平，形成代码和组件重用，并作为应用程序部署的独立单元。 (1)、容器是微效劳的最佳载体：容器化为微效劳提供施行保证，起到应用隔离作用；对于采用云计算技术的金融机构来说，Docker是目前主要选择的容器引擎/容器运行技术，已将容器技术用于消费环境或测试环境。 (2)、容器编排技术：即容器编排系统，主要用于容器管理，容器间的负载平衡。K8S和Mesos/DCOS是主流的容器编排技术，但是Google的K8S是更流行。 (3)、Docker和K8S都采用Go编写，都是好东西。
特点	容器化取代了本地化，更轻量级、可移植性好、占用内存更少、通过RPC停止交互、水平扩容、高可用。
优缺点	(1)、效率更高：与规范虚拟机相比，容器能同时提供效率和速度。 (2)、动态划分：单个操作系统实例使用操作系统级的虚拟化，在一个或多个隔离容器之间停止动态划分，每个容器都具有唯一的可写文件系统和资源配额。 (3)、重建本钱低：创建和破坏容器的本钱较低，再加上单个虚拟机中的高包装密度，使容器成为部署各个微效劳的完美计算工具。
容器与微效劳	由于微效劳自身就是独立发布、独立部署、自治的、微小的效劳，而Docker容器也是跨平台、独立运行、小的执行单元。所以容器是微效劳架构的良好运行载体。
Docker的特点	(1)、Docker的设计理念很伟大：Docker的伟大性远不只是体如今“轻量的虚拟化”还体如今“同一个软件发布，在不同的平台上运行”。这更是Java最初流行起来的原因，而Python语言为了实现这一点，通过设计VirtualEnv把依赖包都随着程序发布，才处置了多平台运行的问题。 (2)、Docker的设计很优雅：一个应用都打包成一个image格式，image采用分层技术等等。
虚拟化技术对比	KVM，Kernel-based Virtual Machine的简称，是一个开源的系统虚拟化模块，自Linux 2.6.20之后集成在Linux的各个主要发行版本中，它使用Linux自身的调度器停止管理。 (1)、Docker比KVM更省资源、资源利用率更高； (2)、KVM属于OS级别隔离：KVM等虚拟化技术是在操作系统级别上停止虚拟和隔离，每一个虚机都是独立的OS。 (3)、Docker属于进程级别的隔离—轻量级性：Docker是在同一个操作系统中，实现了“轻量级的虚拟化”。Docker容器貌似是独立的操作系统，但实质上是同一个操作系统中的进程隔离，所以它是轻量级的；
开展趋势

(3)、DevOps

从某种角度来讲，DevOps其实已经包含了持续交付的含义，在这里还是分开讲述一下；

简介	DevOps是Development开发和Operations运维的组合(还包括测试)，重视软件开发人员和运维人员的沟通合作(不像开发和产品，经常刀刃相见)，它是通过自动化流程来使得软件构建、测试、发布更加迅速和可靠。 DevOps 是软件开发人员和 IT 运营之间的合作，目的是自动执行软件交付和根底架构更改流程。
功能/价值	(1)、DevOps管理整个生命周期：它强调的是以开发运维的视角，去构建一套高效完备的CI/CD流程，并通过自动化构建工具及发布系统，来实现软件生命周期的管理。从而使得普通开发人员，可以更快、更频繁地交付更加稳定的软件代码。 (2)、DevOps是一个种文化：DevOps是一个敏捷思维、一个沟通文化、一种组织形式，为云原生提供持续交付才干。它发明了一种文化和环境，可在其中快速、频繁且更可靠地构建、测试和发布软件。开发与运维之间的协同，上升到一种文化的层次，可以让应用快速的部署和发布。
特点	(1)、自动化发布管道、CI工具 (2)、快速部署到消费环境 (3)、开发、运维协同合作
优缺点
开展趋势	耐久以来，DevOps只是在文化上和流程指导上给出了方向，至于落地的方法论和工具链上，并没有很胜利，只是在CI/CD流程的个别环节上独立开展出一些比较胜利的产品，例如jenkins及一些自动化测试工具。 究其原因，还是在软件应用根底架构上，没有完善的技术支撑和技术体系，软件的运行环境千差万别、软件的部署和维护流程千差万别、软件的形态和架构千差万别，DevOps落地需要大量定制化，工具链落地难度很大。
关联	DevOps与上述的云原生、微效劳、容器等技术应用没有直接的关系，可以讲，没有微效劳和容器等技术，一样的可以朝着自动化的构建、测试和发布流程上行进。 (1)、DevOps与云原生的关系：DevOps仅提供理念指导，且因根底组件众多且不统一导致落地难 (2)、DevOps是云原生应用在开发、测试和发布流程上的必要手腕，基于容器的PaaS平台和微效劳架构，为DevOps的流行提供了土壤。 (3)、DevOps的自动化文化迎合了微效劳架构的目的：微效劳架构的重要目的就是快速发布，那么就需要在敏捷文化、自动化工具链上对流程提出了高要求。在这个根底上，利用DevOps的自动化文化、协作文化、敏捷文化，在软件的开发、测试、部署、运维流程上，提升了开发效率、降低了沟通本钱、提升了部署和上线速度。

(4)、持续交付

简介	基于容器的笨重的特性，构建持续集成和持续发布的流水线。
功能/价值	持续交付使得单个应用更改在准备就绪后即可发布，而不用等待与其他更改捆绑发布或等待维护窗口期等事件。
特点
优缺点	(1)、频繁发布、快速交付、快速反响、降低发布风险：持续交付让发布行为变得平淡可靠，因而企业可以以更低的风险频繁交付，并更快地获得最终用户的反响，直到部署成为业务流程和企业竞争力必不可少的组成部分。 (2)、小步快跑：持续交付是不误时开发，不停机更新，小步快跑，突破传统瀑布式开发流程，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。
开展趋势

2、效劳网格Service Mesh

背景	微效劳仍然分布式的热门方向，符合高内聚，低耦合架构设计思想，这个过程中呈现的问题等着我们去处置，比如Service Mesh呈现，并在过去的一年照旧坚持着热度。 (1)、微效劳VS效劳网格：微效劳更像是一个效劳之间的生态，专注于效劳治理等方面，而效劳网格更专注于效劳之间的通信，以及和 DevOps更好的结合。
简介	Service Mesh作为Sidebar运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在Service Mesh中实现。
功能/价值
特点
优缺点
开展趋势	目前流行的Service Mesh开源软件有Linkerd、Envoy和Istio，而最近Buoyant（开源Linkerd的公司）又发布了基于Kubernetes的Service Mesh开源项目Conduit。

3、不可变的根底设备—传统可变的根底设备(需人工维护/不可预测/易出错)→效率/扩展/更新

背景	在应用开发测试到上线的过程中，应用通常需要被频繁部署到开发环境、测试环境和消费环境中。在传统的可变架构时代，通常需要系统管理员保证所有环境的一致性。而随着时间的推移，这种靠人工来维护的环境一致性很难维持，环境的不一致又会导致应用越来越容易出错。这种由人工维护、经常被更改的环境就是我们常说的“可变根底设备”。
简介	与可变根底设备相对应的是不可变根底设备，指的是一个根底设备环境被创建以后不接受任何方式的更新和修改。这个根底设备也可以作为模板来扩展更多的根底设备。 (1)、假设需要对根底设备做更新迭代，那么应该先修改这些根底设备的公共配置部分，构建新的根底设备，将旧的交换下线。简而言之，不可变根底设备架构是通过整体交换而不是部分修改来创建和变卦的。
功能/价值
特点	(1)、一致性/可靠性/可预测性：不可变根底设备的优势在于能坚持多套根底设备的一致性和可靠性，而且根底设备的创建和部署过程也是可预测的。 (2)、提供了一个全新方式：在云原生构造中，借助K8S和容器技术，云原生不可变根底设备提供了一个全新的方式来实现应用交付。
优缺点	云原生不可变根底设备具有以下优势。 ● 能提升应用交付效率； ● 能快速、可靠地水平扩展； ● 能保证根底设备的快速更新和回滚；
开展趋势

4、声明式API

背景	与声明式设计相对应的是过程式设计。在过程式设计中，我们需要描绘为了让事物到达目的状态的一系列操作， 并正确执行这一系列的操作，最终才会到达我们期望的状态。
简介	声明式设计是一种软件设计理念：我们负责描绘一个事物想要到达的目的状态，并将其提交给工具，由工具内部去处置如何实现目的状态。
功能/价值
特点
优缺点
开展趋势

5、K8S

背景
简介	Kubernetes，即K8S，最初源于谷歌内部的 Borg，提供了面向应用的容器集群部署和管理系统，通过集中式的编排调度系统来动态的管理和调度。
详细功能	K8S提供了效劳注册、配置管理、负载平衡、故障隔离、业务恢复、自动扩容等才干。基于K8S的PaaS平台又提供了诸如根底数据效劳、网关效劳、微效劳治理效劳等根底效劳才干。此外，K8S不限制编程语言，社区活泼、功能稳定。
价值	(1)、是云原生架构的核心承载平台：基于K8S的容器化编排技术，已经事实上成为微效劳运行的规范根底架构环境，也正是K8S的流行，才真正推动了云原生架构理念的普及，K8S可以说就是云原生架构的核心承载平台。 (2)、是PaaS层的根底架构：鉴于K8S所具有的成熟度以及无可比较的优势，PaaS层的根底架构根本上都是采用K8S。
特点	(1)、编排平台提供了应用编排管理功能，与DevOps工具链联动，实现持续集成持续部署的快速迭代。 (2)、通过编排平台，容器被有机的组合成微效劳应用，实现应用系统的业务需求。
优缺点	(1)、K8S 的目的旨在消除编排物理/虚拟计算，网络和存储根底设备的负担，并使应用程序运营商和开发人员，完全将重点放在以容器为中心的原语上停止自助运营。 (2)、K8S提供稳定、兼容的根底平台，用于构建定制化的 workflows 和更高级的自动化任务。 (3)、K8S 具备完善的集群管理才干，包括多层次的安全防护和准入机制、多租户应用支撑才干、透明的效劳注册和效劳发现机制、内建负载平衡器、故障发现和自我修复才干、效劳滚动晋级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理才干。 (4)、K8S 提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。
开展趋势	Google为了压制AWS，把自己的容器运行平台开源出来，成为了如今的K8S。目前，K8S已经成为下一代云原生操作系统。对于想成为互联网架构师的同学，K8S架构是必需掌握的。
关联	基于容器和K8S的平台提供了云原生应用的规范发布和运行环境； K8S和PaaS平台是微效劳技术的运行平台。

(1)、基于Docker镜像的分布式应用

传统的分布式应用	设计几台效劳器，一个效劳器上装一个程序，程序之间，可以通过socket或其他协议通信。
基于Docker镜像的分布式应用	Docker镜像运行起来是一个一个的程序，多个程序合起来做成一个大的分布式应用怎么做呢？程序之间互相调用就行。就像传统的分布式应用，基于Docker的分布式应用也是如此，区别只是网络、CPU和内存资源都虚拟化了。

(2)、分布式集群运行分布式应用的复杂性——分布式容器应用的可靠性、可扩展性

假设我们搭建了一套分布式集群，运行了一套分布式应用：

	分布式集群运行分布式应用的复杂性	传统方法处置方案	K8S容器编排系统方案
可靠性	可靠性(故障如何排查修复)：这个集群中的某个机器出故障了（断电了、硬盘坏了等等），怎么去排查故障、怎么去修复？	人过去检查机器、修复或者重装	可以自动感知效劳器或容器应用呈现的问题，会自动将容器应用在集群内的其他机器里重新运行起来；
可扩展性	可扩展性(才干如何扩大)：这个集群中某一部分业务由于访问量增加，需要扩大支撑才干，怎么扩大？	负载过大了，就改应用的架构，上面套上负载平衡性，采用可扩展的架构。	通过启动相同的容器应用，自动的提升应用的负载支撑才干；
	1、传统方法处置方案的两个弊端：修复太慢，太费人力、本钱高、对业务影响大。想象一个网站，等扩展架构都弄好了，用户也就都流失了； 2、所以，降生了K8S容器编排系统，那么，以上两个问题就不复存在了。

6、云原生、微效劳、容器、K8S、SOA、PaaS平台、DevOps 之间的关系——互相促进、互相依赖、互相关联

	K8S	PaaS	微效劳	SOA	云原生	DevOps
容器	处置了Docker应用的扩展性和稳定性问题	容器技术是PaaS平台的规范	容器是微效劳的良好运行载体	无关	CNCF Runtime首推容器技术	容器是规范的运行发布组件，促进了DevOps的流行
K8S		K8S是PaaS平台底层架构的事实规范	K8S是微效劳架构的运行平台	无关	CNCF Provisioning首推K8S	基于容器的PaaS平台和微效劳架构，为DevOps的落地应用提供了土壤。
PaaS			利用成熟稳定的商业化PaaS平台是微效劳开发本钱最优的方案	无关	云原生技术在云计算经典理论三层架构中落地在PaaS层	DevOps最能体现其价值的平台就是：PaaS平台
微效劳				微效劳与SOA实质上是同一种设计思想在不同时代的不同实现。	云原生首推微效劳架构	微效劳架构强调快速上先, DevOps文化和工具链提升了微效劳的开发效率
SOA					无关	概念提出的都非常早，特别DevOps的CI/CD理论。在年代上有交集
云原生						云原生强调自动化以提升可以开发效率和运维效率。

参考文章
Kubernetes 架构 · Kubernetes 中文指南——云原生应用架构实战手册
微效劳、容器、云原生、Kubernetes、SOA、PaaS平台、Devops 之间的关系 - 网站
CNCF简介及其云原生交互景观

CNCF简介

          著名的CNCF（Cloud-Native Compute Foundation，云原生计算基金会）成立于2015年，由Google等大公司牵头，目前有100多家企业成员，其目的是在容器、微效劳及DevOps领域里、通过一系列的规范和规范协助企业和组织、在现代的云化环境中构建架构一致的应用。
           CNCF的Landscape定义了关于Provisioning、Runtime、容器编排、PaaS平台、微效劳治理等多个容器和微效劳相关子领域的开源组件和技术规范。
           从CNCF的Landscape上来看，进入CNCF的Landscape的组件，在功能、稳定性、活泼水平上大致都是业界领先的。简单直白的讲，基于CNCF云原生技术开发的应用，可以在业界各个平台里畅行无阻，部署在私有云、公有云里都是一样的技术体系和架构。
CNCF Cloud Native Interactive Landscape

官网地址：Cloud Native Landscape
          灰色的logo是非开源的，You are viewing 1,167 cards with a total of 3,387,190 stars, market cap of $18.9T and funding of $54.2B.

云原生技术的使用经历及方法

1、当前业务是否要立即切换到云原生架？

          虽然，云原生的推介文档有引导之嫌，但它的优点确实也是有目共睹。但是，这样的好东西，是不是就要，立即把当前的应用改换到基于云原生的架构？
           参考网站网友“华为云开发者联盟”的观点：理想很丰满，现实经常很骨感，需从应用的实际需要动身，目前的问题是否真的影响到业务开展，而推倒重来的代价能否接受得来。
2、云原生时代的开发者具备的才干

微效劳拆分及分层：业务拆分其实是一种业务架构才干，需要熟悉业务，并对业务停止笼统、解耦、提取公共功能。这是一个从代码库到软件包，在到数据库的全面拆分，并分层堆叠；
API接口化：所有的程序模块，都要通过效劳化接口API将其数据维护起来，并随时做好对外开放的准备；
无限伸缩随时迁移才干：所有的应用效劳和中间件都需要被设计成具备可无限伸缩的属性，与传统的IaaS层停止联动；
效劳治理：包括效劳注册发现、效劳流量路由调度、配置管理、安康检查、效劳间通信、效劳的弹力容错(隔离、限流、重试、幂等、熔断、降级…)，以及效劳观测性(日志、指针、调用链追踪、性能排名等)；
分布式中间件：包括分布式数据库、分布式缓存、分布式消息队列、分布式大数据处置等。
参考网站《新程序员》一书