简介： 有幸作为阿里云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/article/768344?utm_content=g_1000162426
本文为阿里云原创内容，未经允许不得转载。
