分布式计算、云计算与大数据 第2版 课件 第7章 云原生技术

第7章云原生技术提纲7.1 云原生的概念与架构7.2 云原生关键技术7.3 云原生应用开发7.4 云原生技术特色云原生的概念云原生计算基金会（CloudNativeComputingFoundation，CNCF）组织对云原生的定义是：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。代表技术：容器、服务网格、微服务、不可变基础设施和声明式API。云原生本质上是一种基于云的软件架构思想，以及基于云进行软件开发实践的一组方法论。通过学习云原生的应用架构设计理念和云原生包含的各种适用于云环境、发挥云端优势的技术，使个人或企业能够顺利地在云端环境进行应用设计、开发和运维。云原生的架构云原生架构有4个要点，即微服务、容器、DevOps、持续交付云原生的架构微服务：微服务是将应用作为小型服务集合开发的架构方法，其中每个服务都可以实施业务功能，每个微服务都可以独立于应用中的其他服务进行部署、升级、扩展和重新启动。容器：容器技术是云原生概念兴起的基础，与标准虚拟机相比，容器体积小、速度快。DevOps：通过自动化工具协作和沟通，让开发、测试和运维之间能够模糊边界，从而更快、更频繁地交付更稳定的软件。持续交付：在不影响用户使用服务的前提下频繁把新功能发布给用户使用。提纲7.1 云原生的概念与架构7.2 云原生关键技术7.3 云原生应用开发7.4 云原生技术特色微服务定义微服务（microservice）是一种软件架构风格，它以专注于单一责任与功能的小型功能区块（smallbuildingblock）为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的API集相互通信。特点采用模块化的设计风格，更加适合大型应用开发可以将模块化的服务跨多个服务器和基础设施进行部署，充分满足自身业务需求，具有高度的可扩展性

拥有出色的弹性，只要确保正确构建，这些独立的服务就不会彼此影响典型开发框架比较著名的有SpringCloud、Dubbo和Dropwizard等目前最为流行的开发框架为SpringCloudSpringCloudSpringCloud服务发现—SpringCloudNetflixEurekaEureka由EurekaServer和EurekaClient组成EurekaServer提供服务注册服务，各个EurekaClient启动后，会在EurekaServer中进行注册EurekaServer本身也是一个服务，默认情况下会自动注册到注册中心EurekaServer之间可以相互注册，组成高可用的注册中心来提高系统的稳定性。当一个服务注册至注册中心后，相当于在集群中发现了该服务，这样当服务消费者需要通过远程调用获取这个服务的内容时，就可以通过注册中心找到该服务。SpringCloud客户端负载均衡—SpringCloudNetflixRibbon在微服务架构中，一个服务可能会被部署多份以提高服务的可用性，当多个相同服务的提供者被注册至注册中心后，注册中心会注册该服务的所有提供者，当服务消费者需要调用该服务时，注册中心会查询所有可用的服务提供者，这时可以通过Ribbon基于负载均衡算法做到负载均衡地请求其中一个服务提供者实例。Ribbon（负载均衡器）的作用正是提供负载均衡机制，当为Ribbon配置服务提供者地址列表后，Ribbon就可以基于某种负载均衡算法，自动帮助服务消费者处理请求。Ribbon提供的负载均衡算法有多种，例如轮询、加权响应时间、随机和区域感知轮询。SpringCloud断路器—SpringCloudNetflixHystrix断路器能够统计一段时间内调用失败的次数，并决定是正常请求依赖的服务还是直接返回。当对特定服务的调用的不可用达到一个阈值（Hystrix是5秒20次）时，断路器将会被打开。断路器被打开后，可以避免连锁故障，fallback方法直接返回一个固定值SpringCloud服务消费者—SpringCloudOpenFeignFeign是一种声明式、模板化的HTTP客户端，主要作为服务消费者用于调用其他服务。Feign大大简化了服务调用客户端的开发量，通过简单的注解就能完成对服务提供方的接口绑定。Feign整合了Ribbon，所以能够做到负载均衡地调用服务。Feign也整合了Hystrix，所以具有断路器的功能，当服务调用失败后，会返回预先设定的fallback函数的值。SpringCloud服务网关—SpringCloudNetflixZuul当一个请求到达系统后，应该最先到达网关，由网关进行统一鉴权等操作后再将请求转发至各个具体的服务。Zuul的主要功能是路由转发和过滤器。Zuul默认和Ribbon结合实现了负载均衡的功能。分布式配置—SpringCloudConfig动态拉取远程数据仓库的配置文件，并把配置文件应用至对应的微服务中容器概念：容器是一种允许在资源隔离的过程中运行应用程序和其依赖项的、轻量的、操作系统级别的虚拟化技术，运行应用程序所需的所有必要组件都被打包为单个镜像，该镜像是可以重复使用的。当镜像运行时，它运行在独立的环境中，并不会和其他的应用共享主机操作系统的内存、CPU或磁盘。容器特点：容器实现的是操作系统级虚拟化，具有轻量级的特点，与虚拟机相比较，容器性能更好，一般能做到秒级启动。容器没有自己的OS，直接共享宿主机的内核，也没有管理程序（hypervisor）这一层进行资源隔离和限制，所有对于容器进程的限制都是基于操作系统本身的能力来进行的。容器在版本控制、计算环境可移植性和标准化方面也有很多优点。容器Docker容器技术：用于研发、测试、交付和运行软件应用的容器引擎。容器Docker使用户可以在容器中封装和运行软件应用。高资源利用率与隔离性使我们可以在同一时间、同一服务器上运行多个容器。容器轻量的特性使它们可以在系统内核中直接运行，而不需要对应用的额外负载进行管理。Kubernetes概念：Kubernetes是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。功能服务发现和负载均衡存储编排自动部署和回滚自动完成装箱计算自我修复密钥与配置管理特性不限制支持的应用程序类型不部署源代码，也不构建应用程序不提供应用程序级别的服务作为内置服务不要求日志记录、监视或警报解决方案不提供或不要求配置语言/系统不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。Kubernetes架构主从分布式结构，其节点在角色上分为Master节点和Node节点最小部署单元：

