标签分类
当前位置:首页 > 计算机理论电子书 > 微服务电子书网盘下载
微服务设计 微服务设计
yzxlyd

yzxlyd 提供上传

资源
33
粉丝
33
喜欢
112
评论
7

    微服务设计 PDF 原书完整版

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

    给大家带来的一篇关于微服务相关的电子书资源,介绍了关于微服务、设计方面的内容,本书是由人民邮电出版社出版,格式为PDF,资源大小49.2 MB,纽曼编写,目前豆瓣、亚马逊、当当、京东等电子书综合评分为:8.1,更多相关的学习资源可以参阅 计算机理论电子书、等栏目。

  • 微服务设计 PDF 下载
  • 下载地址:https://pan.baidu.com/s/1IpcJNY5o-1esrm-PNi9BOw
  • 分享码:z8d1
  • 微服务设计 PDF

    以往10年中,分布式系统的粒度分布变得更加细,包括很多编码的片料运用慢慢变化为自包括的微服务。但开发微服务系统软件也是某些令人头痛的难题。这书根据很多的事例,全方位探讨了系统架构师和管理人员在搭建、管理方法和演变分布式架构时务必考虑到的难题,并得出了好用的提议。
    这书不仅详尽地论述了微服务的基本要素,并且还深层次研究了怎样对自治服务项目开展模型、集成化、检测、布署及监控器。书中编造了某一行业的一间企业,来协助用户学习培训分布式架构是怎样危害1个行业的。
    掌握微服务如何把控制系统设计与机构总体目标相符合

    把握将1个服务项目和目前系统软件开展集成化的不一样方法

    应用增量式的作法分拆片料编码库
    根据持续集成布署每个微服务
    思考对分布式系统开展检测和监控器的多元性
    管理方法“客户-服务项目”和“服务项目-服务项目”二种方式下的安全系数
    了解分布式架构在产业化层面所遭遇的难题
    这书全方位详细介绍了微服务的模型、集成化、检测、布署和监控器,根据1个编造的企业解读了怎样创建分布式架构。主题思想包含了解微服务在保障体系设计方案与机构总体目标一致上的必要性,学好把服务项目集成化到现有系统软件中,选用增长方式分拆片料大中型运用,根据持续集成布署微服务,这些。

    目录

    • 前言 xiv
    • 第1 章 微服务 1
    • 1.1 什么是微服务 2
    • 1.1.1 很小,专注于做好一件事 2
    • 1.1.2 自治性 3
    • 1.2 主要好处 3
    • 1.2.1 技术异构性 3
    • 1.2.2 弹性 4
    • 1.2.3 扩展 5
    • 1.2.4 简化部署 5
    • 1.2.5 与组织结构相匹配 6
    • 1.2.6 可组合性 6
    • 1.2.7 对可替代性的优化 6
    • 1.3 面向服务的架构 7
    • 1.4 其他分解技术 7
    • 1.4.1 共享库 8
    • 1.4.2 模块 8
    • 1.5 没有银弹 9
    • 1.6 小结 10
    • 第2 章 演化式架构师 11
    • 2.1 不准确的比较 11
    • 2.2 架构师的演化视角 12
    • 2.3 分区 14
    • 2.4 一个原则性的方法 15
    • 2.4.1 战略目标 15
    • 2.4.2 原则 15
    • 2.4.3 实践 16
    • 2.4.4 将原则和实践相结合 16
    • 2.4.5 真实世界的例子 16
    • 2.5 要求的标准 17
    • 2.5.1 监控 18
    • 2.5.2 接口 18
    • 2.5.3 架构安全性 18
    • 2.6 代码治理 18
    • 2.6.1 范例 19
    • 2.6.2 裁剪服务代码模板 19
    • 2.7 技术债务 20
    • 2.8 例外管理 21
    • 2.9 集中治理和领导 21
    • 2.10 建设团队 22
    • 2.11 小结 23
    • 第3 章 如何建模服务 24
    • 3.1 MusicCorp 简介 24
    • 3.2 什么样的服务是好服务 25
    • 3.2.1 松耦合 25
    • 3.2.2 高内聚 25
    • 3.3 限界上下文 26
    • 3.3.1 共享的隐藏模型 26
    • 3.3.2 模块和服务 27
    • 3.3.3 过早划分 28
    • 3.4 业务功能 28
    • 3.5 逐步划分上下文 29
    • 3.6 关于业务概念的沟通 30
    • 3.7 技术边界 30
    • 3.8 小结 31
    • 第4 章 集成 32
    • 4.1 寻找理想的集成技术 32
    • 4.1.1 避免破坏性修改 32
    • 4.1.2 保证API 的技术无关性 32
    • 4.1.3 使你的服务易于消费方使用 33
    • 4.1.4 隐藏内部实现细节 33
    • 4.2 为用户创建接口 33
    • 4.3 共享数据库 33
    • 4.4 同步与异步 35
    • 4.5 编排与协同 35
    • 4.6 远程过程调用 38
    • 4.6.1 技术的耦合 38
    • 4.6.2 本地调用和远程调用并不相同 39
    • 4.6.3 脆弱性 39
    • 4.6.4 RPC 很糟糕吗 40
    • 4.7 REST 41
    • 4.7.1 REST 和HTTP 41
    • 4.7.2 超媒体作为程序状态的引擎 42
    • 4.7.3 JSON、XML 还是其他 44
    • 4.7.4 留心过多的约定 44
    • 4.7.5 基于HTTP 的REST 的缺点 45
    • 4.8 实现基于事件的异步协作方式 46
    • 4.8.1 技术选择 46
    • 4.8.2 异步架构的复杂性 47
    • 4.9 服务即状态机 48
    • 4.10 响应式扩展 48
    • 4.11 微服务世界中的DRY 和代码重用的危险 49
    • 4.12 按引用访问 50
    • 4.13 版本管理 51
    • 4.13.1 尽可能推迟 51
    • 4.13.2 及早发现破坏性修改 52
    • 4.13.3 使用语义化的版本管理 53
    • 4.13.4 不同的接口共存 53
    • 4.13.5 同时使用多个版本的服务 54
    • 4.14 用户界面 55
    • 4.14.1 走向数字化 56
    • 4.14.2 约束 56
    • 4.14.3 API 组合 57
    • 4.14.4 UI 片段的组合 57
    • 4.14.5 为前端服务的后端 59
    • 4.14.6 一种混合方式 60
    • 4.15 与第三方软件集成 61
    • 4.15.1 缺乏控制 61
    • 4.15.2 定制化 62
    • 4.15.3 意大利面式的集成 62
    • 4.15.4 在自己可控的平台进行定制化 62
    • 4.15.5 绞杀者模式 64
    • 4.16 小结 65
    • 第5 章 分解单块系统 66
    • 5.1 关键是接缝 66
    • 5.2 分解MusicCorp 67
    • 5.3 分解单块系统的原因 68
    • 5.3.1 改变的速度 68
    • 5.3.2 团队结构 68
    • 5.3.3 安全 68
    • 5.3.4 技术 68
    • 5.4 杂乱的依赖 69
    • 5.5 数据库 69
    • 5.6 找到问题的关键 69
    • 5.7 例子:打破外键关系 70
    • 5.8 例子:共享静态数据 71
    • 5.9 例子:共享数据 72
    • 5.10 例子:共享表 73
    • 5.11 重构数据库 74
    • 5.12 事务边界 75
    • 5.12.1 再试一次 76
    • 5.12.2 终止整个操作 77
    • 5.12.3 分布式事务 77
    • 5.12.4 应该怎么办呢 78
    • 5.13 报告 78
    • 5.14 报告数据库 78
    • 5.15 通过服务调用来获取数据 80
    • 5.16 数据导出 81
    • 5.17 事件数据导出 82
    • 5.18 数据导出的备份 83
    • 5.19 走向实时 84
    • 5.20 修改的代价 84
    • 5.21 理解根本原因 84
    • 5.22 小结 85
    • 第6 章 部署 86
    • 6.1 持续集成简介 86
    • 6.2 把持续集成映射到微服务 87
    • 6.3 构建流水线和持续交付 90
    • 6.4 平台特定的构建物 91
    • 6.5 操作系统构建物 92
    • 6.6 定制化镜像 93
    • 6.6.1 将镜像作为构建物 94
    • 6.6.2 不可变服务器 95
    • 6.7 环境 95
    • 6.8 服务配置 96
    • 6.9 服务与主机之间的映射 97
    • 6.9.1 单主机多服务 97
    • 6.9.2 应用程序容器 99
    • 6.9.3 每个主机一个服务 100
    • 6.9.4 平台即服务 101
    • 6.10 自动化 101
    • 6.11 从物理机到虚拟机 102
    • 6.11.1 传统的虚拟化技术 103
    • 6.11.2 Vagrant 104
    • 6.11.3 Linux 容器 104
    • 6.11.4 Docker 106
    • 6.12 一个部署接口 107
    • 6.13 小结 109
    • 第7 章 测试 110
    • 7.1 测试类型 110
    • 7.2 测试范围 111
    • 7.2.1 单元测试 112
    • 7.2.2 服务测试 113
    • 7.2.3 端到端测试 114
    • 7.2.4 权衡 114
    • 7.2.5 比例 115
    • 7.3 实现服务测试 115
    • 7.3.1 mock 还是打桩 115
    • 7.3.2 智能的打桩服务 116
    • 7.4 微妙的端到端测试 117
    • 7.5 端到端测试的缺点 118
    • 7.6 脆弱的测试 118
    • 7.6.1 谁来写这些测试 119
    • 7.6.2 测试多长时间 119
    • 7.6.3 大量的堆积 120
    • 7.6.4 元版本 120
    • 7.7 测试场景,而不是故事 121
    • 7.8 拯救消费者驱动的测试 121
    • 7.8.1 Pact 123
    • 7.8.2 关于沟通 124
    • 7.9 还应该使用端到端测试吗 124
    • 7.10 部署后再测试 125
    • 7.10.1 区分部署和上线 125
    • 7.10.2 金丝雀发布 126
    • 7.10.3 平均修复时间胜过平均故障间隔时间 127
    • 7.11 跨功能的测试 128
    • 7.12 小结 129
    • 第8 章 监控 131
    • 8.1 单一服务,单一服务器 132
    • 8.2 单一服务,多个服务器 132
    • 8.3 多个服务,多个服务器 133
    • 8.4 日志,日志,更多的日志 134
    • 8.5 多个服务的指标跟踪 135
    • 8.6 服务指标 135
    • 8.7 综合监控 136
    • 8.8 关联标识 137
    • 8.9 级联 139
    • 8.10 标准化 139
    • 8.11 考虑受众 140
    • 8.12 未来 140
    • 8.13 小结 141
    • 第9 章 安全 143
    • 9.1 身份验证和授权 143
    • 9.1.1 常见的单点登录实现 144
    • 9.1.2 单点登录网关 145
    • 9.1.3 细粒度的授权 146
    • 9.2 服务间的身份验证和授权 146
    • 9.2.1 在边界内允许一切 146
    • 9.2.2 HTTP(S) 基本身份验证 147
    • 9.2.3 使用SAML 或OpenID Connect 148
    • 9.2.4 客户端证书 148
    • 9.2.5 HTTP 之上的HMAC 149
    • 9.2.6 API 密钥 149
    • 9.2.7 代理问题 150
    • 9.3 静态数据的安全 152
    • 9.3.1 使用众所周知的加密算法 152
    • 9.3.2 一切皆与密钥相关 153
    • 9.3.3 选择你的目标 153
    • 9.3.4 按需解密 153
    • 9.3.5 加密备份 153
    • 9.4 深度防御 154
    • 9.4.1 防火墙 154
    • 9.4.2 日志 154
    • 9.4.3 入侵检测(和预防)系统 154
    • 9.4.4 网络隔离 155
    • 9.4.5 操作系统 155
    • 9.5 一个示例 156
    • 9.6 保持节俭 158
    • 9.7 人的因素 158
    • 9.8 黄金法则 158
    • 9.9 内建安全 159
    • 9.10 外部验证 159
    • 9.11 小结 159
    • 第10 章 康威定律和系统设计 161
    • 10.1 证据 161
    • 10.1.1 松耦合组织和紧耦合组织 162
    • 10.1.2 Windows Vista 162
    • 10.2 Netflix 和Amazon 162
    • 10.3 我们可以做什么 163
    • 10.4 适应沟通途径 163
    • 10.5 服务所有权 164
    • 10.6 共享服务的原因 164
    • 10.6.1 难以分割 164
    • 10.6.2 特性团队 164
    • 10.6.3 交付瓶颈 165
    • 10.7 内部开源 166
    • 10.7.1 守护者的角色 166
    • 10.7.2 成熟 166
    • 10.7.3 工具 167
    • 10.8 限界上下文和团队结构 167
    • 10.9 孤儿服务 167
    • 10.10 案例研究:RealEstate.com.au 168
    • 10.11 反向的康威定律 169
    • 10.12 人 170
    • 10.13 小结 170
    • 第11 章 规模化微服务 171
    • 11.1 故障无处不在 171
    • 11.2 多少是太多 172
    • 11.3 功能降级 173
    • 11.4 架构性安全措施 174
    • 11.5 反脆弱的组织 175
    • 11.5.1 超时 176
    • 11.5.2 断路器 176
    • 11.5.3 舱壁 178
    • 11.5.4 隔离 179
    • 11.6 幂等 179
    • 11.7 扩展 180
    • 11.7.1 更强大的主机 181
    • 11.7.2 拆分负载 181
    • 11.7.3 分散风险 181
    • 11.7.4 负载均衡 182
    • 11.7.5 基于worker 的系统 184
    • 11.7.6 重新设计 184
    • 11.8 扩展数据库 185
    • 11.8.1 服务的可用性和数据的持久性 185
    • 11.8.2 扩展读取 185
    • 11.8.2 扩展写操作 186
    • 11.8.4 共享数据库基础设施 187
    • 11.8.5 CQRS 187
    • 11.9 缓存 188
    • 11.9.1 客户端、 代理和服务器端缓存 188
    • 11.9.2 HTTP 缓存 189
    • 11.9.3 为写使用缓存 190
    • 11.9.4 为弹性使用缓存 190
    • 11.9.5 隐藏源服务 191
    • 11.9.6 保持简单 191
    • 11.9.7 缓存中毒:一个警示 192
    • 11.10 自动伸缩 192
    • 11.11 CAP 定理 193
    • 11.11.1 牺牲一致性 194
    • 11.11.2 牺牲可用性 195
    • 11.11.3 牺牲分区容忍性 195
    • 11.11.4 AP 还是CP 196
    • 11.11.5 这不是全部或全不 196
    • 11.11.6 真实世界 197
    • 11.12 服务发现 197
    • 11.13 动态服务注册 199
    • 11.13.1 Zookeeper 199
    • 11.13.2 Consul 200
    • 11.13.4 构造你自己的系统 201
    • 11.13.5 别忘了人 201
    • 11.14 文档服务 201
    • 11.14.1 Swagger 202
    • 11.14.2 HAL 和HAL 浏览器 202
    • 11.15 自描述系统 203
    • 11.16 小结 203
    • 第12 章 总结 204
    • 12.1 微服务的原则 204
    • 12.1.1 围绕业务概念建模 205
    • 12.1.2 接受自动化文化 205
    • 12.1.3 隐藏内部实现细节 205
    • 12.1.4 让一切都去中心化 206
    • 12.1.5 可独立部署 206
    • 12.1.6 隔离失败 206
    • 12.1.7 高度可观察 207
    • 12.2 什么时候你不应该使用微服务 207
    • 12.3 临别赠言 208
    • 关于作者 209
    • 关于封面 209

    上一篇:大型分布式网站架构设计与实践  下一篇:算法

    展开 +

    收起 -

    码小辫二维码
     

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

    Spring Boot 快速搭建微服务框架详细教程

    前言: SpringBoot是为了简化Spring应用的创建、运行、调试、部署等而出现的,使用它可以做到专注于Spring应用的开发,而无需过多关注XML的配置。 简单来说,它提供了一堆依赖打包,并已经按照使用习惯解决了依赖问题---习惯大于约定。 Spring Boot默认使用tomcat作为服务器,使用logback提供日志记录。 Spring Boot的主要优点: 为所有Spring开发者更快的入门 开箱即用,提供各种默认配置来简化项目配置 内嵌式容器简化Web项目 没有冗余代码生成和XML配置的要求 技术栈: Java 8 Maven Spring-boot Mybatis Redis Lombok Swagger2 Jenkins SonarQuber 1、使用Maven构建项目 1.1 通过 SPRING INITIALIZR 工具生产基础项目 通过访问:http://start.spring.io/ 快速创建Spring-boot 的服务框架。 初始化相应信息后,下载压缩包。解压完成后,用IDEA打开项目,项目的目录结构: 总体流程: 访问:http://start.spring.io/ 选择构建工具Maven Project、Spring Boot版本1.3.2以及一些工程基本信息 点击Generate Project下载项目压缩包 解压项目包,并用IDE以Maven项目导入,以IntelliJ IDEA 14为例: 菜单中选择File–New–Project from Existing Sources... 选择解压后的项目文件夹,点击OK 点击Import project from external model并选择Maven,点击Next到底为止。 若你的环境有多个版本的JDK,注意到选择Java SDK的时候请选择Java 7以上……

    网友NO.753302

    浅谈Redis在微服务架构中的几种应用场景

    本文介绍在SpringCloud中使用Redis作为Pub/Sub异步通信、缓存或主数据库和配置服务器的三种场景应用。 Redis可以广泛用于微服务架构。它可能是您应用程序以多种不同方式利用的少数流行软件解决方案之一。根据要求,它可以充当主数据库,缓存或消息代理。虽然它也是一个键/值存储,但我们可以将它用作微服务体系结构中的配置服务器或发现服务器。虽然它通常被定义为内存中的数据结构,但我们也可以在持久模式下运行它。 这里我将向您展示一些使用Redis与Spring Boot和Spring Cloud框架之上构建的微服务的示例。这些应用程序将使用Redis Pub / Sub异步通信,使用R​​edis作为缓存或主数据库,最后使用Redis作为配置服务器。 Redis作为配置服务器 如果您已经使用Spring Cloud构建了微服务,那么您可能对Spring Cloud Config有一些经验。它负责为微服务提供分布式配置模式。 不幸的是,Spring Cloud Config不支持Redis作为属性源的后端存储库。这就是我决定分叉Spring Cloud Config项目并实现此功能的原因。 我希望我的实现很快将被包含在官方的Spring Cloud版本中,但是,现在,您可以使用我的fork repo来运行它。我们怎么用呢?非常简单。让我们来看看。 Spring Boot的当前SNAPSHOT版本2.2.0.BUILD-SNAPSHOT与我们用于Spring Cloud Config的版本相同。在构建Spring Clou……

    网友NO.444421

    SpringCloud微服务架构升级汇总

    一、背景 1.1 应用系统的架构历史 1.2 什么是微服务? 起源:微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”。文中内容提到:微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。 通信方式:每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API)。 微服务的常规定义:微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务。 把原来的一个完整的进程服务,拆分成两个或两个以上的进程服务,且互相之间存在调用关系,与原先单一的进程服务相比,就是“微服务”。(微服务是一个比较级的概念,而不是单一的概念) 1.3 微服务架构的优势 可扩展性:在增加业务功能时,单一应用架构需要在原先架构的代码基础上做比较大的调整,而微服务架构只需要增加新的微服务节点,并调整与之有关联的微服务节点即可。在增加业务响应能力时,单一架构需要进行整体扩容,而微服务架构仅需要扩容响应能力不足的微服务节点。 容错性:在系统发生故障时,单一应用……

    网友NO.772912

    微服务搭建集成Spring Cloud Turbine详解

    1.概述 本文中,我将向你介绍Spring Cloud Netflix Turbine。它将多个Hystrix Metrics Streams 聚合为一个,以便显示在一个仪表板视图中。 简要介绍Hystrix 。 在微服务架构中,我们有许多小应用程序相互通信以完成请求。这些下游服务有可能无法正确响应或完全失败。为了防止发生级联故障,我们为微服务设置了Hystrix回退机制。 每个实现Hystrix的微服务都可以选择公开Hystrix Metrics Streams(通过actuator端点/hystrix.stream),以便通过Hystrix Dashboard查看。 如果您想了解更多信息,我已在Spring Cloud:Hystrix中详细介绍了这一点。 Turbine是Netflix的一个开源工具,用于将多个流聚合到一个流中。 Spring提供了一个很好的包装器,以方便在Spring生态系统中使用。 2.搭建 类似于Spring Cloud:Hystrix的设置,后端服务如下所示: Eureka Server :作为服务注册运行并在端口8761上运行。 推荐服务:一个简单的REST服务,只有一个端点:/recommendations,并在端口8070上运行。 用户服务:一个简单的REST服务,单个端点为:/personalized/{id},并在端口8060上运行。 Hystrix Turbine :Hystrix dashboard服务,用于显示Hystrix流,并在端口'9090'上运行。 以下是我们在Eureka服务器上看到的服务列表: user-service和recommendation-service都实现了Hystrix回退机制,并通过Actuator暴露了/hystrix.stream端点: 用户服……

    Copyright 2018-2019 xz577.com 码农之家

    版权责任说明