《Pivotal基于开源的持续集成解决方案》由会员分享，可在线阅读，更多相关《Pivotal基于开源的持续集成解决方案（56页珍藏版）》请在金锄头文库上搜索。
1、Pivotal 基于开源的持续集成解决方案,目录,传统应用架构和互联网应用微服务架构 PaaS和容器 Pivotal PaaSPCF功能架构 PCF对开发环境的支持 PCF对DevOps的支持 PCF对云本应用的支持 应用迁移到PCF的实际效果 PCF案例分享,DevOps的由来,最初起源于2009年，由Patrick Debois/Andrew Shafer 提出 是两个词的融合 Development Operations 是一种运动，一种文化,术语“DevOps”通常指的是新兴的专业化运动 这种运动提倡开发和IT运维之间的高度协同，从而 在完成高频率部署的同时，提高生产环境的可靠性、稳定
2、性、弹性和安全性。,定义,10+ Deploys Per Day: Dev and Ops Cooperation,DevOps的几个相关重要概念,核心关键词 敏捷 快速 持续不间断 变化 现有开发运维流程关键词 规划 步骤 稳定 自动化 Fast, automated feedback on the production readiness of your application every time there is a change -to code, infrastructure, or configuration.,DevOps,敏捷宣言-遵循以下原则,我们最重要的目标，是通过持续不
3、断地及早交付有价值的软件使客户满意。 欣然面对需求变化，即使在开发后期也一样。 为了客户的竞争优势，敏捷过程掌控变化。 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 业务人员和开发人员必须相互合作，项目中的每一天都不例外。 敏捷过程倡导可持续开发责任人、开发人员和用户要能够共同维持其步调稳定延续。,DevOps和Agile开发模式的区别,Agile 敏捷开发,DevOps,Always Production Ready,Release,DevOps与ITIL/ITSM,并不是完全颠覆 为了适用跟DevOps相关的快速部署的节奏，ITIL流程的很多方面，特别是围绕着变更、
4、配置和发布流程方面，需要自动化。 DevOps的目标不仅只是增加变更的频率，而且也支持在不中断和破坏当前服务的基础上，确保功能部署成功，同时也可以快速检测和修复缺陷。这引入了服务设计，事故和问题管理方面的ITIL新准则。,DevOps与ITIL/ITSM - 续,ITIL/ITSM 是第二代IT平台的产物，该方法论是基于第二代IT架构的最佳实践 在向云及第三代IT平台的转型过程中，除了技术平台本身需要转型之外，应用生命周期管理的方法论也需要转型 根本原因是基础平台的进化移除了原本需要流程来防范的系统性风险,DevOps的优势,30倍生产效率提升 50%出错率下降,Amazon 每周生产迭代10
5、00次 99.999%的成功率,DevOps的价值,产品快速推向市场 缩短开发周期 更高的部署频率 大幅度提高质量 提升可用性 提高变更成功率 减少故障 大幅度提升组织效率 提高dev,ops组织员工满意度 降低工作的强度，减少重复劳动,持续集成尽可能快的把不同开发人员修改的代码集成到一起，通常一天进行多次需要结合自动化单元测试，每次集成都运行一整套单元测试目标是尽快发现代码问题,持续交付持续的把改动的代码交给预演环境，接受QA检查，确保此套代码是可以随时部署的持续交付比持续集成更进一步，持续集成是代码层面的测试，持续交付不仅把代码集成起来，还会把真实环境中需要的配置信息设置好，在预演环境中运
6、行起来，进行整体业务逻辑检查目标是保证代码处于可部署状态,持续部署 把所有通过测试的代码尽快部署到线上产品环境持续部署是持续交付的更高阶段，它把处于可部署的代码自动发布到了产品环境，所以持续部署需要持续集成、持续交付的支撑,DevOps的核心要素,要点1-敏捷开发,符合敏捷开发12原则 是Heroku的创始人运维了上万的版本和应用总结出来的最佳实践 围绕这12个原则衍生了一大批的方法论和工程实践，大多数应用于互联网企业并得到了非常好的评价和反馈 微服务模式 - Microservices 选择合适的开发框架 如企业级的Spring框架,十二原则,One Codebase/Many Deploy
7、s Explicit Isolated Dependencies Config via Environment Attached Backing Services Separate Build/Release/Run Stateless Processes Export Services via Port Bindings Scale Out via Processes Disposable Instances Dev/Prod Parity Logs = Event Streams Admin Tasks = Processes,16,详见 ,一个流程的交付件，如一次构件结果,与部署定义相关
8、的配置信息、SLA等。,应用,配置,物理的或者虚拟的架构 IaaS PaaS,变更频率,低,高,硬件,操作系统本身,操作系统配置,中间件本身,应用本身,中间件配置,应用的配置,曾遇到的那些问题 发布管理为什么困难？-涉及层面太多,Integration Testing lags a step behind the code,Tester,Developer,编写&交付代码,Nightly build(s)Compile, unit test, publish,Developer,Developer,Developer,Developer,Developer,N 天去安装和配置,N 个每日交付成
9、果,发布与部署的常见问题一：持续构建但不能持续上线,传统应用架构和互联网应用架构双轨运行(Bi-Modal),+ SQL,可深度扩展的分析数据平台,MPP Database,实时数据平台,传统磁盘RDBMS,OLTP应用,统一OLTP应用 /OLAP 实时分析,传统数据仓库,OLAP应用,服务平台,Neo4J,移动框架,DS,应用 分发,Jenkins,cassandra,数据同步,云存储,MongoDB,Tracker,推送,Redis,流处理,传统应用和互联网业务应用的需求不同带来的技术要求,需求是持续发展的 是一个产品，持续发展 用户访问量难以预测，而且一般是持续增长 用户访问的并发量是
10、万级、十万、百万 在线业务，业务不能停顿，互联网应用24小时服务，任何时候中断服务都是事故。,传统应用特征,互联网应用特征,需求比较固定 是个项目，完成以后就是运维 用户访问量可以预测，较为固定 用户访问的并发量在百级、千级 非在线业务，允许一定时间的业务停顿(比如夜间停机)，包括系统维护等，,敏捷业务，敏捷开发 持续集成 应用平台的弹性 支持海量并发 业务不停顿，灰度发布，发布回滚，系统在线升级。,互联网应用技术要求,云原生应用架构,云原生应用框架,云原生应用平台,产品(互联网应用)和项目(传统应用)的区别,产品不是项目 传统应用的开发模式：提供一些被认为是完整的软件。一旦开发完成，软件将移
11、交给维护部门，然后，开发组就可以解散掉了。 互联网应用(微服务)认为认为开发组应该负责产品的整个生命周期。一个常见的证明是：Amazon的“你编译，你运维（you build, you run it）”的理念，它要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都关注软件产品的运行情况，并与用户联系的更紧密，同时承担一些售后支持。 成熟的产品会与业务功能进行绑定。除了把软件看成既定功能的集合外，会进一步关心“软件如何帮助用户实现业务功能”这样的问题。 采用整体型的架构也有其应用场景，但是越小的服务粒度越容易促进用户与服务运营商之前的关系。,传统一体化架构和微服务架构的概念模型,关系数据
12、库,浏览器,微服务支持开发的组织架构围绕业务能力规划,烟囱式功能开发团队,烟囱式应用架构,跨功能开发团队,微服务架构,围绕业务能力进行组织 微服务架构有以下几个特点： 每个服务只需要做好一件事，更加专注和简单 用合适的工具来做合适的事情 服务(产品)之间是松耦合的，独立部署 服务(产品)的团队之间是相互独立的 单一功能的改变只需要重新构建部署相应的服务即可,SOA和微服务,微服务 去中心化，才能无限扩展，才能持续成长，支持海量并发，强化终端、弱化管道 服务是一个部署单元，可以直接部署 松耦合、高内聚，REST接口或消息 每个服务可以选择特定的技术，Node.JS开发Web页面，C+做高性能要求
13、， 分散治理 无单点设计、可监控、可测试、可回滚、可禁用、短事务与柔性事务、异步设计、无状态 集成设施自动化，基于容器部署 微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务即可,SOA架构 ESB就是汇集中心点，ESB影响了系统的扩展性，把接口复杂化。 服务还不是直接部署单元，部署要做特定设计 SOAP、BPEL等复制协议，集中式框架 服务的实现都是基于J2EE实现，一个技术难以适应各种技术要求 集中治理,SOA和微服务,微服务 分散治理 分散数据管理 强调服务间事务的协调，一致性只能是最终一致性以及通过补偿运算处理问题。 BA
14、SE(Basically Available为基本可用，Soft-state为软状态/柔性事务，EventualConsistency 为最终一致性) 适合互联网金融业务,SOA架构 集中治理 集中数据管理 支持数据库的事务性，难以支持分布式事务 ACID（原子性、一致性、隔离性、持久性） 适合核心帐务之类严格事务性的应用,微服务特征-容错性设计,微服务要求应用需要有能容忍服务的故障的设计，客户端需要尽可能的优化这种场景的响应。这将让微服务团队时刻的想到服务故障的情况下用户的体验。为每个应用的服务及数据中心提供日常故障检测和恢复。 这种产品中的自动化测试可以让大部分的运维团队正常的上下班。 由
15、于服务可以随时故障，快速故障检测，乃至，自动恢复变更非常重要。微服务应用把实时的监控放在应用的各个阶段中，检测构架元素（每秒数据库的接收的请求数）和业务相关的指标（把分钟接收的定单数）。监控系统可以提供一种早期故障告警系统，让开发团队跟进并调查。 对于微服务框架来说，这相当重要，因为微服务相互的通信可能导致紧急意外行为。监控是至关重要的，它能快速发现这种紧急不良行为，让我们迅速修复它。 微服务团队期望清楚的监控和记录每个服务的配置，比如使用仪表盘显示上/下线状态、各种运维和业务相关的指标。对断路器（circuit breaker,定时检测服务状态）状态、目前的吞吐量和时延细节，我们也会经常遇到
16、。,微服务特征基础设施自动化,微服务特征-运行在容器中,软件工厂 根据反馈快速迭代开发 水平伸缩 支持多样化的客户端 持续交付,基础设施,应用,微服务架构,物理机器/虚拟化,Cloud Foundry,Application Framework,Services,Database,Object Storage,User Provided,Circuit Breakers,.NET,Spring Boot,Node.js,Ruby on Rails,PaaS应用运行时和运维自动化,系统在线自升级,IaaS基础设施 自动化(CPI),虚机故障自动恢复,物理机故障自动恢复,高可用性区,网络隔离,自动弹性伸缩,应用安全组,APM,应用一键部署,应用计量,服务计量,系统提醒,自动容器调度,容器故障自动恢复,应用故障自动恢复,多IaaS混合支持,虚机全生命周期管理,应用灰度发布,应用发布回滚,异地双活,日志自动采集聚合,PaaS应用平台,Java,Tomcat,
