云计算原理-课件 第4章　云应用

《云计算原理》大型的云应用云应用-Netflix1.用户端：用户通过互联网访问Netflix的服务。2.AWS云：Netflix的云端基础设施托管在AWS上。其主要由以下几个部分组成：VPC、EC2、RDS。3.数据流过程：用户通过互联网连接到Netflix的AWS服务器。用户的请求被分配到不同的EC2实例，EC2实例与RDS数据库交互，查询用户账户信息和内容目录。云应用-云端人脸识别访客或员工通过前端应用程序上传照片，前端与AWSAPIGateway进行交互，调用人脸识别功能，如果访客照片与员工照片匹配成功，系统即可识别访客身份；否则将作为新访客，处理后将访客的照片上传到另一个S3桶中，或存入数据库内。一、创建Bucket输入Bucket名称，选择AWS的可用区，或从现有Bucket中复制一份设置来创建新的Bucket二、配置Lambda选择使用情况为Lambda，服务选择AWSservice。三、创建角色输入角色名称和描述，根据站内提示的步骤完成角色创建。四、创建函数输入函数名称，运行时环境，此处运行时环境可选Python3.7，架构为x8664位，授权之后完成函数的创建。五、编写业务代码编写客户端与云端交互的代码，以及lambda函数处理逻辑等必要的内容。六、配置policy策略选择S3允许的操作，对写入操作来说就是PutObject操作，之后填写policy的详细信息。《云计算原理》王

鹏AWSVPC的基本用法微服务是什么微服务是一种软件架构风格，强调将应用程序拆分为多个小的、独立的服务，每个服务可以独立开发、部署和扩展。每个微服务通常围绕特定的业务功能或领域构建，具备独立的业务逻辑、数据库和服务接口。方式一：通过API调用进行通信。每个微服务都定义了一组公开的API接口，这些接口描述了该服务提供的功能和可用的操作。微服务通过发送HTTP请求与其他服务进行通信。这种通信方式通常是同步的，即调用服务会等待请求的响应。微服务的通信方式方式二:通过消息代理进行通信发布/订阅模式：消息的发布者将消息发送到一个主题，所有订阅了该主题的消费者（即其他微服务）都会接收到消息。点对点消息传递：消息发送到一个队列，每个消息只能被一个消费者接收和处理。微服务的通信方式微服务的通信方式方式三：通过服务网格进行通信服务网格是一个基础设施层，专门用于处理微服务之间的通信。它通过代理来管理。每个微服务实例旁边都会运行一个代理，它负责处理所有进入和离开该微服务的网络流量。由于微服务应用是一个分布式系统，增加了复杂性。需要配置服务之间的通信。在多个服务器上分布的每个服务实例使监控变得更加困难。微服务架构的缺点微服务的CI/CD（持续集成/持续部署）管道是一个自动化工作流程，允许开发人员频繁集成代码更改并快速可靠地部署应用程序。微服务CI/CD管道的主要阶段包括源代码管理、持续集成、容器化、持续部署、监控与反馈。微服务架构的CI/CD微服务的CI/CD（持续集成/持续部署）管道是一个自动化工作流程，允许开发人员频繁集成代码更改并快速可靠地部署应用程序。微服务CI/CD管道的主要阶段包括源代码管理、持续集成、容器化、持续部署、监控与反馈。微服务架构的CI/CD《云计算原理》王

鹏DevOps实践DevOps是一种软件开发和运维的文化和实践，旨在通过促进开发与运维团队之间的协作和沟通，缩短软件开发生命周期，提高软件交付的质量和频率其核心理念是打破传统上开发和运维之间的壁垒，使团队能够更快速、更频繁地发布软件，同时减少错误和故障的发生。DevOps持续开发

ContinuousDevelopment持续开发强调在软件开发生命周期中实现更快、更频繁的代码提交和集成Git是一种分布式版本控制系统，在持续开发中提供强大的版本控制、协作支持和自动化集成，极大地提升了开发团队的工作效率和代码质量，使得软件的迭代速度更快、响应能力更强。持续集成

ContinuousIntegration通过频繁地将代码集成到共享的代码库中，来提高软件开发的效率和质量。强调自动化测试和构建过程，确保每次代码更改都能够被及时验证和集成。持续测试

ContinuousTesting持续测试在整个软件开发生命周期中不断执行测试，以确保软件的质量和可靠性。它是DevOps和持续交付流程的重要组成部分，具有自动化、快速反馈、覆盖范围广等特点持续部署

ContinuousDeployment在持续集成的基础上，进一步自动化软件的发布过程。其包括以下步骤：代码提交自动构建自动测试自动部署监控与反馈持续监控

ContinuousMonitoring持续监控是DevOps和持续交付流程中的一个关键组成部分。通过持续监控，团队能够及时发现并响应潜在问题，从而确保软件在生产环境中的稳定性和可靠性。持续监控其包括性能监控、可用性监控、日志管理等。《云计算原理》王

鹏SRE实践为什么需要SRE?DevOps并没有达到理想中的稳定性，部分原因在于DevOps原则的实施中缺乏专门的角色或人员专注于系统的可靠性。SRE的出现填补这一空白，确保团队能够更有效地管理和维护系统的可靠性。通过将可靠性作为一个重点，SRE能够帮助DevOps团队在快速迭代的同时，确保系统的稳定性和用户体验。SRE团队SRE团队由软件工程师组成。专注于构建和实施软件解决方案，以提高系统和服务的可靠性。不仅负责开发自动化工具和监控系统，还参与故障响应和容量规划。他们通过编写可复用的代码和设计高效的流程，优化运维操作，从而确保服务在高负载和变化环境中的稳定性。SRE团队的目标是将软件工程的最佳实践应用于运维管理，以实现更高的可用性和更好的用户体验。服务水平协议SLA（服务水平协议，ServiceLevelAgreement）是一种正式的协议。定义了服务提供者与客户之间的期望和责任。SLA详细列出了服务的性质、质量和可用性标准，以及在未能满足这些标准时的补救措施。确保系统可靠性的努力一旦定义了SLA，就需要更多的努力来保证系统的可靠性。如果系统的可靠性低于SLA规定的标准，SRE团队将投入额外资源，致力于将系统恢复到正常状态。这意味着在超出允许的停机时间后，团队将采取一系列措施，以确保服务能够达到承诺的可用性和性能，从而维护用户信任和业务连续性。优越性能与SLA的灵活性如果系统的性能远远超出定义的SLA，那么在SLA范围内的可接受变更将相对较少。这种情况下，SRE团队中的开发人员可以更加灵活地发布新功能或进行改进，因为系统的高可靠性和稳定性为他们提供了更多的操作空间。SRE的任务和职责自动化运维任务：通过编写代码和开发工具来自动化日常运维工作，减少手动操作，提高效率和一致性。SRE的任务和职责配置监控、日志记录和报警（可观察性用于检测问题）实施全面的监控，实时收集性能数据，并设置报警规则以便及时响应问题。SRE和Developers协同两个团队共同致力于将系统保持在定义的SLA范围内。SRE团队专注于维护和负责自动交付操作，通过各种自动化工具和流程，帮助开发人员安全、快速地发布他们的更改。确保了系统的稳定性和高效性，使开发团队能够在保证可靠性的前提下，不断推动创新和改进，从而实现业务