云原生

java

Publish Date: 2022-06-26

随着虚拟化技术的成熟和分布式架构的普及，用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型，它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。随着云化技术的不断进展，云原生的概念也应运而生。

大家言必称云原生，却鲜少有人告诉你到底什么是云原生，若是找资料来看，读完大多会感觉云绕雾罩，一知半解，总之虚得很；甚至会让你一度怀疑自己的智商。云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。

说到云原生，就不得不提到云计算，云计算这个词也火了很久。

什么是云计算

用过阿里云主机的，对云服务器应该不陌生，在那些年大家应该看过诸如这样的新闻标题：“中国云计算之父：当年拿走马云10个亿，11年后还给马云5400亿”，没错，这个中国云计算之父就是我们阿里云的创始人——王坚博士。

早些年，国内电商迎来飞速发展时期，淘宝用户每年增长十几倍，而国外云计算平台都是针对本土企业设计，没有考虑过服务几亿人的情况。于是拥有一套属于自己、便宜好用的计算架构，成为阿里巴巴当时的重中之重。于是马云把王坚从微软挖来，负责构建阿里的计算架构，并且约定每年投10个亿，坚持10年。

不过，阿里云发展的前几年并不顺利；内部质疑、技术出现瓶颈，大批工程师因为看不到阿里云的前景，纷纷投入其他部门，或者干脆离开阿里，最严重的时候，阿里云80%工程师都选择离开，但王坚依然顶着巨大压力坚持了下去。

2013年，飞天系统实现了5000台机器的集群调度，阿里正式成为中国第一家拥有完整云计算系统能力的企业，也成为中国第一家有能力提供海外云计算服务的公司。此后，12306将业务放到了阿里云上，春运高峰期间，阿里云承担了12306系统大部分的流量，一改往日抢票期间系统瘫痪的情况。展示了自身实力的阿里云，开始大规模对外提供云计算服务。去年双十一，阿里云更是创造了新的世界纪录，而阿里云全都支撑下来，刷新了历史。值得关注的是，对比五年前，阿里云的业绩已增长了数十倍。如今，阿里云在国内的份额遥遥领先其它对手，并且成功走向国际。

想必大家已经感受到了云计算的强大，那么接下来我们再来看看云计算的概念。

2006年，亚马逊把基于分布式操作系统聚集起来的强⼤计算能⼒，通过互联⽹的⽅分输送给千千万万的普通⽤户，⼈们给这种计算的在线服务，起的名字叫做云计算。

通俗的说，把分布式操作系统聚集起来的强大计算能力像水电一样，成为大众的必需品，输送给千家万户，让每个人都可以高效利用这种计算资源。就像水龙头一样，我们什么需要水打开水龙头就好了，再也不用去井里挑水喝了；什么时候需要电直接打开开关就好了，再也不用拿两根木头磨来磨去了。但是，你要付费，你得掏钱，天底下没有免费的午餐，因为能量守恒。

云计算的四个层次

IaaS（基础架构即服务）

IaaS（Infrastructure as a Service，基础架构即服务）是基础层。在这一层，通过虚拟化、动态化将IT基础资源（计算、网络、存储）聚合形成资源池。资源池即计算能力的集合，终端用户（企业）可以通过网络获得自己需要的计算资源，运行自己的业务系统。这种方式使用户不必自己建设这些基础设施，而是通过付费即可使用这些资源。

PaaS（平台即服务）

在IaaS层之上的是PaaS（Platform as a Service，平台即服务）层。这一层除了提供基础计算能力，还具备了业务的开发运行环境，提供包括应用代码、SDK、操作系统以及API在内的IT组件，供个人开发者和企业将相应功能模块嵌入软件或硬件，以提高开发效率。对于企业或终端用户而言，这一层的服务可以为业务创新提供快速、低成本的环境。

SaaS（软件即服务）

最上层是SaaS（Software as a Service，软件即服务）。实际上，SaaS在云计算概念出现之前就已经存在，并随着云计算技术的发展得到了更好的发展。SaaS的软件是“拿来即用”的，不需要用户安装，软件升级与维护也无须终端用户参与。同时，它还是按需使用的软件，与传统软件购买后就无法退货相较具有无可比拟的优势。

