Pivotal云原生和PaaS平台C课件.pptx
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《Pivotal云原生和PaaS平台C课件.pptx》由用户(晟晟文业)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Pivotal 原生 PaaS 平台 课件
- 资源描述:
-
1、 Copyright 2013 Pivotal.All rights reserved.Copyright 2013 Pivotal.All rights reserved.PaaS时代云平台建设和应用云化之路 Copyright 2013 Pivotal.All rights reserved.目录 云原生应用架构和原理 PaaS的理论基础 PaaS的架构模型 PaaS的业务价值 Pivotal的PaaS架构和实践 Pivotal Spring微服务框架 PAAS的生产案例Defining Cloud Native Cloud native is a term describing soft
2、ware designed to run and scale reliably and predictably on top of potentially unreliable cloud based infrastructure.概念澄清Cloud NativeCloud Native 包括两个方面1、Cloud Native Framework-应用框架,应用框架和设计本身适合运行在云上2、Cloud native Platform,部署和运行环境业界有些思路是应用运行在容器中就是Cloud Native,缺乏应用框架的支持。Copyright 2013 Pivotal.All right
3、s reserved.区别于传统应用-互联网应用的需求带来新技术-新技术带来运维全自动化需求是持续发展的是一个产品,持续发展用户访问量难以预测,而且一般是持续增长用户访问的并发量是万级、十万、百万在线业务,业务不能停顿,互联网应用24小时服务,任何时候中断服务都是事故。传统应用特征互联网应用特征需求比较固定是个项目,完成以后就是运维用户访问量可以预测,较为固定用户访问的并发量在百级、千级非在线业务,允许一定时间的业务停顿(比如夜间停机),包括系统维护等,敏捷业务,敏捷开发持续集成应用平台的弹性支持海量并发业务不停顿,灰度发布,发布回滚,系统在线升级。互联网应用技术要求云原生应用架构云原生应用架
4、构云原生应用框架云原生应用平台 Copyright 2013 Pivotal.All rights reserved.传统巨石应用和云原生微服务应用的概念模型关系数据库数据访问服务/EJB/Java BeanHTMLJavaScriptMVC服务传统一体化架构的应用浏览器HTTPHTTPHTTPHTTPHTTPHTTPAMQPAMQP关系型数据库Key/Value数据库(NoSQL)图形数据库 Copyright 2013 Pivotal.All rights reserved.传统巨石应用的特征和面对的问题-难以运维全自动化 故障有可能发生 随时备份数据,用于服务恢复 不惜一切代价保证服务器
5、的运行 当服务器宕机时-摊上大事了 基础设施恢复 自动或者手动 应用恢复 手动 应用模块紧耦合 无法根据负载自动扩展 很难持续集成 应用聚合困难(ESB)应用升级麻烦端口变化负载增加配置变化环境依赖代码变化RTO/RPO云原生应用的特征 符合十二要素 微服务 自服务的敏捷基础设施 基于API的协作 Antifragility(反脆弱性)8原生云架构原生云架构应用框架应用运行时基础架构自动化引擎基础架构文化文化/角色角色开发人员开发人员运维人员运维人员运维人员支撑支撑Spring CloudSpring BootCloud FoundryBOSHAWSVMWareOpenStackAzure应用
6、云原生架构只有容器是不够的12 Factor AppBOSH ReleaseCloud Provider Interface9CNA架构需面对的难点分布式系统的复杂性远程调用多跨多个服务的应用功能设计依赖性管理/API版本化重构模块的边界无状态和有状态的分离(无状态改装不是必须的)10Source:“Microservice Prerequisites,”Martin Fowler,August 2014.采用CNA的必要基础 需要开发、测试、运行平台的支持 快速提供应用环境 通用的框架 基本的监控 快速应用部署 DevOps的支持11PAAS提供对CNA的支撑应用环境的自动化供应按需的/自动
7、化的弹性伸缩四重的故障自动恢复/自愈能力自动的路由/负载均衡数据服务的运维自动化基于平台的监控和基于应用的监控,二者的结合微服务的框架通用的应用服务(日志、APM、Session共享)目录Pivotal的业界大牛云原生应用架构和原理PaaS的理论基础PaaS的架构模型PaaS的业务价值Pivotal的PaaS架构和实践Pivotal Spring微服务框架PAAS的生产案例 Copyright 2013 Pivotal.All rights reserved.PaaS的业务驱动力和要解决的问题PaaS要解决要解决的问题的问题业务敏捷性业务敏捷性 业务敏捷 开发敏捷 部署敏捷 移动计算应用和系统
8、的应用和系统的可用性可用性 系统可用性 应用可用性运维运维自动化自动化 应用零运维 服务运维高度自动化 Copyright 2013 Pivotal.All rights reserved.p 通过十二要素来规范应用p 通过PaaS在平台层面支撑十二要素p应用需要即时弹性,而且需要运维的高度自动化(部署、故障恢复、自动扩容缩容),应用多是无状态,无状态即公牛机制,通过服务来实现有状态,p而服务不太需要即时弹性,服务更多是有状态,服务的运维自动化即时性要求不高,有状态就要去有备份、恢复等。p服务的运维需要各种工具,很多时候会需要人工介入,比如数据库调优、故障恢复,而应用的运维可以高度自动化、无需
9、人工介入,主要通过日志分析,服务更适合运行在虚机,而应用适合运行在容器中。p由于服务的有状态,不容易实现即时恢复,所以服务的可用性要求、资源独享性更高,共享OS内核不适合服务p 区分IaaS和PaaSp IaaS实现基础设施池化p PaaS实现应用相关的功能p 通过PaaS来驱动IaaS,实现运维自动化十二要素1区分应用和服务2区分IaaS和PaaS3PaaS三大理论基础 Copyright 2013 Pivotal.All rights reserved.PaaS的理论基础云原生应用的十二要素 1.基准代码:基准代码:一份基准代码,多份部署。基准代码和应用之间总是保持一一对应的关系。所有部署
10、的基准代码相同,但每份部署可以使用其不同的版本。2.依赖:显式声明依赖关系。应用程序一定通过依赖清单,确切地声明所有依赖项。3.配置:配置:在环境中存储配置。将应用的配置存储于环境变量中。环境变量可以非常方便地在不同的部署间做修改,却不动一行代码。4.后端服务后端服务:不区分本地和远端服务。不要把服务打包在应用中,通过绑定或是DNS寻址。5.构建,发布,运行:严格区分构建,发布,运行这三个步骤,不要再运行中去改配置。6.进程:进程:以一个或多个无状态进程运行应用。应用的进程必须无状态且无共享。7.端口绑定:端口绑定:通过端口绑定提供服务。应用完全自我加载而不依赖于任何网络服务器就可以创建一个面
11、向网络的服务。8.并发:并发:通过进程模型进行扩展,开发人员可以运用这个模型去设计应用架构,将不同的工作分配给不同的进程类型,每个进程均可以并发,可以弹性伸缩。9.易销毁性:易销毁性:快速启动和优雅终止可最大化健壮性。应用的进程是可销毁的,意思是说它们可以瞬间开启或停止。10.开发环境与线上环境等价:开发环境与线上环境等价:尽可能保持开发、预发布、线上环境相同。应用想要做到持续部署就必须缩小本地与线上差异。11.日志日志:把日志当作事件流。应用本身考虑存储自己的输出流。不应该试图去写或者管理日志文件。12.管理进程:基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布,从而避免同步
12、问题。Copyright 2013 Pivotal.All rights reserved.为发挥PaaS最大价值,传统应用架构转变为云原生应用遵循云原生架构原则开发的应用,适应于部署在PaaS云上的应用,能够充分发挥PaaS价值的应用就是云原生应用传统巨石应用云原生应用应用平台PaaS平台IT基础设施PaaS平台驱动的IaaS 微服务(开发相关)符合十二要素(开发/平台相关)Antifragility/反脆弱性(开发/平台相关)自服务的敏捷基础设施(平台相关)Copyright 2013 Pivotal.All rights reserved.云原生应用解决了哪些传统巨石应用的问题 很难根据
13、负载自动扩展很难根据负载自动扩展自动,水平扩展自动,水平扩展应用模块牵一发而动全身应用模块牵一发而动全身应用由多个微服务组成,松耦合应用由多个微服务组成,松耦合应用的恢复是靠人工的应用的恢复是靠人工的 应用的恢复是自动化的应用的恢复是自动化的 应用系统的物理环境错误导致业务停顿应用系统的物理环境错误导致业务停顿 应用的物理环境的出错是可以接受的应用的物理环境的出错是可以接受的不遗余力的保障物理机的运转不遗余力的保障物理机的运转 物理机对应用不是那么重要物理机对应用不是那么重要物理机的宕机是一件特大事故!物理机的宕机是一件特大事故!没什么大惊小怪的!没什么大惊小怪的!积极备份数据以便应用环境出错
14、时恢复积极备份数据以便应用环境出错时恢复 设计时要尽量避免数据恢复的必要设计时要尽量避免数据恢复的必要升级时候不睡觉升级时候不睡觉灰度发布、发布回滚灰度发布、发布回滚一期项目就半年,一期接一期一期项目就半年,一期接一期持续集成持续集成 Copyright 2013 Pivotal.All rights reserved.相对巨石应用,云原生应用引入了哪些技术传统巨石应用云原生应用垂直扩展;硬件定义可靠性水平扩展;应用设计消除对基础设施的依赖性虚拟化轻量级运行环境(容器,进程,PaaS平台)3层架构,有状态,紧耦合松耦合,微服务,API对操作系统和虚机有察觉和依赖通过容器和SpringBoot抽
15、象于操作系统,管理员控制系统控制(自动扩展,自动配置,自动恢复)瀑布式开发 敏捷开发敏捷开发 持续集成,持续部署,DevOps Copyright 2013 Pivotal.All rights reserved.云原生应用的关键设计之一-容错性设计 微服务要求应用需要有能容忍服务的故障的设计,客户端需要尽可能的优化这种场景的响应。这将让微服务团队时刻的想到服务故障的情况下用户的体验。为每个应用的服务及数据中心提供日常故障检测和恢复。这种产品中的自动化测试可以让大部分的运维团队正常的上下班。由于服务可以随时故障,快速故障检测,乃至,自动恢复变更非常重要。微服务应用把实时的监控放在应用的各个阶段
16、中,检测构架元素(每秒数据库的接收的请求数)和业务相关的指标(把分钟接收的定单数)。监控系统可以提供一种早期故障告警系统,让开发团队跟进并调查。对于微服务框架来说,这相当重要,因为微服务相互的通信可能导致紧急意外行为。监控是至关重要的,它能快速发现这种紧急不良行为,让我们迅速修复它。微服务团队期望清楚的监控和记录每个服务的配置,比如使用仪表盘显示上/下线状态、各种运维和业务相关的指标。对断路器(circuit breaker,定时检测服务状态)状态、目前的吞吐量和时延细节,我们也会经常遇到。Copyright 2013 Pivotal.All rights reserved.传统巨石应用和互联
17、网应用运作运维模式的不同产品不是项目产品不是项目u传统应用的开发模式:提供一些被认为是完整的软件。一旦开发完成,软件将移交给维护部门,然后,开发组就可以解散掉了。u互联网应用(微服务)认为认为开发组应该负责产品的整个生命周期。一个常见的证明是:Amazon的“你编译,你运维(you build,you run it)”的理念,它要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都关注软件产品的运行情况,并与用户联系的更紧密,同时承担一些售后支持。u成熟的产品会与业务功能进行绑定。除了把软件看成既定功能的集合外,会进一步关心“软件如何帮助用户实现业务功能”这样的问题。u采用整体型的架构也
18、有其应用场景,但是越小的服务粒度越容易促进用户与服务运营商之前的关系。Copyright 2013 Pivotal.All rights reserved.互联网应用开发的组织架构和传统巨石应用开发模式的不同界面开发人员中间件业务开发人员数据库管理员业务能力A业务能力B业务能力C烟囱式功能开发团队烟囱式应用架构跨功能开发团队微服务架构数据访问服务/EJB/Java BeanHTMLJavaScriptMVC服务围绕业务能力进行围绕业务能力进行组织组织微服务架构有以下几个特点:u 每个服务只需要做好一件事,更加专注和简单u 用合适的工具来做合适的事情u 服务(产品)之间是松耦合的,独立部署u 服
19、务(产品)的团队之间是相互独立的u 单一功能的改变只需要重新构建部署相应的服务即可 Copyright 2013 Pivotal.All rights reserved.传统巨石架构和互联网应用架构双轨运行(Bi-Modal)现代应用框架现代应用框架+SQL可深度扩展的分析数据平台可深度扩展的分析数据平台MPP Database实时数据平台实时数据平台重量级应用中间件重量级应用中间件传统磁盘传统磁盘RDBMSOLTP应用 统一统一OLTP应用应用/OLAP 实时分析实时分析ETL传统数据仓库传统数据仓库OLAP应用 服务平台服务平台Neo4J移动框架移动框架DS应用分发Jenkinscassa
20、ndra数据同步云存储MongoDBTracker推送Redis流处理 Copyright 2013 Pivotal.All rights reserved.目录 Pivotal的业界大牛 云原生应用架构和原理 PaaS的理论基础 PaaS的架构模型 PaaS的业务价值 Pivotal的PaaS架构和实践 Pivotal Spring微服务框架 PAAS的生产案例 Copyright 2013 Pivotal.All rights reserved.PaaS的几大架构要点运维自动化严格区分PaaS和IaaS运维通过PaaS来驱动IaaS的运维平台在线升级平台在线补丁应用服务器在线升级4重故障自
21、动恢复自动弹性伸缩灰度发布提供策略接口,运维模式自动化固化后定制实现全方位监控机制IaaS平台层监控PaaS部件业务逻辑层监控基于平台的应用无差别监控APM(应用性能监控)容器的监控PaaS应用微服务框架通过应用框架结合PaaS来实现新的自动化运维模式通过框架实现弹性伸缩通过框架实现对应用的调用监控通过框架实现故障截流、探测后自动恢复Application FrameworkServicesDatabaseObject StorageUser ProvidedCircuit Breakers.NETSpring BootNode.jsRuby on RailsPaaS应用运行应用运行时和运维自
22、动化时和运维自动化系统在线自升级OpenStackAmazonVMwareIaaS基础设施基础设施自动化自动化(CPI)虚机故障自动恢复 物理机故障自动恢复高可用性区网络隔离自动弹性伸缩应用安全组APM 应用一键部署应用计量服务计量系统提醒自动容器调度容器故障自动恢复 应用故障自动恢复多IaaS混合支持虚机全生命周期管理应用灰度发布 应用发布回滚异地双活日志自动采集聚合PaaS应用平台应用平台JavaTomcatGoPHPRubyNode.JSPython.NetWeblogicWebsphereC/C+JettyPlayResinPaaS应用通应用通用功能平台化用功能平台化Session共享
23、 日志分析APM应用和配置解耦服务自动安装、升级服务套餐化平台定制租户管理动态路由SSOLDAP集成Build CIPaaS应用服务应用服务Spring微服务框架远程文件共享API管理PaaS CI/CDDevOps服务服务Spring Boot服务注册和自动发现集中配置管理短路开关和监控数据消息服务mySQLMongoDBCassandraNeo4JRedisKafkaRabbitMQRiakCS流服务移动计算服务应用分发API Gateway数据同步应用分析大数据服务Pivotal HadoopGreenPlum服务EclipseJava插件微软Studio插件GitHubJenkinsA
24、rtifactoryPaaS功能架构图运维自动化门户容器集群管理容器引擎容器注册系统安全性CaaS/Docker也有的功能系统监控 Copyright 2013 Pivotal.All rights reserved.PaaS的业界逻辑架构26Source:Structured 预集成和测试过的解决方案 开箱即用的功能“Just works”,特定需求进行定制Unstructured 定制工作量比较大,针对每种不同的unstructured的需求进行定制 基于容器或容器镜像为主 带来非常好的灵活性,当时构建的代价高PaaS Platform 对开发者可见部分Message Bus/Queuin
25、g/RoutingService BrokersCapacity PlanningLoggingMonitoringApplication Staging/Application ServicesApplication SchedulingContainer SchedulingService DiscoveryContainer Cluster ManagementContainer NetworkingContainer RuntimeContainer OSContainer RuntimeContainer OSPhysical Host(or VM)Physical Host(or
展开阅读全文