出版社: 人民邮电出版社
译者: 崔力强 / 张骏
出版年: 2016-5
页数: 228
定价: 69.00元
装帧: 平装
丛书: 图灵程序设计丛书
ISBN: 9787115420268
内容简介 · · · · · ·
本书全面介绍了微服务的建模、集成、测试、部署和监控,通过一个虚构的公司讲解了如何建立微服务架构。主要内容包括认识微服务在保证系统设计与组织目标统一上的重要性,学会把服务集成到已有系统中,采用递增手段拆分单块大型应用,通过持续集成部署微服务,等等。
作者简介 · · · · · ·
作者简介:
Sam Newman
是ThoughtWorks公司的技术专家、ThoughtWorks内部系统架构师,同时还为全球的客户提供咨询服务。他在开发和IT运维方面与全球多个领域的公司有过合作。
译者简介:
崔力强
阿里巴巴技术专家,目前专注于持续交付相关的产品开发。曾在ThoughtWorks任职多年,从事软件定制开发、敏捷软件开发的相关咨询等工作,帮助过数个团队和项目进行精益需求管理、软件设计、自动化测试和持续集成等实践。微信号:blade_1986
张骏
2010年加入ThoughtWorks公司。作为开发人员、项目经理、资深敏捷教练和资深咨询师,在金融、电信和能源服务行业的大型复杂业务系统的设计、开发、管理、咨询等方面有丰富的经验。曾为国内外诸多客户提供软件设计、开发以及咨询服务。拥有10年工作经验,在Scrum、看板、规模化敏捷等方法...
作者简介:
Sam Newman
是ThoughtWorks公司的技术专家、ThoughtWorks内部系统架构师,同时还为全球的客户提供咨询服务。他在开发和IT运维方面与全球多个领域的公司有过合作。
译者简介:
崔力强
阿里巴巴技术专家,目前专注于持续交付相关的产品开发。曾在ThoughtWorks任职多年,从事软件定制开发、敏捷软件开发的相关咨询等工作,帮助过数个团队和项目进行精益需求管理、软件设计、自动化测试和持续集成等实践。微信号:blade_1986
张骏
2010年加入ThoughtWorks公司。作为开发人员、项目经理、资深敏捷教练和资深咨询师,在金融、电信和能源服务行业的大型复杂业务系统的设计、开发、管理、咨询等方面有丰富的经验。曾为国内外诸多客户提供软件设计、开发以及咨询服务。拥有10年工作经验,在Scrum、看板、规模化敏捷等方法论,以及精益需求管理、自动化测试、持续集成、领域驱动设计、微服务等具体实践方面都有丰富的积累。微信号:zhangjun695339
目录 · · · · · ·
第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.3 扩展写操作 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
· · · · · · (收起)
原文摘录 · · · · · · ( 全部 )
-
聚在一起,就如何做事情达成共识是一个好主意。但是,花时间保证人们按照这个共识来做事情就没那么有趣了,因为在各个服务中使用这些标准做法会成为开发人员的负担。我坚信应该使用简单的方式把事情做对。我见过比较奏效的两种方式是,提供范例和服务代码模板。 (查看原文) —— 引自章节:代码治理 -
编写文档是有用的,... 但是开发人员更喜欢可以查看和运行的代码。 创建服务代码模板不是某个中心化工具的职责,也不是指导我们应怎样工作的架构团队的职责。应该通过合作的方式定义出这些实践,所以你的团队也需要负责更新这个模板。 我也见过一个团队的士气和生产力是如何被强制使用的框架给毁掉的。基于代码重用的目的,越来越多的功能被加入到一个中心化的框架中,直到把这个框架变成一个不堪重负的怪兽。 你还需要知道,重用代码可能引入的危险。在重用代码的驱动下,我们可能会引入服务之间的耦合。... 一些我接触过的团队,把服务代码模板简单地做成了一个共享的库依赖,这时他们就要非常小心地防止对 DRY 的追求导致系统过度耦合。 (查看原文) —— 引自章节:代码治理
> 全部原文摘录
丛书信息
喜欢读"微服务设计"的人也喜欢的电子书 · · · · · ·
喜欢读"微服务设计"的人也喜欢 · · · · · ·
微服务设计的书评 · · · · · · ( 全部 20 条 )


