标签分类
当前位置:首页 > 其它计算机电子书 > 微服务电子书网盘下载
微服务运维实战:第一卷 微服务运维实战:第一卷
52pojie

52pojie 提供上传

资源
22
粉丝
22
喜欢
172
评论
7

    微服务运维实战:第一卷 PDF 完整清晰版

    微服务电子书
    • 发布时间:

    给大家带来的一篇关于微服务相关的电子书资源,介绍了关于微服务、运维、实战方面的内容,本书是由华中科技大学出版社出版,格式为PDF,资源大小197 MB,Viktor Farcic编写,目前豆瓣、亚马逊、当当、京东等电子书综合评分为:7.8,更多相关的学习资源可以参阅 其它计算机电子书、等栏目。

  • 微服务运维实战:第一卷 PDF 下载
  • 下载地址:https://pan.baidu.com/s/12FvPhAWzb8pz1tUolelXvQ
  • 分享码:byk1
  • 微服务运维实战:第一卷 PDF

    《微服务运维实战(第1卷)》详细讲解微服务和容器在软件持续集成和部署中的应用。将微服务打包成不可变的容器,通过配置管理工具实现自动化测试和持续部署,同时保证零停机且随时能回滚。采用集中日志对集群进行记录和监控,轻松实现服务器扩展。作者通过讲解相关工具(Docker、Kubernetes、Ansible、Consul等)的用法,分享自己的工作经验,帮助读者构建高效、可靠、可快速恢复的软件系统。

    目录

    • 第1章 DevOps的理想 1
    • 1.1 持续集成、交付和部署 2
    • 架构 3
    • 部署 4
    • 编排 5
    • 1.2 部署流水线的曙光 5
    • 第2章 实现突破——持续部署、微服务和容器 7
    • 2.1 持续集成 7
    • 推送到代码库 9
    • 静态分析 10
    • 部署前测试 12
    • 打包并部署到测试环境 13
    • 部署后测试 13
    • 2.2 持续交付和部署 15
    • 微服务 18
    • 容器 18
    • 2.3 三个火枪手——持续部署、微服务和容器的协作 20
    • 第3章 系统架构 23
    • 3.1 单块应用 24
    • 微服务 27
    • 3.2 单块应用与微服务的比较 29
    • 运维和部署的复杂性 30
    • 规模 31
    • 部署、回滚和故障隔离 32
    • 承诺期限 32
    • 3.3 微服务的最佳实践 41
    • 容器 41
    • 3.4 代理微服务或API网关 44
    • 反向代理 44
    • 极简主义方法 45
    • 配置管理 45
    • 跨职能团队 45
    • API版本化 46
    • 最后的思考 46
    • 第4章 使用Vagrant和Docker搭建开发环境 49
    • 4.1 结合微服务架构和容器技术 50
    • Vagrant与Docker 52
    • 4.2 开发环境搭建 55
    • 开发环境使用 58
    • 第5章 部署流水线的实现——初始阶段 63
    • 5.1 启动持续部署虚拟机 63
    • 5.2 部署流水线步骤 65
    • 构建Docker容器 67
    • 第6章 Docker世界中的配置管理 79
    • 6.1 CFEngine 79
    • Puppet 80
    • Chef 80
    • 最后几点思考 82
    • 配置生产环境 83
    • 设置Ansible Playbook 86
    • 第7章 部署管道的实现——中间阶段 91
    • 7.1 在生产服务器上部署容器 92
    • 检查清单 97
    • 第8章 发现服务——分布式服务的关键 99
    • 8.1 服务注册表 101
    • 服务注册 101
    • 主动注册 102
    • 注册服务 103
    • 服务发现 103
    • 服务发现工具 104
    • 手动配置 106
    • Zookeeper 106
    • etcd 107
    • 配置Registrator 130
    • Consul Health Checks、Web UI和数据中心 138
    • 8.2 服务发现工具的比较 141
    • 第9章 代理服务 143
    • 9.1 反向代理服务 144
    • 代理服务对我们的项目有何帮助 146
    • nginx 146
    • nginx 146
    • HAProxy 158
    • 9.2 代理工具的比较 163
    • 第10章 部署流水线的实现——后期阶段 167
    • 10.1 启动容器 169
    • 10.2 集成服务 170
    • 10.3 运行部署后测试 171
    • 10.4 将测试容器推送到镜像库 172
    • 10.5 检查表 173
    • 第11章 部署流水线的自动化实现 175
    • 11.1 部署流水线的步骤 175
    • Playbook和Role 178
    • 部署前任务 179
    • 部署任务 182
    • 部署后任务 185
    • 11.2 运行自动部署流水线 186
    • 第12章 持续集成、交付和部署的工具 187
    • 12.1 CI/CD工具对比 188
    • CI/CD工具的简史 189
    • 运行Jenkins作业 203
    • 创建Jenkins Workflow作业 206
    • 安装Jenkins Multibranch Workflow和Jenkinsfile 215
    • 最后的想法 217
    • 第13章 蓝绿部署 219
    • 13.1 蓝绿部署的流程 220
    • 13.2 手动执行蓝绿部署 223
    • 部署蓝色版本 224
    • 集成蓝色版本 226
    • 部署绿色版本 228
    • 集成绿色版本 230
    • 移除蓝色版本 231
    • 发现应部署哪个版本以及回滚 233
    • 13.3 使用Jenkins workflow自动化蓝绿部署 239
    • 蓝绿部署角色 240
    • 运行蓝绿部署 245
    • 第14章 服务集群和扩展 249
    • 14.1 可扩展性 250
    • 轴线扩展 252
    • 集群 254
    • Docker集群工具大比拼——Kubernetes、Docker Swarm和
    • Mesos对比 256
    • 搭建 258
    • 运行容器 260
    • 选择 262
    • 14.2 Docker Swarm漫步 263
    • 14.3 搭建Docker Swarm 268
    • 使用Docker Swarm部署 274
    • 使用Docker Swarm无链接部署 275
    • 使用Docker Swarm和Docker Networking部署 276
    • 使用Docker Swarm扩展服务 283
    • 根据预留的CPU和内存调度容器 284
    • 14.4 使用Docker Swarm和Ansible自动化部署 288
    • 检验Swarm部署playbook 290
    • 第15章 自我修复系统 297
    • 15.1 自我修复等级和类型 298
    • 应用程序级别的自我修复 299
    • 系统级别的自我修复 300
    • 硬件级别的自我修复 302
    • 反应式自我修复 303
    • 预防式自我修复 303
    • 15.2 自我修复架构 305
    • 15.3 Docker、Consul Watches和Jenkins组成的自我修复系统 311
    • 搭建环境 311
    • 15.4 自动设置Consul健康检查和watches来监测硬件 322
    • 15.5 预设扩展和收缩的预防式自我修复 334
    • 采用Docker重启策略的预防式自我修复 339
    • 将On-Premise与云节点结合 341
    • 15.6 自我修复系统(到目前为止)总结 342
    • 第16章 集中日志和监控 343
    • 16.1 集中日志的需求 344
    • 16.2 向ElasticSearch发送日志条目 347
    • 解析文件条目 354
    • 发送日志条目到集中式LogStash 358
    • 发送Docker日志条目到集中式LogStash实例 363
    • 16.3 基于软件数据的自修复系统 375
    • 硬件状态日志 381
    • 基于硬件数据的自修复系统 388
    • 最后的想法 388
    • 第17章 结语 391
    • 附录A Docker Flow 393
    • A.1 背景 394
    • 标准搭建环境 394
    • 问题 396
    • Docker Flow漫谈 398
    • 零停机事件部署新版本 404
    • 索引 415
       

    上一篇:PHP编程入门与应用  下一篇:看透JavaScript:原理、方法与实践

    展开 +

    收起 -

    微服务 相关电子书
    学习笔记
    网友NO.532559

    浅谈Spring Boot 微服务项目的推荐部署方式

    如果开发过spring boot的程序,应该都知道,使用 spring boot 官方的 maven 打包插件(spring-boot-maven-plugin) 来打包,打出来的jar包一般有40M以上. 如果公司的服务器上传带宽不高,那么手动上传一个jar或者jenkins部署一次jar,都是非常痛苦的........ 但是,如果打包的时候不引入lib,那么打出来的jar包一般只有几十k而已,非常小,想怎么传就怎么传......... 本文会提供一个 bash 启动脚本,只需要稍做更改,即可适应你的程序部署方式. 先看一下我的微服务目录结构: service/ =================== 服务根目录├── bootstrap.sh ============ 公用启动脚本├── lib ==================== 公用lib,如果有特殊的服务,不需要共用的jar,则需要添加私用的启动脚本,和私用的lib│ ├── accessors-smart-1.1.jar│ ├── asm-5.0.3.jar...... ======================= jar包太多,省略.├── service0 =============== 一个微服务│ ├── application.yml ======= 这个配置文件作用仅仅是控制不同环境的使用的不同配置文件,内容非常简单: spring.profiles.active: dev │ └── service0.jar ========= 核心jar└── service1 ├── application.yml └── service1.jar 插一句:这里没有使用docker,日后有空,再写一篇基于docker的spring boot微服务部署. 这样一来,如果我要启动service0,只需要在service目录下输入: ./bootstrap.sh start service0 即可启动service0 最后……

    网友NO.457577

    详解SpringCloud微服务架构之Hystrix断路器

    一:什么是Hystrix 在分布式环境中,许多服务依赖项中的一些将不可避免地失败。Hystrix是一个库,通过添加延迟容差和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点,停止其间的级联故障以及提供回退选项,从而提高系统的整体弹性。 Hystrix旨在执行以下操作 1:对通过第三方客户端库访问(通常通过网络)的依赖关系提供保护并控制延迟和故障。 2:隔离复杂分布式系统中的级联故障。 3:快速发现故障,尽快恢复。 4:回退,尽可能优雅地降级。 5:启用近实时监控,警报和操作控制。 二:为什么需要Hystrix? 大型分布式系统中,一个客户端或者服务依赖外部服务,如果一个服务宕了,那么由于我们设置了服务调用系统超时时间,势必会影响相应时间,在高并发的情况下大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性。 (图片官方图片) 当一切都健康时,请求可以看起来像这样 当许多后端服务系统中的一个宕掉时,整个用户请求: 如果多个客户端调用同一个异常服务的时候,出现的情况是: 三:Hystrix解决什么问题? 分布式架构中的应用程序具有几十个依赖关系,每个依赖关系在某个时刻将不可避免的出现异常。如果应用程序不与这些外部故障隔离,则可能出现线……

    网友NO.285394

    详解spring cloud构建微服务架构的网关(API GateWay)

    前言 在我们前面的博客中讲到,当服务A需要调用服务B的时候,只需要从Eureka中获取B服务的注册实例,然后使用Feign来调用B的服务,使用Ribbon来实现负载均衡,但是,当我们同时向客户端暴漏多个服务的时候,客户端怎么调用我们暴漏的服务了,如果我们还想加入安全认证,权限控制,过滤器以及动态路由等特性了,那么就需要使用Zuul来实现API GateWay了,下面,我们先来看下Zuul怎么使用。 一、加入Zuul的依赖 dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-zuul/artifactId /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-eureka/artifactId /dependency 由于,我们需要将Zuul服务注册到Eureka Server上,同时从Eureka Server上发现注册的服务,所以这里我们加上了Eureka的依赖。 二、在应用Application主类上开启Zuul支持 @SpringBootApplication @EnableZuulProxy // 使用@EnableZuulProxy来开启Zuul的支持,如果你不想使用Zuul提供的Filter和反向代理的功能的话,此处可以使用@EnableZuulServer注解 public class ZuulApplication { public static void main(String[] args) { SpringApplication.run(ZuulApplication.class, args); } } 三、在application.yml中增加Zuul的基础配置信息 spring: application: name: gateway-zuul # 应用名 server: port: 8768 #Zuul Server的端口号 eureka: client: service-url: defau……

    网友NO.293331

    Servlet+MyBatis项目转Spring Cloud微服务,多数据源配置修改建议

    一、项目需求 在开发过程中,由于技术的不断迭代,为了提高开发效率,需要对原有项目的架构做出相应的调整。 二、存在的问题 为了不影响项目进度,架构调整初期只是把项目做了简单的maven管理,引入springboot并未做spring cloud微服务处理。但随着项目的进一步开发,急需拆分现有业务,做微服务处理。因此架构上的短板日益突出。spring cloud config 无法完全应用,每次项目部署需要修改大量配置文件。严重影响开发效率,因此便萌生了对项目架构再次调整的决心。 三、调整建议 为了兼容以前的代码版本,尽量不修改现有的代码结构,以免增加额外的工作量并且为了更好的应用cloud config。 首先,创建JdbcConfigBean类,用以读取配置文件,实例代码入如下(仅供参考): import org.springframework.beans.factory.annotation.Value;import org.springframework.cloud.context.config.annotation.RefreshScope;import org.springframework.stereotype.Component;@RefreshScope@Component("jdbcConfigBean")public class JdbcConfigBean { @Value("${jdbc.driver}") private String driver; @Value("${db1.jdbc.url}") private String url; @Value("${db1.jdbc.username}") private String username; @Value("${db1.jdbc.password}") private String password; @Value("${db2.jdbc.url}") private String db2_url; @Value("${db2.jdbc.username}") private String db2_username; @Value("${db2.jdbc.password}") private Str……

    Copyright 2018-2019 xz577.com 码农之家

    版权责任说明