PodMaster组件：APIServeretcdControllerManagerSchedulerNode组件：KubeletProxy容器运行时服务网格概念服务网格是一个专门处理服务通信的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。架构服务网格的基础设施层主要分为两部分：控制平面与数据平面。每个服务实例都与一个反向代理服务器实例配对特点微服务治理与业务逻辑解耦可以实现异构系统的统一治理一定的可观察性和流量控制提供了保护网络调用的功能和基础设施提纲7.1 云原生的概念与架构7.2 云原生关键技术7.3 云原生应用开发7.4 云原生技术特色实例概述云原生应用开发实例——线上考试系统业务：集题库、组卷、发布、考试、评卷、系统考试报告业务闭环的考试平台设计：使用SaaS模式基于SpringCloud的微服务技术构建。在数据的设计模式上为每一个租户新建独立的Schema或者Database共享数据库实例，因为考试服务为互联网应用，所以选择SpringCloud微服务技术为项目基础支撑技术，同时使用Kubernetes容器编排系统进行考试系统的部署和运维。考试系统主要分为基础数据服务、系统管理、试卷中心、考试中心四个模块系统设计系统架构设计

采用分布式体系架构设计，前端由Nginx服务器反向代理，访问网关，由网关将请求分发给对应微服务，服务与服务之间通过Feign进行数据接口的调用，服务均被注册至Eureka中，将SpringCloud微服务使用Kubernetes进行容器化部署。系统设计功能模块划分

系统设计基础框架设计：主要分为以下5个部分es-util：工具类es-log：统一异常处理切面、错误码，统一日志收集切面es-core：Entity、DTO、Controller等Base类、请求应答报文类、封装公共字段注解自动注入功能切面es-cache-redis：RedisAPI封装、Redis分布式锁es-config：集成Swagger，便于查看API发布系统设计功能模块详细设计

