Pivotal的云原生和PaaS平台-C

©Copyright2013Pivotal.Allrightsreserved.©Copyright2013Pivotal.Allrightsreserved.PaaS时代云平台建设和应用云化之路©Copyright2013Pivotal.Allrightsreserved.目录•云原生应用架构和原理•PaaS的理论基础•PaaS的架构模型•PaaS的业务价值•Pivotal的PaaS架构和实践•PivotalSpring微服务框架•PAAS的生产案例DefiningCloudNativeCloudnativeisatermdescribingsoftwaredesignedtorunandscalereliablyandpredictablyontopofpotentiallyunreliablecloudbasedinfrastructure.概念澄清—CloudNativeCloudNative包括两个方面1、CloudNativeFramework--应用框架，应用框架和设计本身适合运行在云上2、CloudnativePlatform,部署和运行环境业界有些思路是应用运行在容器中就是CloudNative，缺乏应用框架的支持。©Copyright2013Pivotal.Allrightsreserved.区别于传统应用--互联网应用的需求带来新技术--新技术带来运维全自动化•需求是持续发展的•是一个产品，持续发展•用户访问量难以预测，而且一般是持续增长•用户访问的并发量是万级、十万、百万•在线业务，业务不能停顿，互联网应用24小时服务，任何时候中断服务都是事故。传统应用特征互联网应用特征•需求比较固定•是个项目，完成以后就是运维•用户访问量可以预测，较为固定•用户访问的并发量在百级、千级•非在线业务，允许一定时间的业务停顿(比如夜间停机)，包括系统维护等，•敏捷业务，敏捷开发•持续集成•应用平台的弹性•支持海量并发•业务不停顿，灰度发布，发布回滚，系统在线升级。互联网应用技术要求云原生应用架构云原生应用框架云原生应用平台©Copyright2013Pivotal.Allrightsreserved.传统巨石应用和云原生微服务应用的概念模型关系数据库数据访问服务/EJB/JavaBeanHTMLJavaScriptMVC服务传统一体化架构的应用浏览器…HTTPHTTPHTTPHTTPHTTPHTTPAMQPAMQP关系型数据库Key/Value数据库(NoSQL)图形数据库©Copyright2013Pivotal.Allrightsreserved.传统巨石应用的特征和面对的问题--难以运维全自动化•故障有可能发生•随时备份数据，用于服务恢复•不惜一切代价保证服务器的运行•当服务器宕机时-摊上大事了•基础设施恢复–自动或者手动•应用恢复–手动•应用模块紧耦合•无法根据负载自动扩展•很难持续集成•应用聚合困难(ESB)•应用升级麻烦端口变化负载增加配置变化环境依赖代码变化RTO/RPO云原生应用的特征•符合十二要素•微服务•自服务的敏捷基础设施•基于API的协作•Antifragility（反脆弱性）8原生云架构应用框架应用运行时基础架构自动化引擎基础架构文化/角色开发人员开发人员运维人员运维人员运维人员支撑SpringCloudSpringBootCloudFoundryBOSHAWSVMWareOpenStackAzure应用云原生架构只有容器是不够的12FactorAppBOSHReleaseCloudProviderInterface9CNA架构需面对的难点•分布式系统的复杂性•远程调用多•跨多个服务的应用功能设计•依赖性管理/API版本化•重构模块的边界•无状态和有状态的分离(无状态改装不是必须的)10Source:“MicroservicePrerequisites,”MartinFowler,August2014.采用CNA的必要基础•需要开发、测试、运行平台的支持•快速提供应用环境•通用的框架•基本的监控•快速应用部署•DevOps的支持11PAAS提供对CNA的支撑•应用环境的自动化供应•按需的/自动化的弹性伸缩•四重的故障自动恢复/自愈能力•自动的路由/负载均衡•数据服务的运维自动化•基于平台的监控和基于应用的监控，二者的结合•微服务的框架•通用的应用服务(日志、APM、Session共享)目录•Pivotal的业界大牛•云原生应用架构和原理•PaaS的理论基础•PaaS的架构模型•PaaS的业务价值•Pivotal的PaaS架构和实践•PivotalSpring微服务框架•PAAS的生产案例©Copyright2013Pivotal.Allrightsreserved.PaaS的业务驱动力和要解决的问题PaaS要解决的问题业务敏捷性业务敏捷开发敏捷部署敏捷移动计算应用和系统的可用性系统可用性应用可用性运维自动化应用零运维服务运维高度自动化©Copyright2013Pivotal.Allrightsreserved.通过十二要素来规范应用通过PaaS在平台层面支撑十二要素应用需要即时弹性，而且需要运维的高度自动化(部署、故障恢复、自动扩容缩容)，应用多是无状态，无状态即公牛机制，通过服务来实现有状态，而服务不太需要即时弹性，服务更多是有状态，服务的运维自动化即时性要求不高，有状态就要去有备份、恢复等。服务的运维需要各种工具，很多时候会需要人工介入，比如数据库调优、故障恢复，而应用的运维可以高度自动化、无需人工介入，主要通过日志分析，服务更适合运行在虚机，而应用适合运行在容器中。由于服务的有状态，不容易实现即时恢复，所以服务的可用性要求、资源独享性更高，共享OS内核不适合服务区分IaaS和PaaSIaaS实现基础设施池化PaaS实现应用相关的功能通过PaaS来驱动IaaS，实现运维自动化十二要素1区分应用和服务2区分IaaS和PaaS3PaaS三大理论基础©Copyright2013Pivotal.Allrightsreserved.PaaS的理论基础云原生应用的十二要素1.基准代码：一份基准代码，多份部署。基准代码和应用之间总是保持一一对应的关系。所有部署的基准代码相同，但每份部署可以使用其不同的版本。2.依赖：显式声明依赖关系。应用程序一定通过依赖清单，确切地声明所有依赖项。3.配置：在环境中存储配置。将应用的配置存储于环境变量中。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码。4.后端服务：不区分本地和远端服务。不要把服务打包在应用中，通过绑定或是DNS寻址。5.构建，发布，运行：严格区分构建，发布，运行这三个步骤，不要再运行中去改配置。6.进程：以一个或多个无状态进程运行应用。应用的进程必须无状态且无共享。7.端口绑定：通过端口绑定提供服务。应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。8.并发：通过进程模型进行扩展，开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程类型，每个进程均可以并发，可以弹性伸缩。9.易销毁性：快速启动和优雅终止可最大化健壮性。应用的进程是可销毁的，意思是说它们可以瞬间开启或停止。10.开发环境与线上环境等价：尽可能保持开发、预发布、线上环境相同。应用想要做到持续部署就必须缩小本地与线上差异。11.日志：把日志当作事件流。应用本身考虑存储自己的输出流。不应该试图去写或者管理日志文件。12.管理进程：基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。。©Copyright2013Pivotal.Allrightsreserved.为发挥PaaS最大价值，传统应用架构转变为云原生应用遵循云原生架构原则开发的应用，适应于部署在PaaS云上的应用，能够充分发挥PaaS价值的应用就是云原生应用传统巨石应用云原生应用应用平台PaaS平台IT基础设施PaaS平台驱动的IaaS•微服务(开发相关)•符合十二要素(开发/平台相关)•Antifragility/反脆弱性(开发/平台相关)•自服务的敏捷基础设施(平台相关)©Copyright2013Pivotal.Allrightsreserved.云原生应用解决了哪些传统巨石应用的问题很难根据负载自动扩展自动，水平扩展应用模块牵一发而动全身应用由多个微服务组成，松耦合应用的恢复是靠人工的应用的恢复是自动化的应用系统的物理环境错误导致业务停顿应用的物理环境的出错是可以接受的不遗余力的保障物理机的运转物理机对应用不是那么重要物理机的宕机是一件特大事故！没什么大惊小怪的！积极备份数据以便应用环境出错时恢复设计时要尽量避免数据恢复的必要升级时候不睡觉灰度发布、发布回滚一期项目就半年，一期接一期持续集成©Copyright2013Pivotal.Allrightsreserved.相对巨石应用，云原生应用引入了哪些技术传统巨石应用云原生应用垂直扩展；硬件定义可靠性水平扩展；应用设计消除对基础设施的依赖性虚拟化轻量级运行环境（容器，进程，PaaS平台）3层架构，有状态，紧耦合松耦合，微服务，API对操作系统和虚机有察觉和依赖通过容器和SpringBoot抽象于操作系统，管理员控制系统控制（自动扩展，自动配置，自动恢复）瀑布式开发敏捷开发敏捷开发持续集成，持续部署,DevOps©Copyright2013Pivotal.Allrightsreserved.云原生应用的关键设计之一--容错性设计微服务要求应用需要有能容忍服务的故障的设计，客户端需要尽可能的优化这种场景的响应。这将让微服务团队时刻的想到服务故障的情况下用户的体验。为每个应用的服务及数据中心提供日常故障检测和恢复。这种产品中的自动化测试可以让大部分的运维团队正常的上下班。由于服务可以随时故障，快速故障检测，乃至，自动恢复变更非常重要。微服务应用把实时的监控放在应用的各个阶段中，检测构架元素（每秒数据库的接收的请求数）和业务相关的指标（把分钟接收的定单数）。监控系统可以提供一种早期故障告警系统，让开发团队跟进并调查。对于微服务框架来说，这相当重要，因为微服务相互的通信可能导致紧急意外行为。监控是至关重要的，它能快速发现这种紧急不良行为，让我们迅速修复它。微服务团队期望清楚的监控和记录每个服务的配置，比如使用仪表盘显示上/下线状态、各种运维和业务相关的指标。对断路器（circuitbreaker,定时检测服务状态）状态、目前的吞吐量和时延细节，我们也会经常遇到。©Copyright2013Pivotal.Allrightsreserved.传统巨石应用和互联网应用运作运维模式的不同产品不是项目传统应用的开发模式：提供一些被认为是完整的软件。一旦开发完成，软件将移交给维护部门，然后，开发组就可以解散掉了。互联网应用(微服务)认为认为开发组应该负责产品的整个生命周期。一个常见的证明是：Amazon的“你编译，你运维（youbuild,yourunit）”的理念，它要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都关注软件产品的运行情况，并与用户联系的更紧密，同时承担一些售后支持。成熟的产品会与业务功能进行绑定。除了把软件看成既定功能的集合外，会进一步关心“软件如何帮助用户实现业务功能”这样的问题。采用整体型的架构也有其应用场景，但是越小的服务粒度越容易促进用户与服务运营商之前的关系。©Copyright2013Pivotal.Allrightsreserved.互联网应用开发的组织架构和传统巨石应用开发模式的不同界面开发人员中间件业务开发人员数据库管理员业务能力A业务能力B业务能力C烟囱式功能开发团队烟囱式应用架构跨功能开发团队微服务架构数据访问服务/EJB/JavaBeanHTMLJavaScriptMVC服