微服务构建的入门指南之书
> 更多书评 20篇
-
红色有角F叔 (勇敢困难 不怕牛牛)
这个组织逐渐决定对团队进行扩容,增加了一个巴西团队来分担一部分工作。系统被划分成两部分,一部分面向前端,该部分不保存任何状态,如图 3-4 所示;后端部分就是一个简单的数据存储,通过 RPC 提供服务。基本上你可以理解为,把一个代码库中的仓储层变成了一个独立的服务。 后来发现,需要频繁地同时修改两个服务。两个服务都是偏底层的、RPC 风格的方法调用,而这是非常不稳定的。这个服务接口也很繁琐,会导致性能问题。这...2016-06-09 14:33:03
-
红色有角F叔 (勇敢困难 不怕牛牛)
聚在一起,就如何做事情达成共识是一个好主意。但是,花时间保证人们按照这个共识来做事情就没那么有趣了,因为在各个服务中使用这些标准做法会成为开发人员的负担。我坚信应该使用简单的方式把事情做对。我见过比较奏效的两种方式是,提供范例和服务代码模板。 编写文档是有用的,... 但是开发人员更喜欢可以查看和运行的代码。 创建服务代码模板不是某个中心化工具的职责,也不是指导我们应怎样工作的架构团队的职责。应该通...2016-06-09 11:49:40
聚在一起,就如何做事情达成共识是一个好主意。但是,花时间保证人们按照这个共识来做事情就没那么有趣了,因为在各个服务中使用这些标准做法会成为开发人员的负担。我坚信应该使用简单的方式把事情做对。我见过比较奏效的两种方式是,提供范例和服务代码模板。 引自 代码治理 编写文档是有用的,... 但是开发人员更喜欢可以查看和运行的代码。 创建服务代码模板不是某个中心化工具的职责,也不是指导我们应怎样工作的架构团队的职责。应该通过合作的方式定义出这些实践,所以你的团队也需要负责更新这个模板。 我也见过一个团队的士气和生产力是如何被强制使用的框架给毁掉的。基于代码重用的目的,越来越多的功能被加入到一个中心化的框架中,直到把这个框架变成一个不堪重负的怪兽。 你还需要知道,重用代码可能引入的危险。在重用代码的驱动下,我们可能会引入服务之间的耦合。... 一些我接触过的团队,把服务代码模板简单地做成了一个共享的库依赖,这时他们就要非常小心地防止对 DRY 的追求导致系统过度耦合。 引自 代码治理 回应 2016-06-09 11:49:40 -
优雅的刺猬 (自娱自乐的段子手)
你通常难以完全控制遗留系统和COTS平台,所以当你使用它们时要考虑如果需要移除或者绕过它们的话,应该如何操作。一个有用的模式叫作绞杀者模式( Strangler Application Pattern,hp/ martinfowler.com/bliki/Stranglerapplication.html)。与在CMS系统前面套一层自己的代码非常类似,绞杀者可以捕获并拦截对老系统的调用。这里你就可以决定,是把这些调用路由到现存的遗留代码中还是导向新写的代码中。这种方式可以帮助我们逐...2022-01-04 15:55:51
你通常难以完全控制遗留系统和COTS平台,所以当你使用它们时要考虑如果需要移除或者绕过它们的话,应该如何操作。一个有用的模式叫作绞杀者模式( Strangler Application Pattern,hp/ martinfowler.com/bliki/Stranglerapplication.html)。与在CMS系统前面套一层自己的代码非常类似,绞杀者可以捕获并拦截对老系统的调用。这里你就可以决定,是把这些调用路由到现存的遗留代码中还是导向新写的代码中。这种方式可以帮助我们逐步对老系统进行替换,从而避免影响过大的重写。 在微服务的上下文中,通常不会使用单一的单块应用来拦截所有对已有遗留系统的调用,相反你可能会使用一系列的微服务来实施这些拦截。在这种情况下,捕获并重定向这些原始调用可能会变得更加复杂,可能需要使用一个代理来为你做这些事情。 引自 4.15.5 绞杀者模式 64 回应 2022-01-04 15:55:51
-
Thinker Wu (技术就是信仰!志在终身探索!)
-
Thinker Wu (技术就是信仰!志在终身探索!)
微服务可以帮助我们更快地采用新技术,并且理解这些新技术的好处。尝试新技术通常伴随着风险,这使得很多人望而却步。 Netflix和Twitter选用的技术大多基于JVM(Java Virtual Machine,Java虚拟机),因为他们非常了解该平台的稳定性和性能。他们还在JVM上开发了一些库和工具,使得大规模运维变得更加容易,但这同时也使得我们更难以采用Java外的其他技术来编写服务和客户端。2016-05-10 10:57:27
-
优雅的刺猬 (自娱自乐的段子手)
你通常难以完全控制遗留系统和COTS平台,所以当你使用它们时要考虑如果需要移除或者绕过它们的话,应该如何操作。一个有用的模式叫作绞杀者模式( Strangler Application Pattern,hp/ martinfowler.com/bliki/Stranglerapplication.html)。与在CMS系统前面套一层自己的代码非常类似,绞杀者可以捕获并拦截对老系统的调用。这里你就可以决定,是把这些调用路由到现存的遗留代码中还是导向新写的代码中。这种方式可以帮助我们逐...2022-01-04 15:55:51
你通常难以完全控制遗留系统和COTS平台,所以当你使用它们时要考虑如果需要移除或者绕过它们的话,应该如何操作。一个有用的模式叫作绞杀者模式( Strangler Application Pattern,hp/ martinfowler.com/bliki/Stranglerapplication.html)。与在CMS系统前面套一层自己的代码非常类似,绞杀者可以捕获并拦截对老系统的调用。这里你就可以决定,是把这些调用路由到现存的遗留代码中还是导向新写的代码中。这种方式可以帮助我们逐步对老系统进行替换,从而避免影响过大的重写。 在微服务的上下文中,通常不会使用单一的单块应用来拦截所有对已有遗留系统的调用,相反你可能会使用一系列的微服务来实施这些拦截。在这种情况下,捕获并重定向这些原始调用可能会变得更加复杂,可能需要使用一个代理来为你做这些事情。 引自 4.15.5 绞杀者模式 64 回应 2022-01-04 15:55:51 -
优雅的刺猬 (自娱自乐的段子手)
如果你正在阅读此书,那么你很有可能工作在一个需要写代码的组织中。你可能为内部或者外部的用户编写软件,或者两者皆有。不管怎样,即使你所在的组织拥有很强的定制化软件开发的能力,你还是需要外部组织提供的商业或者开源软件产品。为什么会这样呢? 第一,你的组织对软件的需求几不可能完全由内部满足。考虑你使用的所有产品,从类似 Excel的办公自动化工具到操作系统,再到工资系统。自己创建所有这些产品的工作量是巨大的...2022-01-04 15:50:27
如果你正在阅读此书,那么你很有可能工作在一个需要写代码的组织中。你可能为内部或者外部的用户编写软件,或者两者皆有。不管怎样,即使你所在的组织拥有很强的定制化软件开发的能力,你还是需要外部组织提供的商业或者开源软件产品。为什么会这样呢? 第一,你的组织对软件的需求几不可能完全由内部满足。考虑你使用的所有产品,从类似 Excel的办公自动化工具到操作系统,再到工资系统。自己创建所有这些产品的工作量是巨大的。第二,也是最重要的一点是,这样做非常低效!自己构建邮件系统的代价要远远大于使用现成的工具,即使选用的是商业工具。 我的客户经常纠结这样的问题:“应该自己做,还是买?”一般来讲,我和同事的建议是,对于一般规模的组织来说,如果某个软件非常特殊,并且它是你的战略性资产的话,那就自己构建;如果不是这么特别的话,那就购买。 引自 4.15 与第三方软件集成 61 回应 2022-01-04 15:50:27 -
优雅的刺猬 (自娱自乐的段子手)
如果一个客户端能够仅仅通过査看服务的版本号,就知道它是否能够与之进行集成,那就太棒了!语义化版本管理(htup/ /server.org)就是一种能够支持这种方式的规格说明。语义化版本管理的每一个版本号都遵循这样的格式:MAJOR.MINOR.PATCH。其中MAJOR的改变意味着其中包含向后不兼容的修改; MINOR的改变意味着有新功能的增加,但应该是向后兼容的;最后, PATCH的改变代表对已有功能的缺陷修复。 为了更好地理解语义化版本管理...2022-01-04 15:34:11
如果一个客户端能够仅仅通过査看服务的版本号,就知道它是否能够与之进行集成,那就太棒了!语义化版本管理(htup/ /server.org)就是一种能够支持这种方式的规格说明。语义化版本管理的每一个版本号都遵循这样的格式:MAJOR.MINOR.PATCH。其中MAJOR的改变意味着其中包含向后不兼容的修改; MINOR的改变意味着有新功能的增加,但应该是向后兼容的;最后, PATCH的改变代表对已有功能的缺陷修复。 为了更好地理解语义化版本管理,让我们来看一个简单的用例。帮助台应用能够与1.2.0版本的客户服务一起使用。如果新功能的增加引起了客户服务的版本变成了1.3.0,那么帮助台应用不应该看到任何行为的变化,并且自身也不需要做任何改动。由于当前的客户端可能会依赖于在1.2.0版本中新加入的功能,所以不能保证,现在的版本可以和1.1.0版本的客户服务一起工作。当客户服务升级到2.0.0版本时,本地应用程序应该也需要做相应的修改。 引自 4.11 微服务世界中的DRY和代码重用的危险 49 回应 2022-01-04 15:34:11 -
优雅的刺猬 (自娱自乐的段子手)
客户端尽可能灵活地消费服务响应这一点符合 Postel法则(也叫作鲁棒性原则,htps tools。 ietf。 org/html/rfc761)。该法则认为,系统中的每个模块都应该“宽进严出”,即对自己发送的东西要严格,对接收的东西则要宽容。这个原则最初的上下文是网络设备之间的交互,因为在这个场景中,所有奇怪的事情都有可能发生。在请求/响应的场景下,该原则可以帮助我们在服务发生改变时,减少消费方的修改。2022-01-04 15:31:30
论坛 · · · · · ·
大咖经验分享,十足干货 | 来自莫冲 | 2016-12-02 18:43:37 |
当前版本有售 · · · · · ·
-
每满100-50
这本书的其他版本 · · · · · · ( 全部4 )
-
O'Reilly Media (2014)7.9分 114人读过
-
O'Reilly Media (2021)暂无评分 10人读过
-
歐萊禮 (2016)暂无评分
以下书单推荐 · · · · · · ( 全部 )
- 3.服务器端技术 (葡萄)
- Web Developer SkillStack 2017 (Chain)
- 我偶然看到2 (明生)
- 架构师之路 (仰望星空)
- 2016年读书列表 (姜文广)
谁读这本书?
二手市场
订阅关于微服务设计的评论:
feed: rss 2.0
0 有用 fanko24 2019-09-23 08:52:39
架构
3 有用 嘉陵 2016-05-14 16:43:33
微服务并不神秘,只是用了一个新词解释已经存在的事物。
0 有用 XDash 2020-04-22 10:32:03
原作者逻辑混乱,且代码演示太少空讲概念;中文版的翻译也是灾难。
8 有用 贾里 2016-06-03 13:33:50
理清了一些模糊的概念。但再次确认一个道理:没有银弹!
1 有用 君泓 2016-06-11 15:21:52
很有用的方法论
0 有用 D 2022-08-02 00:59:26
差强人意
0 有用 mov $1 %eax 2022-07-25 22:35:57
虽然有点过时,好在讲的很清楚很多compliance要求为什么要这么做。除了今天大家都选择的一些技术外,还有些什么别的方法,为什么会这么演化。microservices有哪些是一定要注意的concept。
0 有用 okfine 2022-06-30 14:09:48
印象中是2018年底实习回学校的路上读的。
0 有用 gzhh 2022-06-20 15:56:37
快速看了一遍,主要是微服务系统设计的方法论。
0 有用 夜想曲 2022-03-24 20:41:57
读的第一本架构方面的书。由于工作上用golang实现微服务,就抽几天空闲时间认真看完这薄薄200多页,读完收获挺多。 微服务工程上的划分,集成,部署,测试,规模化,安全,监控,扩展等,面面俱到。几天读完就自己找方案实现了个集中式日志处理系统,之后计划要整个统一标识,链路跟踪,持续集成与交付.....等等。总之就是发现我还需要不少技能点,成功解锁不少新方向。 这里简单标记下几个作者引出的,看起来不错... 读的第一本架构方面的书。由于工作上用golang实现微服务,就抽几天空闲时间认真看完这薄薄200多页,读完收获挺多。 微服务工程上的划分,集成,部署,测试,规模化,安全,监控,扩展等,面面俱到。几天读完就自己找方案实现了个集中式日志处理系统,之后计划要整个统一标识,链路跟踪,持续集成与交付.....等等。总之就是发现我还需要不少技能点,成功解锁不少新方向。 这里简单标记下几个作者引出的,看起来不错的,经典的参考书目。 《持续交付》、《企业集成模式》、《REST实战》、《数据库重构》、《领域驱动设计》、《修改代码的艺术》、《测试驱动的面向对象软件开发》、《敏捷软件测试(Lisa Crispin)》、《Scum敏捷软件开发》、《反脆弱》、《Release It!》。 (展开)