开发者学堂课程【云计算、容器和云原生基础课程：为什么要学习云原生技术（下）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/823
为什么要学习云原生技术（下）
------马永亮
目录：
一、云原生架构参考示例
二、CNCF的云原生项目
三、云原生平台DIY
四、云原生未来架构趋势
五、云原生人才培养计划课程简介
一、云原生架构参考示例
1、云原生架构参考示例
云原生的架构模型，通过对CNCF所了解的云原生技术特性的描述，可以大体上描绘出来一个云原生的参考架构：
●基础设施层
◆主机、存储、网络管理
●预配层(Provisioning)
◆主机创建、操作系统安装、存储分配等
●运行时层
◆CRI、CNICS
●容器编排及管理
●云原生应用程序定义与开发
2、云原生系统的功能特征
●动态化是云原生应用的天然属性，微服务架构是支撑该目标的关键所在
◆各微服务提供的API应该集成为复合的API，通过“API网关”对外提供统一的访问接口
★API网关对于安全、监控计费等也是必不可少的
◆组件微服务治理
★Istio、OpenPaaS、Linkerd等
◆Serverless
★Knative等
◆各微服务以窗口镜像进行交付
◆云原生编排平台
★调度、运行、健康状态检测、监控
★弹性扩缩容
◆灵活部署:重建、灰度、蓝绿、金丝雀、A/B测试、影子(Shadow)部署
动态是云原生应用和云原生基础设施的天然属性，所以微服务架构是支撑该目标的关键所在。每一个服务本身都通过API向外提供其功能，很显然不希望客户端的真正的系统外的部分，分别独立的急需要通信的或需要获取数据的每一个微服务进行通信。所以各个微服务提供的API应该聚合成为复合的API，通过API网关对外提供一个统一的访问接口。
因此再去构建云系统的时候还有一个关键性的组件叫做API网关，微服治理也就必不可少了。像email open，Open smash，主要是open smash，还有linked等，都是著名的微服治理，尤其是服务网格时代的微服治理的工具。也就是service的平台在service运行时的PPT。除此之外，编排平台去调度运行应用程序对其做出简单的平等则是Google net的功能和任务对应的微服务治理通常还能够支持相对应服务的回头发布的猎豹经济部署、A/B测试等等相关功能，所以原生系统大概就具有了刚才摸索或者一个对应的原系统。
根据这种架构模型拼接的话，拼接出来这些对应的各个解决方案，大体上就能实现具有类似特征的或类似描述特征的元素。于是采用云原生技术的组织或者公司所构建的云原生系统，大概从一个粗略的角度描述的话。有这样几个层级，首先底层基础设施很可能是私有云、公有云或者是混合云，而后在云环境的基础之上，应该添加和部署一个对应的容器编排平台，就是copper。如果需要到无服务计算的话，还需要额外提供一个SaaS的平台，就是sunlight接着在该平台之上，就可以提供类似于叫做容器及服务的这么一个接口，叫CS接口。再接着向上，应该去提部署和提供一个微服务，运行平台，那就是服务网格系统，去运行自己的各种各样的以微服务形式存在的业务单元，这些单元甚至包括底层平台自身都应该纳入监控系统来，如果没有监控，几乎就没办法管理。所以立体化监控系统、包括日志、指标监控、还有对应的分布式链路跟踪系统等所组成，这是现代银行系统几乎所必然要具备的几个监控组件。还有API网关刚收购API网关要实现API。
统一的流量管理，尤其是接入外部系统时的流量管理，它包括API治理、流量控制等相关功能。很显然，对这么多的微服务应用，必要时应该体现到它，叫做认证对应的访问国有服务技术，还有它能够支持的项目对应服务，一般往新部署A/B层是在线上层的，其实就是开发认证，所以云联上新改成具有高效摸索，而一个对应的云联系统，如果要做金融高层架构模型系统拼接的话。
3、云原生架构体系的参考实例
在公有云、私有云之上，发布渠道应该有一个Kubernetes垫片，然后在此基础之上，提供一个微服务的基础，通常它是一个service mash，在这个service max的基础之上，应该从开发框架，提供各种各样的中介，确保各个微服务之间的正常的发现等出发。要提供的监控系统，确保每一个服务都要纳入到监控体系中来，现在各种各样的网络管理功能，为了确保高效的去交付每一个微服务应用，还应该遵循这个所谓的甚至是get UPS这样的模型来实现应用的啊。事实上在新功能上，当然接入外部的访问流量时，应该有一个服务的统一接入接口。
4、云原生的技术范畴
总的来说云原生的技术范畴，大体可以归类为六个方面，第一个是云应用与定义与开发流程，第二个是云原生底层技术，第三个云应用编排与管理，第四个云原生工具集，第五个监控与可观测线。
而这个就是我们的service，这其中包含了比如应用的定义，还有镜像制作，CSD。伯希和流式数据，还有数据库底层运行和容器运行时，是存储技术，云原生存储技术，接着原生的编排与管理，这里主要是cool max和surface max就是Excel等相关组件的功能工具及这里大家应该容易理解这个描述监控系统就是个例，调监控系统，这就是云原生体系应该具有的技术范畴。
5、如何建构云原生
有鉴于此，只要遵循前面的范式，把对应系统组合起来，基本上就能够构建出一个云原生的基础平台了。在这个云生的这个平台当中，它的每一层各有各的作用，比如总结一下我们微服务架构，就是解决单体架构导致。
5.1如何设计和使用云原生架构
应用云原生构架是有应用复杂性问题的，但是它拆分成微服务以后，这个复杂性就留给了外部的治理系统，而并不是真正的减少了这个服务的复杂，或者降低了服务的复杂性。另外，服务治理框架和立体化监控方案能够解决服务间协同基调异常的情况，问题那些，那很显然立体化监控方案，在这个监控时代依然是需要的，虽然这个图当中画的是传统的应用中有了第二层。但事实上，监控系统对云原生体系来讲更是重中之重的组件，那个借助于应用应用技术，容器技术解决应用构建、分发和部署等相关的问题。
容器在某种程度上原生环境中扮演着不可变基础设施的角色，K8S用于编排、调度和弹性，Service用于解决微服务框架的侵入式和流量治理等功能。Switch运行于K8S之上，还可以提供更好的容器底层环境支持。借助于ras云和容器技术，可以进一步解决不可变基础设施的相关问题，这就是如何是和使用云原生架构。
二、CNCF的云原生项目
1、在CNCF主导下的为主流的、现在的云原生生态当中的相关项目有很多，这其中可能最为重要的就包括了前面所提到的如果想真正的完整的构建出一个云原生的技术平台所需的组件或直接或间接使用的云原生的相关项目是远远不止这么几个的。
2、Maturity levels
上面的这幅图其实就是由CNCF主导原生态技术或者项目全景图可以看CNCF网站。想要获取这个原生态图，那么这个对应的生态实景当中组合的项目大体可以被编排为：事关应用开发、事关编排与管理、事关运行时、与平台的监控与分析的service，以及CSD等相关这几个大类。这每一项都可以点开放大进行详细观看。除此之外，这种平台的那个项目更多的是对应的托管服务，或者是安装服务等相关。
3、毕业的项目
以上是已经毕业的项目，比较典型的代表：第一个就是著名的containerd。事实上的S支持的最为标准的底层的容器运行环境，被称作CoroDNS，默认所对接的一个容器运行时环境，CoroDNS他是个原生的DNS服务，是对英语S之上的各类服务的总线，用于帮助CoroDNS完成服务的注册服务，发现名称解析等功能，因为这是Excel的数据平面。Excel的数据平面是个KV存储一个KV存储系统，它身上也是K8S SAPS SERVER会将k server提a server的所有数据存储的真正或者存储的真正位置，从而appstore只是一个无状态的HTTP服务或者应用服务器，所有数据都委托给高一致性的分布式的键值存储系统。这个fluentd的这个著名的运费系统跟立体化监控有关，这是容器注册表或者镜像，注册表儿在容器中当中是一个非常关键。还有这是应用大包组建接着立体化监控系统的分布式追踪组K8S,顾名思义这是开放策略引擎，事实上是在K8S之上，应该至少说可以被用作cortex之上，这是基于属性的防控系统中一个开放的教育开源的开放的策略引擎，能够帮助用户去制定安全策略的。Promietheus监控系统，这是指标监控，这是分布式链路追踪，这是日志采集系统好基于CNCF等存储系统的原生的存储系统，分布式存储系统half这个升级框架，然后Vitess再造。这是国人所研发的一款分布式的分布式KV存储系统，它也是TDB的机子。基础设施Vitess应该是个Mexico的啊，原生的这个水平扩展框架，为这事已经毕业的几个重点项目，那么florence的日志系统要用到，特别是指标监控用到，那么容器注册表私有的通常也要用到，Erhelm则是用我们在CT上简单部署就简单管理应用的一个非常重要的组件。所以在将来要学习和使用云原生技术，这里已经毕业的项目几乎绝大多数人都用到。
4、孵化中的项目
几乎很多孵化中的项目，已经有不少公司在在采用了。比较关键的组建：比如像CONTOUR，即便不能把它称为叫API Gatewag的解决方案，但它实际上也是K8S上一个非常重要的组件，叫做in gress control的实现。cortex叫做容器网络接口的规范。CNI全称叫Container Network Interface（容器网络接口），其目标是为容器创建基于插件的通用网络解决方案。CNI的说明在规范中定义了。CRI-O这是一个类似于container d的容器运行时CRI的解决方案。dragonfly这是阿里所维护的一个容器镜像服务，它的功能有点容器注册表，叫镜像注册表服务可能更好一点。
flagger是一个k8s operator,可以基于多种ingress 实现金丝雀升级，以进行流量转移,并使用Prometheus指标进行流量分析。canary分析器可以通过webhooks进行扩展，以运行系统集成/验收测试，负载测试或任何其他自定义验证。
Flagger实现了一个控制环路，该环路逐渐将流量转移到金丝雀，同时测量关键性能指标，例如HTTP请求成功率，请求平均持续时间和Pod运行状况。 基于对KPI的分析，金丝雀会被提升或中止。
5：沙箱中的项目
●项目很多，列举几个由阿里云贡献的代表产品
◆OAM/KubeVela-开放架构模型及其在K8s上的完整实现OAM/KubeVela
◆OpenYurt--业界首个“非侵入式”式的边缘云原生项目OpenYurt
◆OpenKruise--云原生应用自动化引擎
◆Fluid-云原生环境下的数据密集型应用的高效支撑平台
三、云原生平台DIY
1、如果想自己动手DIY一个云原生平台的话，大体上要用到的组件或者列出来一部分。如果要附加监控体系还要分别在每一个方向当中各自选择一个组件。
2、基于Kibernetes的Paas示例框架
这些公有云服务商一定会体贴的把现在技术趋势下所需要用到的各种需求，帮我们提供一个一整套的需求。
例：阿里云云原生平台产品
阿里云云原生平台分别提供了各自的结局方案，比如阿里云云原生DevOps工具链是曾经荣获信通院研发运营解决方案分级能力的最高认证。目前有一百万的企业开发者、十万➕以上的企业用户，在使用该服务。
阿里云容器的服务产品，这里有阿里云托管的Kibernetes服务，有阿里云托管的服务叫ACK。阿里云对应的还提供了ASK服务也就是serverless，除此之外还提供了服务网格，也就是阿里云服务网格解决方案。
四、云原生未来的架构趋势
1、未来的架构趋势
●通过把所有传统中间件（例如ESB）的功能移到其他运行时组件，未来的云原生模型实现了如图的整个功能环，不久之后，人们在服务中唯一要做的就是编写业务逻辑
对于云原生未来的体系当中的这些功能当中生命周期管理交给了底层的容器编排平台Kibernetes，对应的网络管理，服务治理交给服务网格系统，对于绑定和网络管理的另外一部分（无服务器计算）可以交给Knative，而对于状态管理、稳定等需求，可以交给dapr或者cloud state等组件，这样一来再去开发任何云原生运用程序时，完全可以将经历只集中在Business logic之上。但是现在很多公司所使用的云原生（K8S）环境本身只提供了K8S和建构在Kibernetes之上的基础设施，比如：消息队列、数据库等。
2、未来的架构趋势
●因而可以把不同领域进行创新的各种云原生项目进行叠加
◆Kibernetes：基于现代应用容器技术在多语言应用程序的生命周期管理
◆服务网站：在Kibernetes之上实现了高级网络功能
◆Knative：专注于Serverless型的工作负载，同时满足了服务编排和事件驱动的绑定需求
◆Dapr:建立在Kibernetes Knative和服务风格的思想之上，深入应用程序运行时以解决有状态工作负载：绑定和集成的需求，从而充当现代化分布式中间件；
五、云原生人才培养计划系列课程简介
第一阶段Kubernetes课程大纲
●最容器技术基础
●Kubernetes系统核心概念及工作模型
●使用kubeadm部署集群微
●API资源模型及Pod基础
●Pod使用进阶:资源需求、资源限制、多容器Pod
●存储卷
●使用ConfigMap和Secret配置Pod应用●服务发现与Service资源
●应用编排之ReplicaSet和Deployment
●应用编排之DaemonSet、Job和CronJob
●应用编排之StatefulSet
●综合应用案例