以系统管理微服务为例，系统管理微服务主要包括组织机构管理模块、公司管理模块、部门管理模块、资源管理模块、职位管理模块、用户管理模块、角色管理模块、参数管理模块、用户在线管理模块和登录模块。系统管理微服务的设计主要包括以下几个方面：各个层级POJO的Base类设计Controller的Base类设计持久层框架的设计错误码的设计API的设计系统设计动态模型设计

动态模型用于描述系统的过程和行为，通常使用时序图、流程图、状态图和活动图等描述系统的动态模型，可以将需求设计明确化、可视化。通过动态模型的评估，可以及时发现系统中设计的缺陷，避免不必要的损失。下图为系统管理微服务中的功能流程图（右图接下）系统设计动态模型设计

系统网关的工作时序图系统实现系统实现流程首先在本地和服务器上配置好所需要的环境，搭建公用代码仓库，进行SpringCloudConfig配置，以便分布式部署同步配置文件根据所设计的E-R图构建相应的数据库和表，规范好每个字段对应的属性和主外键约束，并录入一些示例数据每位工程师开发各自负责的基础框架，并把它们集成为基础框架es-common进行第一次集成开发，每位工程师开发自己负责的部分，开发完成后进行第一次集成测试进行第二次集成开发，每位组员开发各自负责的部分，开发完成后进行第二次集成测试。开发模式按照第一次集成开发的模式前端开发最终集成测试各个模块功能，修复Bug将本地部署的服务迁到云服务器，使用Kubernetes进行编排管理系统实现开发可能需要的软件系统实现开发可能需要的插件系统实现后端服务的开发编写所需功能的API编写该功能模块对应的ExceptionCode枚举类，在Service层抛出Service异常，在Controller层抛出Business异常编写该功能所涉及的DTO、VO、Query、QueryVO等POJO编写Service接口与对应的实现类，实现类主要使用所配置的Tk.MyBatis通用Mapper实现，无须XML配置的单表增删改查操作编写Controller对API进行实现在Controller中使用Service进行服务调用，并进行一些数据验证，不符合则抛出异常Controller的方法中需要对入参进行参数验证、以保证进入方法中参数的合法性系统实现前端的实现

