共计 5704 个字符，预计需要花费 15 分钟才能阅读完成。
简介： 有幸作为阿里云 MVP 提前取得了阿里云云原生团队编写的《云原生架构白皮书》，心愿通过本人对于云原生的了解为开发者提供一篇观后感或者是可能参考的博文
1 云原生与分布式系统架构的关系
1.1 云原生架构的定义
《云原生架构白皮书》中对于云原生架构的定义为“基于云原生技术的一组架构准则和设计模式的汇合，旨在将云利用中的非业务代码局部进行最大化的剥离，从而让云设施接管利用中原有的大量非性能个性（如弹性、韧性、平安、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、麻利、高度自动化的特点。”
1.2 分布式系统架构的定义
此处定义参考百度百科为“在一个分布式系统中，一组独立的计算机展示给用户的是一个对立的整体，就如同是一个零碎似的。零碎领有多种通用的物理和逻辑资源，能够动静的分配任务，扩散的物理和逻辑资源通过计算机网络实现信息替换。零碎中存在一个以全局的形式治理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件负责实现这个模型。”
1.3 云原生与分布式系统架构的关系
分布式架构的重点在于解决计算力的保障问题以及为了进步计算力并同时确保零碎的可靠性、可用性和安全性而产生的诸如弹性伸缩、负载平衡、分布式存储等问题，其指标是在于构建一个分布式的安全可靠的计算力根底平台。通常来说，对于信息系统的架构形式的进化和扭转即是随同着接入数据和所提供的业务由少变多的过程，目前为止信息系统的架构经验了单机架构、集群架构、分布式架构、分布式多活数据中心架构几个阶段，同时随同着业务零碎架构一起演变的还有各种外围零碎和存储系统，比方关系数据库的分库分表革新、从本地缓存过渡到分布式缓存等。要理清分布式架构和云原生的关系，先来演绎一下分布式架构与云之间的关系，云个别指的是一个提供资源的平台，云计算的实质是按需分配资源和弹性计算，而针对目前数据井喷并随着物联网利用的推动依然接入量在呈指数回升的现状下，分布式架构是最可能满足构建一个合格的云平台所应具备特质的架构形式。云原生利用即专门为在云平台部署和运行而设计的利用，采纳云原生的设计模式能够优化和改良传统利用模式，使利用更加适宜在云平台上运行，因而云原生倒退的实质需要来自于 SAAS 层面设计理念的改良，因为 SAAS 层的设计理念的改良而进一步从北向往南向推动了 PAAS 层特地是中间件的降级从而确保整个云平台的架构可能更好的服务于云原生架构的扭转。因而，云原生和分布式架构的降级和迭代是一个滚动的过程，为了更好的施展云平台的特点而有了云原生的需要和设计模式扭转，而在这个过程中云原生也反过来促成了上层架构的降级。这个迭代的过程充沛的反馈了互联网或者说数据时代开发理念的特色，即滚动而非单向。
1.3《云原生架构白皮书》章节导读
通过《云原生架构白皮书》的第 1 章和第 2 章内容能够充沛的了解云原生的实质和云原生架构的特点，在浏览这两章的内容时举荐参考分布式架构的相干书籍，因为云原生和分布式架构密切相关，然而降级迭代的着力点又有所区别，所以可能联合在一起进行浏览是最好的。
2 云原生次要架构准则和技术剖析
2.1 微服务和小零碎服务
微服务架构，从宏观上来看，无非就是细化了服务拆分过程中的粒度，粒度越细，业务耦合越小，容错性就越好，并且前期扩大也会越容易。然而颗粒度过细，又会带来另外一些麻烦比方晋升了保护老本、影响排查问题时的效率、业务开发人员很难梳理分明服务之间的依赖关系等。因而《云原生架构白皮书》在微服务相干章节中又提到了小零碎服务的概念，即是一个颗粒度的中间状态，其实外围就是一个服务拆分颗粒度的问题，白皮书中的第 3 章中有专门章节对于云原生微服务特地是微服务设计过程中的束缚做了具体介绍，基本目标就是使微服务的倒退处于一个受约束的状态，而不是因为有了微服务的理念就是服务拆分的颗粒度越细越好。
2.2 容器技术与云原生的关系
从白皮书中提供的比照图能够分明的发现，云原生在代码方面，对于代码通常所蕴含的三局部：业务代码、三方软件和解决非性能个性的代码进行剥离，最终想实现的现实状态是把所有非功能性代码（即除业务代码局部）从 SAAS 层剥离到 PAAS 层和 IAAS 层中去，当然目前还是没有齐全做到。剥离非性能代码依然是一个设计模式理念的变动，而在这个理念的落地过程中容器技术成为了最好的工具。
在白皮书中这张比照图的根底上，依据其余一些公开材料可能更清晰的反映出容器技术利用之后，云原生架构所产生的变动。
单机架构
注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师 2.0》高翔龙著 电子工业出版社
集群架构
注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师 2.0》高翔龙著 电子工业出版社
服务化架构
注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师 2.0》高翔龙著 电子工业出版社
在这种架构形式下以被广泛应用的 Kubernetes 为例，K8S 中的大部分概念如 Node（除了集群管制节点 Master 外 K8S 集群中的其余机器）、Pod（容器）等能够被看作资源对象，简直所有资源对象都能够通过 K8S 提供的 kubectl 工具执行增、删、改、查等操作并将其保留在 etcd 中长久化存储，也就是说容器服务包含 DOCKER、K8S 等的全新设计模式天生就适宜于分布式服务架构。当然相比集群架构来说，在开发运维自动化程度的要求上也天然较高以确保对于容器可能进行有序而全局化的治理避免零碎呈现不可管制的状态。
2.2《云原生架构白皮书》章节导读
白皮书的第 3 章和第 4 章次要介绍的就是次要的云原生技术和阿里云原生架构设计的内容，其实外围的技术就是容器技术，在这个根底上包含微服务的理念、Serverless 和 Service Mesh 等才可能被顺利的付诸于实际，而在容器技术中自动化程度又是一个重中之重，所以白皮书中数次提到的所有过程自动化准则就是是否施展云原生技术劣势的外围因素。
3 小结：云原生的将来倒退方向
云原生毕竟是一个很大的概念，实践上所有从设计和开发之始就以部署在云上的设计理念都可能称为云原生，而微服务则是云原生在服务维度典型的表现形式，而容器服务即是可能将微服务胜利落地的核心技术。Serverless 是一个技术也能够从字面意思了解为将来的倒退方向，核心理念依然是将非业务局部的性能下沉至基础设施，从这点上来说，现实中的 Serverless 甚至不用蕴含目前 K8S 中的集群容量布局、平安保护和故障诊断等性能，将这些集中思考为云基础设施所应该具备的性能，而功能模块只需思考本身的业务，充分体现出的是轻量，通过事件驱动将轻量的服务和服务间以及轻量服务和云平台之间连接起来，整个体系相比集群化部署来说，与其说是一个零碎，不如说是云基础设施根底上各类微服务造成的生态。
作者简介：朱祺 国内电气电子工程师协会 IEEE 高级会员、阿里云寰球 MVP
简介： 有幸作为阿里云 MVP 提前取得了阿里云云原生团队编写的《云原生架构白皮书》，心愿通过本人对于云原生的了解为开发者提供一篇观后感或者是可能参考的博文
1 云原生与分布式系统架构的关系
1.1 云原生架构的定义
《云原生架构白皮书》中对于云原生架构的定义为“基于云原生技术的一组架构准则和设计模式的汇合，旨在将云利用中的非业务代码局部进行最大化的剥离，从而让云设施接管利用中原有的大量非性能个性（如弹性、韧性、平安、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、麻利、高度自动化的特点。”
1.2 分布式系统架构的定义
此处定义参考百度百科为“在一个分布式系统中，一组独立的计算机展示给用户的是一个对立的整体，就如同是一个零碎似的。零碎领有多种通用的物理和逻辑资源，能够动静的分配任务，扩散的物理和逻辑资源通过计算机网络实现信息替换。零碎中存在一个以全局的形式治理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件负责实现这个模型。”
1.3 云原生与分布式系统架构的关系
分布式架构的重点在于解决计算力的保障问题以及为了进步计算力并同时确保零碎的可靠性、可用性和安全性而产生的诸如弹性伸缩、负载平衡、分布式存储等问题，其指标是在于构建一个分布式的安全可靠的计算力根底平台。通常来说，对于信息系统的架构形式的进化和扭转即是随同着接入数据和所提供的业务由少变多的过程，目前为止信息系统的架构经验了单机架构、集群架构、分布式架构、分布式多活数据中心架构几个阶段，同时随同着业务零碎架构一起演变的还有各种外围零碎和存储系统，比方关系数据库的分库分表革新、从本地缓存过渡到分布式缓存等。要理清分布式架构和云原生的关系，先来演绎一下分布式架构与云之间的关系，云个别指的是一个提供资源的平台，云计算的实质是按需分配资源和弹性计算，而针对目前数据井喷并随着物联网利用的推动依然接入量在呈指数回升的现状下，分布式架构是最可能满足构建一个合格的云平台所应具备特质的架构形式。云原生利用即专门为在云平台部署和运行而设计的利用，采纳云原生的设计模式能够优化和改良传统利用模式，使利用更加适宜在云平台上运行，因而云原生倒退的实质需要来自于 SAAS 层面设计理念的改良，因为 SAAS 层的设计理念的改良而进一步从北向往南向推动了 PAAS 层特地是中间件的降级从而确保整个云平台的架构可能更好的服务于云原生架构的扭转。因而，云原生和分布式架构的降级和迭代是一个滚动的过程，为了更好的施展云平台的特点而有了云原生的需要和设计模式扭转，而在这个过程中云原生也反过来促成了上层架构的降级。这个迭代的过程充沛的反馈了互联网或者说数据时代开发理念的特色，即滚动而非单向。
1.3《云原生架构白皮书》章节导读
通过《云原生架构白皮书》的第 1 章和第 2 章内容能够充沛的了解云原生的实质和云原生架构的特点，在浏览这两章的内容时举荐参考分布式架构的相干书籍，因为云原生和分布式架构密切相关，然而降级迭代的着力点又有所区别，所以可能联合在一起进行浏览是最好的。
2 云原生次要架构准则和技术剖析
2.1 微服务和小零碎服务
微服务架构，从宏观上来看，无非就是细化了服务拆分过程中的粒度，粒度越细，业务耦合越小，容错性就越好，并且前期扩大也会越容易。然而颗粒度过细，又会带来另外一些麻烦比方晋升了保护老本、影响排查问题时的效率、业务开发人员很难梳理分明服务之间的依赖关系等。因而《云原生架构白皮书》在微服务相干章节中又提到了小零碎服务的概念，即是一个颗粒度的中间状态，其实外围就是一个服务拆分颗粒度的问题，白皮书中的第 3 章中有专门章节对于云原生微服务特地是微服务设计过程中的束缚做了具体介绍，基本目标就是使微服务的倒退处于一个受约束的状态，而不是因为有了微服务的理念就是服务拆分的颗粒度越细越好。
2.2 容器技术与云原生的关系
从白皮书中提供的比照图能够分明的发现，云原生在代码方面，对于代码通常所蕴含的三局部：业务代码、三方软件和解决非性能个性的代码进行剥离，最终想实现的现实状态是把所有非功能性代码（即除业务代码局部）从 SAAS 层剥离到 PAAS 层和 IAAS 层中去，当然目前还是没有齐全做到。剥离非性能代码依然是一个设计模式理念的变动，而在这个理念的落地过程中容器技术成为了最好的工具。
在白皮书中这张比照图的根底上，依据其余一些公开材料可能更清晰的反映出容器技术利用之后，云原生架构所产生的变动。
单机架构
注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师 2.0》高翔龙著 电子工业出版社
集群架构
注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师 2.0》高翔龙著 电子工业出版社
服务化架构
注：以上图片来源于《超大流量分布式系统架构解决方案：人人都是架构师 2.0》高翔龙著 电子工业出版社
在这种架构形式下以被广泛应用的 Kubernetes 为例，K8S 中的大部分概念如 Node（除了集群管制节点 Master 外 K8S 集群中的其余机器）、Pod（容器）等能够被看作资源对象，简直所有资源对象都能够通过 K8S 提供的 kubectl 工具执行增、删、改、查等操作并将其保留在 etcd 中长久化存储，也就是说容器服务包含 DOCKER、K8S 等的全新设计模式天生就适宜于分布式服务架构。当然相比集群架构来说，在开发运维自动化程度的要求上也天然较高以确保对于容器可能进行有序而全局化的治理避免零碎呈现不可管制的状态。
2.2《云原生架构白皮书》章节导读
白皮书的第 3 章和第 4 章次要介绍的就是次要的云原生技术和阿里云原生架构设计的内容，其实外围的技术就是容器技术，在这个根底上包含微服务的理念、Serverless 和 Service Mesh 等才可能被顺利的付诸于实际，而在容器技术中自动化程度又是一个重中之重，所以白皮书中数次提到的所有过程自动化准则就是是否施展云原生技术劣势的外围因素。
3 小结：云原生的将来倒退方向
云原生毕竟是一个很大的概念，实践上所有从设计和开发之始就以部署在云上的设计理念都可能称为云原生，而微服务则是云原生在服务维度典型的表现形式，而容器服务即是可能将微服务胜利落地的核心技术。Serverless 是一个技术也能够从字面意思了解为将来的倒退方向，核心理念依然是将非业务局部的性能下沉至基础设施，从这点上来说，现实中的 Serverless 甚至不用蕴含目前 K8S 中的集群容量布局、平安保护和故障诊断等性能，将这些集中思考为云基础设施所应该具备的性能，而功能模块只需思考本身的业务，充分体现出的是轻量，通过事件驱动将轻量的服务和服务间以及轻量服务和云平台之间连接起来，整个体系相比集群化部署来说，与其说是一个零碎，不如说是云基础设施根底上各类微服务造成的生态。
作者简介：朱祺 国内电气电子工程师协会 IEEE 高级会员、阿里云寰球 MVP
原文链接：https://developer.aliyun.com/…_content=g_1000162426
本文为阿里云原创内容，未经容许不得转载。