DaaS（数据即服务）

越来越多的数据沉淀、抽象形成了新的服务——DaaS（Data as a Service，数据即服务）。数据聚合抽象，把数据转换成通用信息，从而为公众提供公共信息服务。例如，对于天气信息，可能A需要根据天气信息来判断出门穿着，B需要根据天气信息判断是否洗车，C需要根据天气信息判断是否准备防洪防涝设施等。不同用户均可利用DaaS满足自己的诉求。

此外，通过对各类数据信息进一步加工形成信息组合应用，会进一步盘活数据，提升数据价值。这就像搭积木一样，对基础数据信息块以不同的方式进行组装，可以达到千变万化的效果。DaaS服务已成为当下数字化转型的重要抓手。

日薄西山：瀑布模型

传统的软件开发环境依赖于由单体架构驱动的所谓“瀑布”模型，其中软件是按顺序开发的。

1、设计师准备产品设计以及相关文件。
2、开发人员编写代码并将其发送给测试部门。
3、测试团队运行不同类型的测试来识别错误并衡量应用程序的性能。
4、发现错误时，会将代码发送回开发人员。
5、代码成功通过所有测试后，将部署到测试生产环境并部署到实时环境。

如果需要更新代码或添加/删除功能，则必须重新完成整个过程。当多个团队在同一个项目上工作时，相互协调代码更改是一个很大的挑战。它还限制他们使用单一的编程语言。此外，部署大型软件项目需要建立庞大的基础架构以及广泛的功能测试机制。整个过程效率低下且耗时。

引入了微服务架构来解决大多数这些挑战。微服务架构是一种面向服务的架构，其中应用程序构建为松散耦合的独立服务，可以通过 API 相互通信。它使开发人员能够处理不同的服务并独立使用不同的语言。借助充当版本控制系统的中央存储库，组织能够同时处理代码的不同部分并更新特定功能，而不会干扰软件或导致应用程序停机。此外，实施自动化后，企业可以轻松、频繁地进行具有重大影响的更改，而无需付出多少努力。

后起之秀：云原生

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论，云原生（CloudNative）是一个组合词，Cloud+Native。云原生拆分为云和原生两部分。

Cloud表示应用程序位于云中，而不是传统的数据中心；
Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

云原生的发展历史，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义：

Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：符合12模式（Twelve-Factor App）、微服务、自敏捷架构、基于API协作、扛脆弱性
2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化

封装+自动化管理+面向微服务；
到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理，6个特质
到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。
Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，主要原因是云原生的技术体系还在不断发展，不断完善。我们按照Pivotal最新官网的定义来理解云原生，即DevOps+持续交付+微服务+容器。

什么是云原生？

云原生架构是一种创新的软件开发方法，专为充分利用云计算模型而设计。它使组织能够使用微服务架构将应用程序构建为松散耦合的服务，并在动态编排的平台上运行它们。因此，基于云原生应用程序架构构建的应用程序是可靠的，可提供规模和性能，并缩短上市时间。

为什么云原生如此重要？

云原生应用专为云模型而开发。小的专用功能团队快速将这些应用构建和部署到可提供轻松的横向扩展和硬件解耦的平台，为企业提供更高的敏捷性、弹性和云间的可移植性。

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

云原生四要素

云原生的四要素包括：持续交付、DevOps、微服务、容器

持续交付

持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。

DevOps

这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。

微服务

微服务是将应用作为小型服务集合进行开发的架构方法，其中每个服务都可实施业务功能，在自己的流程中运行并通过 HTTP API 进行通信。每个微服务都可以独立于应用中的其他服务进行部署、升级、扩展和重新启动，通常作为自动化系统的一部分运行，可以在不影响最终客户的情况下频繁更新正在使用中的应用。

容器

与标准虚拟机相比，容器能同时提供效率和速度。单个操作系统实例使用操作系统级的虚拟化，在一个或多个隔离容器之间进行动态划分，每个容器都具有唯一的可写文件系统和资源配额。创建和破坏容器的开销较低，再加上单个虚拟机中的高包装密度，使容器成为部署各个微服务的完美计算工具。

主要区别：云原生与传统企业应用

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