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时代基础设施是什么？又会有什么高端玩法？ 我们需要加深对基础知识的理解，以不变应万变，深耕一个领域，同时也需要多去尝试新技术，扩宽自己的眼界，增加解决问题的思路 |
参考文章：后端技术趋势指南|如何选择自己的技术方向_极客重生的博客-CSDN博客
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层进行联动；
服务治理：包括服务注册发现、服务流量路由调度、配置管理、健康检查、服务间通信、服务的弹力容错(隔离、限流、重试、幂等、熔断、降级…)，以及服务观测性(日志、指针、调用链追踪、性能排名等)；
分布式中间件：包括分布式数据库、分布式缓存、分布式消息队列、分布式大数据处理等。文章来源：https://www.toymoban.com/news/detail-415343.html
参考CSDN《新程序员》一书文章来源地址https://www.toymoban.com/news/detail-415343.html
到了这里，关于CloudNative：云原生(分布式云)的简介(发展&演变/为什么需要/优势&价值/安全/对比传统企业应用)、四大核心技术、CNCF云原生交互景观、云原生技术的使用经验及方法之详细攻略的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