项目采用了微服务的后端架构开发，服务间均采用API通信，因此可以很容易做到前后端分离，前端开发技术的选择不限。SpringCloud的使用实例服务注册和发现——创建服务注册中心（EurekaServer）创建一个Maven工程，并在pom文件中引入SpringCloudEurekaServer相关依赖EurekaServer的配置文件application.yml如右图所示启动一个服务注册中心，只需要一个注解@EnableEurekaServer，需要在Springboot工程的启动Application类上加该注解SpringCloud的使用实例服务注册和发现——创建服务提供者（EurekaClient）创建一个Maven工程，并在pom文件中引入SpringCloudEurekaClient相关依赖通过注解@EnableEurekaClient表明自己是一个EurekaClient。在配置文件中注明自己的服务注册中心的地址，application.yml配置文件如下：启动工程，打开http://localhost:8761，即EurekaServer的网址，就可以看到注册中心SpringCloud的使用实例服务消费者（Feign）新建一个Maven工程，并在pom文件中引入Feign的起步依赖spring-cloud-starter-feign、Eureka的起步依赖spring-cloud-starter-netflix-eureka-client和其他相关依赖。在程序的启动类ServiceFeignApplication，加上@EnableFeignClients注解，开启Feign的功能：SpringCloud的使用实例服务消费者（Feign）定义一个Feign接口，通过@FeignClient（“服务名”）来指定调用哪个服务。比如在代码中调用了service-hi服务的“/hi”接口，代码如下之后就可以通过SpringCloud的自动注入注解@Autowired对其他微服务进行调用，Feign会负责调用，并自动实现负载均衡SpringCloud的使用实例断路器（Hystrix）在配置文件中加入以下代码SchedualServiceHiHystric需要实现SchedualServiceHi接口，并将其注入IoC容器中，代码如下要开启Feign，只需在@Feign注解中加上fallback的指定类SpringCloud的使用实例路由网关——创建Zuul网关新建一个Maven工程，在pom文件中引入Zuul所需的spring-cloud-starter-netflixzuul、spring-cloud-starter-netflix-eureka-client和其他相关依赖。配置文件application.yml如左示代码在其入口Application类中加上注解@EnableZuulProxy，开启Zuul的功能：SpringCloud的使用实例路由网关——服务过滤Zuul不仅是路由，还能过滤，做一些安全验证。下面的代码展示了Zuul的鉴权功能：使用了JWT进行Token生成，在header中携带对应的Token和userId的请求才允许访问。SpringCloud的使用实例分布式配置中心（SpringCloudConfig）——构建配置服务器创建一个Maven工程，引入配置服务器所需的spring-cloud-config-server和其他相关依赖。在程序的入口Application类加上@EnableConfigServer注解，开启配置服务器的功能，代码如下SpringCloud的使用实例分布式配置中心（SpringCloudConfig）——构建配置服务器在程序的配置文件perties中做以下配置SpringCloud的使用实例分布式配置中心（SpringCloudConfig）——构建配置客户端创建Maven项目，引入spring-cloud-starter-config和其他相关依赖。其配置文件bootstrap.properties如下：程序的入口类，写一个API接口“／hi”，返回从配置中心读取的foo变量的值，代码如下：持续集成与部署使用的技术统一的代码仓库在GitHub、Gitee、GitLab等公有或私有的代码仓库平台上构建一个Project作为项目的统一代码仓库使用Jenkins持续集成Jenkins可以结合Git版本控制工具和GitHub等云远程代码仓库使用，并选择Maven作为项目构建工具。持续集成与部署将SpringCloud微服务封装为Docker镜像创建SpringCloud微服务对应的Dockerfile文件。这里使用7.3.4节中的service-hi服务提供者，具体如下：使用命令dockerbuild-tservice-hi:v0.0.1构建Docker镜像。使用命令dockerrun--nameservice-hi-d-p8762:8762service-hi:v0.0.1，运行构建好的微服务镜像，并将宿主机的8762端口映射到容器的8762端口。在Eureka注册中心中查看注册项，注册上后表示镜像能够正常使用。持续集成与部署使用Kubernetes中的Deployment部署高可用微服务Pod：Pod是可以在Kubernetes中创建和管理的、可部署的最小计算单元。Pod可以由一个甚至是一组共享相同运行环境的容器组成。执行以下命令可以创建Pod：持续集成与部署使用Kubernetes中的Deployment部署高可用微服务Service：Kubernetes的Service资源为一组提供相同功能服务的Pod充当入口执行以下命令创建该Service，把服务和8762端口暴露出来：持续集成与部署使用Kubernetes中的Deployment部署高可用微服务Deployment：Deployment可以创建指定数量的Pod并将其部署到各个Node上，可完成更新、回滚等操作。使用以下命令创建Deployment：持续集成与部署零停机时间滚动部署编辑service-hi-deployment.yaml文件，修改容器镜像来引用新的镜像service-hi:v0.0.2，保存并执行以下命令：可以使用以下命令检查滚动部署的状态：持续集成与部署回滚如果当前版本有问题，则需要回滚至前一个版本。执行以下命令：

返回：再执行：

