开发者学堂课程【云计算、容器和云原生基础课程：为什么要学习云原生技术（上）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/823
为什么要学习云原生技术（上）
------马永亮
目录：
一、课程介绍
二、云原生简介
一、课程简介
●由阿里云、Linux开源软件学园和马哥教育联合推出
◆“CNCFxAlibaba云原生技术公开课”的前置课程
◆CKAD/CKA/CKS认证的配套课程
●内容涵盖
◆手把手实践Kubernetes云原生操作系统
◆阿里云Kubernetes托管服务ACK。
二、云原生简介
1、信息迭代的关键历程
从上个世纪80年代到今天，开发流程、应用架构、打包部署、基础设施等软件和信息系统领域的相关技术，分别进行了各自不同形式的迭代，而且也各有各的里程碑式的代表技术，像开发流程中的瀑布模型、敏捷模型，再到今天。比较火热的Dev Ops，甚至是get UPS模型，都经历了三代类似的软件架构，也从最初的单体架构，到后来的分层架构、分布式架构，再到今天的微服务架构，也是经历了非常有代表性的几代打包和部署技术，面向的这个主题环境，从最初的裸服务器，到后来的虚拟机，再到今天主流的容器化技术，也有三代非常典型的代表性技术。最后对应的基础设施的维护模型，从最初的数据中心，到后来的托管，再到今天的云计算，显然也有三个非常典型的发展的里程碑，从图中也可以非常清晰的看到微服务、容器化和云计算，这是今天的主流模型，这其中不得不提一提的就是分布式技术的应用，随着业务规模的扩张，应用程序从单体走向、分层分布式以纵向或者是横向切分的。
2、分布式系统面临的困难
分布式系统是将大的应用，切分成多个小应用，几乎适用于提升系统容量、加强系统可用性的必然选择。但是任何解决方案都不是理想化的，一旦分布式系统引入优势的同时，也必然会带来一些问题，比如发布的频率非常高，而且部署起来部署的频次也非常高，并且部署起来要解决这种依赖关系。因此部署也较为复杂，而且它的难度级数是增加的，更重要的是，因为网络通信的引入，那么响应时间慢就变成了一个非常让人难以接受和容忍特性，运维的复杂度也被成倍的放大了，接着其整体的系统的出现故障以后测试排错复杂。但是为此它带来的好处也包括：因为分布式开发应用，大的单体应用被切分成了多个小的应用。各个应用、每个应用、每个单独的应用更加容易实现的开发故障的影响范围呢，通常也局限在单个应用的范围内，而且通过所谓的这种扩展机制，也能够将这种故障的影响范围给它降低，因为这是统一机制所带来的好处之一。
很显然，为了把这些问题解决，为此呢，也引入了很多技术手段：比如什么服务治理、架构管理，自动化运维、资源调度管理、整体架构监控，立体化监控体系，还有流量治理的技术手段来帮忙解决，在引入分布式服务化架构带来的好处的同时也要去解决他可能要面临的众多问题。
3、创建及运行分布式应用的需求
●运行分布式应用的典型需求有如下几个类别
◆生命周期管理
◆网络
◆状态管理
◆绑定(应用集成)
●ESB中间件及其变体是满足这类分布式需求的前一代主流解决方案
◆提供良好的功能集
◆但是，单体架构以及业务逻辑和平台之间紧密的技术耦合会导致的技术和组织的中心化。
大体上展示了每一个需求维度可能会涉及到的一些技术细节点，比如对生命周期管理来讲，需要关注的包括打包健康状态检测、部署更新、扩缩容应用配置等。
而网络维度则有向服务的发现、测试、发布重试、超时熔断，还有消息队列安全、可观测性等，而在绑定方面，则有连接器那协议、消息格式等相关的话题。在状态管理方面，也有多个话题存在，比如工作流、管理、幂等性、缓存等相关的功能，显然能够满足这些需求的解决方案曾经的主流系统是Binding。
3.1ESB分布式应用中间件的限制
变体ESB其实就是众所周知的企业服务总线，比如像面向消息的中间件，还有一些轻量级的集成框架等，所以从这个角度上来讲就是一款中间件，他支持利用面向服务的架构实现异构环境间的这种互操作性，也提供了良好的功能及，但是单体架构以及业务逻辑和平台之间紧密的技术耦合，一定会导致技术和组织的中心化，所以这是一个与分布式应用本身或者与最初引入分布式系统背道而驰的趋势。
ESB在满足分布式系统需求的局限性也同样在这四个方面各有所表现，比如在生命周期方面，它通常只支持一个语言的运行时，当然这几个一般而言，它通常只是一个语言，这其中最为典型的代表就是Java。这也就限定了软件该如何打包，哪些库可以用，能够提升打补丁的频率等。另外一个业务服务必须要使用这些对应的库，而这些库与平台的这种紧耦合程度决定了必然要使用相同的语言进行编写，所以这些对系统扩展而言一定会带来极大的束缚。
在第二方面，很显然网络上集中于一种主要编程语言及其相关技术，在网络方面依然也要受限于此。更重要的是，网络问题和语义也一定会深深嵌入到业务服务当中，所以这也就使得将来的这种升级、，架构变更，会牵一发而动全身。比如对Java语言来讲，很显然这种解决方案指的就是JMSRGPCR，在状态方面，与状态交互的库和接口并没有完全抽象出来，也没有与服务运行时进行完全结束，所以框架程序与框架本身也是紧耦合的。绑定这个方面使用集成中间件的主要驱动因素之一就是能够使用不同的协议、数据格式、消息交换模式等来连接其他系统。很显然，这些连接器必须与应用程序共存，这也就意味着将来这种依赖项必须以业务逻辑一起进行更新和打补丁。这种绑定导致的系统扩展，也是极其受限的。面对这样的问题，发展到今天相应的解决方案大体上就变成了基于容器化容器编排系统、UPS微服务及典型的智力系统服务网格等技术综合于一体的，被称为叫做云原生的解决方案。
4、云原生的定义
原生的定义其实云原生的概念，最早是在2013年由Matt Stine于2013年在Pivotal司就职的时候提出的。2015年的时候，当云原生这个概念刚刚开始流行的时候，Matt Stine在他出版的一本书当中定义了云原生架构的几个关键特征，这其中最为著名的包括：12要素，应用程序、微服务，自助是敏捷基础设施。还有基于API的协作和反脆弱性；并且在2017年InfoQ的采访当中，Matt Stine做了一些改变，并且提出了原生的六个特征：括号化，可观测性、可部署性、可测试性、可替换性和可处理性。后来在其官网上对云原生的架构进行一个比较规范性的描述，他认为云原生是具有如下四大特征或者的这样一种应用：DevOps、持续交付、微服务、容器化。他们认为这种原生应用一定会要满足，或者基于这几种技术进行构建。2015年成立的云原生计算基金会CNCF呢定义了云原生架构，有三个基本特征：容器化封装、自动化管理以及微服务。
●2018年，CNCF在关于云原生定义v1.0版本中这样描述云原生技术体系
◆云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用
◆云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API
★这些技术能够构建容错性好、易于管理和便于观察的松耦合系统
★结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更
●云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。
要注意的是，随着云原生生态和边界的这种不断扩大化，云原生自身的定义肯定会在过去被多个个人、组织或者公司从不同的维度进行了解读。很显然在未来也一样会有人对他进行不同的定义，甚至就包括CNCF很有可能也会改变对于原生的定义。如果说要根据摩尔定律来进行推断的话，未来对于云原生定义一定还会不断的发生变化，但一个显著的事实是，容器加K8S已经成为一个计算的底座。
5、容器技术(Containers)和容器编排
●容器技术由来已久，dotCloud(后改名为Docker)公司在Docker项目中发明了“容器镜像”技术之后，创造性地解决了应用打包的难题才焕发出新的生命力，并以“应用容器”的面目风靡于世
●单个容器难以产生价值，容器编排才是根本
◆Kubernetes是云原生系统的底座
●现代应用容器技术和Kubernetes将打包、部署应用程序的方法演化成了与编程语言关的格式。
6、Kubernetes和声明式API
●Kubernetes的关键特性
◆容器编排系统
◆声明式API
◆“以应用为中心”的现代应用基础设施
★纳管各类基础支撑类服务，并经由声明式API向上层应用暴露这些基础设施的能力
◆PlatformforPlatform类型的系统
★根本目标在于方便基础设施工程师构建其它的平台系统
★例如ServiceMesh或Serverless等
7、微服务治理
微服务本身可以理解为传统的分布式服务的进一步细化，细化到每一个服务本身可能进行提供一个单一的功能，并且将其功能、接口通过API向外界提供。所以从这个意义上来讲，微服务是一种流行的架构风格，它用于构建弹性化。高度可扩展、可独立部署且能够快速迭代的应用程序，那单体应用被切分成了多个小型的应用，每一个应用独立进行管理，甚至于每个应用都有自己的独独占的存储系统。因而微服务架构就是由一系列的小型自治服务所组成的，每个服务基本上子包含的。当前的云计算环境系统是一个有着公有云、私有云和混合云等新型的动态环境系统，很显然，动态化是从计算应用的天然属性，同时它也是云原生的天然属性，而这种动态性为了能够更好的得以开发、创建、运行，必然要用到微服务的网格，几乎必然的要用到一种所谓的叫做服务治理体系，服务治理框架，其中微服务架构是支撑该目标的关键所在。通常情况下，为了便于用户开发、创建、维护和运行微服务系统或者微服务应用，通常要依赖于一个对应的服务治理框架或者服务治理工具。这其中比较著名的代表有：Dubbo、 spring cloud以及spring cloud的增强版spring cloud alibaba，还有下一代的微服务治理系统，也就是服务网格。
8、服务网格（ServiceMesh）
●服务网格定义：
服务网格在分布式架构或者是微服务架构系统当中服务到的通信是至关重要的，因此要确保通信通道要保持无故障、安全、高可用和足够健壮。所以这些需求之处，恰恰就是服务网格作为基础结构组件所出现的地方，而它的使用方式是通过在每一个应用实例的外层附加一个服务代理，来确保受控的服务到服务的同行的。在上图当中，差不多可以看出来一个端，这其中每一个单元就是一个有浅蓝色底色，浅蓝色这个种叫业务逻辑，深蓝色这个这个方框为叫做Sidecr的应用所共同组成。在服务网络当中，与单个服务一起部署的代理就可以实现服务之间的通信。这个代理被通称为被称为叫做Sidecr，主要负责各个业务单元实例之间的这种通信相关的功能，比如负债均衡服务、断路、超时、重试一系列各种各样的高级功能。当然，服务网格并不是一蹴而就出现的，它恰恰就是在曾经说过的最早期的这种，再到后来Dubbo、 spring cloud等一路发展的基础之上，所衍生出来的新一代的这个通行模型通行概念。
9、Sidecar模式
●ServiceMesh以Sidecar形式，将服务治理从业务逻辑中剥离，并拆解为独立进程，实现异构系统的统一治理和网络安全。
10、不可变基础设施(immutableinfrastructure与一次性组件
●不可变基础设施是早在2013年由ChadFowler在其一篇博客中提出的一个很有的预见性的构想
◆其核心思想在于，任何基础设施的实例一旦创建之后即变为只读状态，若需要修改和升级，只能通过替换为新的实例来实现
◆传统的服务器(裸金属或虚拟机)支持配置的多次变更，因而通常会导致如下问题
★灾难发生时，重新构建较为困难(因手动的变更操作所致)
★存在导致状态不一致的风险毒
●实现
◆容器和容器镜像
◆云端虚拟化组件