返回：提纲7.1 云原生的概念与架构7.2 云原生关键技术7.3 云原生应用开发7.4 云原生技术特色云原生应用的12要素目的：为构建如下的软件即服务（SaaS）应用提供方法论使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。尽可能和操作系统划清界限，在各个系统中提供最大的可移植性。适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。将开发环境和生产环境之间的差异降至最低，并使用持续交付实施敏捷开发。可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。12要素（12-Factor）应用是一系列云原生应用架构的模式集合，用来说明什么样的应用才是云原生应用，它们关注速度、安全、通过声明式配置扩展、可横向扩展的无状态/无共享进程以及部署环境的整体松耦合云原生应用的12要素1.基准代码“一份基准代码”是指基准代码和应用之间总是保持一一对应的关系。一旦有多个基准代码，则不是一个应用，而是一个分布式系统。多个应用共享一份基准代码有悖于12-Factor原则。解决方法是将共享的代码拆成独立的类库，通过依赖管理去使用它们。多份部署”是指每个应用只对应一份基准代码，但可以同时存在多份部署，每份部署相当于运行一个应用的实例。区别在于：可以存在不同的配置文件对应不同的环境，例如开发环境、测试环境、预发布环境、生产环境等。可以使用不同的版本。云原生应用的12要素2.依赖12-Factor原则下的应用会通过依赖清单来显式确切地声明所有的依赖项。在运行工程中通过依赖隔离工具来保证应用不会去调用系统中存在但依赖清单中未声明的依赖项。显式声明依赖项的优点在于可以简化环境配置流程，开发者关注应用的基准代码，而依赖库则由依赖库管理工具来管理和配置。3.配置12-Factor原则要求代码和配置严格分离，配置单独存储，避免将配置硬编码写在代码中。12-Factor原则建议将应用的配置存储在环境变量中，环境变量可以方便在不同的部署环境中修改，而不侵入原有的代码。环境变量的粒度要足够小且相对独立。云原生应用的12要素4.后端服务对于12-Factor应用来说，后端服务都是附加资源，没有区别对待，当其中一份后端服务失效后，可以切换到原先备份的后端服务中，而不需要修改代码（可能需要修改配置）。12-Factor应用与后端服务保持松耦合的关系。5.构建、发布、运行12-Factor应用严格区分构建、发布、运行三个步骤，每一个发布版本对应一个唯一的发布ID，可以使用时间戳或递增的版本序列号。部署新代码之前，由开发人员触发构建操作，构建阶段可以相对复杂一些，方便错误信息被展示出来并得到妥善处理。运行阶段可以人为触发或自动运行，运行阶段应该保持尽可能少的模块。云原生应用的12要素6.进程12-Factor应用的进程必须是无状态且无共享的，任何需要持久化的数据都要存储在后端服务中。12-Factor应用更倾向于在构建步骤执行二进制文件的编译，而不是在运行阶段。7.端口绑定应用通过端口绑定提供服务，并监听发送至该端口的请求。8.并发12-Factor应用的进程具有无共享、水平分区的特性，使得水平扩展较为容易。12-Factor应用的进程不需要守护进程或者写入PID文件，而是通过进程管理器（例如systemd）来管理输出流、响应崩溃的进程，以及处理用户触发的重启或者关闭超级进程的操作。云原生应用的12要素9.易处理12-Factor应用的进程是易处理的，即它们可以快速地启动和停止，这样有利于快速部署和弹性伸缩实例。12-Factor应用都应该设计能够应对意外的、不优雅的退出。10.开发环境与线上环境等价12-Factor应用想要做到持续部署就必须缩小本地与线上的差异。11.日志12-Factor应用本身不考虑存储自己的日志输出流，不去写或者管理日志文件，而是通过标准输出（stdout）的方式实现。12.管理进程将管理任务当作一次性进程来运行。一次性管理进程应该和正常的常驻进程使用相同的运行环境。云原生应用与传统应用的差别云原生应用则要比传统应用更多考虑功能性需求以外的非功能性需求如何将业务拆分为一个个微服务、每个微服务需要实现的业务逻辑是什么、如何设计每个微服务的接口、如何降低微服务间的耦合等都是在云原生应用需求设计阶段需要回答的问题。微服务架构还带来许多应用运营上的需求，如隔离故障、容错、自动恢复、弹性扩缩容、高可用性、分布式一致性、跨云部署等，这些都不能直接使用传统应用的解决方案而是需要重新为云原生应用进行设计的需求。在软件生命周期中，开销最大的阶段就是软件应用的运维阶段，云原生应用的这些需求设计是让应用能够安全、