4.8 用户推荐指数
互联网
类型
8.1
豆瓣评分
可以朗读
语音朗读
188千字
字数
2018-05-01
发行日期
展开全部
主编推荐语
本书通过大量的例子，全面讨论了系统架构师和管理员在构建、管理和演化微服务架构时必须考虑的问题，并给出了实用的建议。
内容简介
本书全面介绍了微服务的建模、集成、测试、部署和监控，通过一个虚构的公司讲解了如何建立微服务架构。主要内容包括认识微服务在保证系统设计与组织目标统一上的重要性，学会把服务集成到已有系统中，采用递增手段拆分单块大型应用，通过持续集成部署微服务，等等。
目录
- 版权信息
- 版权声明
- O'Reilly Media, Inc. 介绍
- 业界评论
- 前言
- 谁该读这本书
- 为什么写这本书
- 当今的微服务
- 本书结构
- 排版约定
- Safari® Books Online
- 联系我们
- 致谢
- 第1章 微服务
- 1.1 什么是微服务
- 1.1.1 很小，专注于做好一件事
- 1.1.2 自治性
- 1.2 主要好处
- 1.2.1 技术异构性
- 1.2.2 弹性
- 1.2.3 扩展
- 1.2.4 简化部署
- 1.2.5 与组织结构相匹配
- 1.2.6 可组合性
- 1.2.7 对可替代性的优化
- 1.3 面向服务的架构
- 1.4 其他分解技术
- 1.4.1 共享库
- 1.4.2 模块
- 1.5 没有银弹
- 1.6 小结
- 第2章 演化式架构师
- 2.1 不准确的比较
- 2.2 架构师的演化视角
- 2.3 分区
- 2.4 一个原则性的方法
- 2.4.1 战略目标
- 2.4.2 原则
- 2.4.3 实践
- 2.4.4 将原则和实践相结合
- 2.4.5 真实世界的例子
- 2.5 要求的标准
- 2.5.1 监控
- 2.5.2 接口
- 2.5.3 架构安全性
- 2.6 代码治理
- 2.6.1 范例
- 2.6.2 裁剪服务代码模板
- 2.7 技术债务
- 2.8 例外管理
- 2.9 集中治理和领导
- 2.10 建设团队
- 2.11 小结
- 第3章 如何建模服务
- 3.1 MusicCorp简介
- 3.2 什么样的服务是好服务
- 3.2.1 松耦合
- 3.2.2 高内聚
- 3.3 限界上下文
- 3.3.1 共享的隐藏模型
- 3.3.2 模块和服务
- 3.3.3 过早划分
- 3.4 业务功能
- 3.5 逐步划分上下文
- 3.6 关于业务概念的沟通
- 3.7 技术边界
- 3.8 小结
- 第4章 集成
- 4.1 寻找理想的集成技术
- 4.1.1 避免破坏性修改
- 4.1.2 保证API的技术无关性
- 4.1.3 使你的服务易于消费方使用
- 4.1.4 隐藏内部实现细节
- 4.2 为用户创建接口
- 4.3 共享数据库
- 4.4 同步与异步
- 4.5 编排与协同
- 4.6 远程过程调用
- 4.6.1 技术的耦合
- 4.6.2 本地调用和远程调用并不相同
- 4.6.3 脆弱性
- 4.6.4 RPC很糟糕吗
- 4.7 REST
- 4.7.1 REST和HTTP
- 4.7.2 超媒体作为程序状态的引擎
- 4.7.3 JSON、XML还是其他
- 4.7.4 留心过多的约定
- 4.7.5 基于HTTP的REST的缺点
- 4.8 实现基于事件的异步协作方式
- 4.8.1 技术选择
- 4.8.2 异步架构的复杂性
- 4.9 服务即状态机
- 4.10 响应式扩展
- 4.11 微服务世界中的DRY和代码重用的危险
- 客户端库
- 4.12 按引用访问
- 4.13 版本管理
- 4.13.1 尽可能推迟
- 4.13.2 及早发现破坏性修改
- 4.13.3 使用语义化的版本管理
- 4.13.4 不同的接口共存
- 4.13.5 同时使用多个版本的服务
- 4.14 用户界面
- 4.14.1 走向数字化
- 4.14.2 约束
- 4.14.3 API组合
- 4.14.4 UI片段的组合
- 4.14.5 为前端服务的后端
- 4.14.6 一种混合方式
- 4.15 与第三方软件集成
- 4.15.1 缺乏控制
- 4.15.2 定制化
- 4.15.3 意大利面式的集成
- 4.15.4 在自己可控的平台进行定制化
- 4.15.5 绞杀者模式
- 4.16 小结
- 第5章 分解单块系统
- 5.1 关键是接缝
- 5.2 分解MusicCorp
- 5.3 分解单块系统的原因
- 5.3.1 改变的速度
- 5.3.2 团队结构
- 5.3.3 安全
- 5.3.4 技术
- 5.4 杂乱的依赖
- 5.5 数据库
- 5.6 找到问题的关键
- 5.7 例子：打破外键关系
- 5.8 例子：共享静态数据
- 5.9 例子：共享数据
- 5.10 例子：共享表
- 5.11 重构数据库
- 实施分离
- 5.12 事务边界
- 5.12.1 再试一次
- 5.12.2 终止整个操作
- 5.12.3 分布式事务
- 5.12.4 应该怎么办呢
- 5.13 报表
- 5.14 报表数据库
- 5.15 通过服务调用来获取数据
- 5.16 数据导出
- 另一个方向
- 5.17 事件数据导出
- 5.18 数据导出的备份
- 5.19 走向实时
- 5.20 修改的代价
- 5.21 理解根本原因
- 5.22 小结
- 第6章 部署
- 6.1 持续集成简介
- 你真的在做CI吗
- 6.2 把持续集成映射到微服务
- 6.3 构建流水线和持续交付
- 不可避免的例外
- 6.4 平台特定的构建物
- 6.5 操作系统构建物
- 6.6 定制化镜像
- 6.6.1 将镜像作为构建物
- 6.6.2 不可变服务器
- 6.7 环境
- 6.8 服务配置
- 6.9 服务与主机之间的映射
- 6.9.1 单主机多服务
- 6.9.2 应用程序容器
- 6.9.3 每个主机一个服务
- 6.9.4 平台即服务
- 6.10 自动化
- 关于自动化好处的两个案例研究
- 6.11 从物理机到虚拟机
- 6.11.1 传统的虚拟化技术
- 6.11.2 Vagrant
- 6.11.3 Linux容器
- 6.11.4 Docker
- 6.12 一个部署接口
- 环境定义
- 6.13 小结
- 第7章 测试
- 7.1 测试类型
- 7.2 测试范围
- 7.2.1 单元测试
- 7.2.2 服务测试
- 7.2.3 端到端测试
- 7.2.4 权衡
- 7.2.5 比例
- 7.3 实现服务测试
- 7.3.1 mock还是打桩
- 7.3.2 智能的打桩服务
- 7.4 微妙的端到端测试
- 7.5 端到端测试的缺点
- 7.6 脆弱的测试
- 7.6.1 谁来写这些测试
- 7.6.2 测试多长时间
- 7.6.3 大量的堆积
- 7.6.4 元版本
- 7.7 测试场景，而不是故事
- 7.8 拯救我们的消费者驱动的测试
- 7.8.1 Pact
- 7.8.2 关于沟通
- 7.9 还应该使用端到端测试吗
- 7.10 部署后再测试
- 7.10.1 区分部署和上线
- 7.10.2 金丝雀发布
- 7.10.3 平均修复时间胜过平均故障间隔时间
- 7.11 跨功能的测试
- 性能测试
- 7.12 小结
- 第8章 监控
- 8.1 单一服务，单一服务器
- 8.2 单一服务，多个服务器
- 8.3 多个服务，多个服务器
- 8.4 日志，日志，更多的日志
- 8.5 多个服务的指标跟踪
- 8.6 服务指标
- 8.7 综合监控
- 实现语义监控
- 8.8 关联标识
- 8.9 级联
- 8.10 标准化
- 8.11 考虑受众
- 8.12 未来
- 8.13 小结
- 第9章 安全
- 9.1 身份验证和授权
- 9.1.1 常见的单点登录实现
- 9.1.2 单点登录网关
- 9.1.3 细粒度的授权
- 9.2 服务间的身份验证和授权
- 9.2.1 在边界内允许一切
- 9.2.2 HTTP(S)基本身份验证
- 9.2.3 使用SAML或OpenID Connect
- 9.2.4 客户端证书
- 9.2.5 HTTP之上的HMAC
- 9.2.6 API密钥
- 9.2.7 代理问题
- 9.3 静态数据的安全
- 9.3.1 使用众所周知的加密算法
- 9.3.2 一切皆与密钥相关
- 9.3.3 选择你的目标
- 9.3.4 按需解密
- 9.3.5 加密备份
- 9.4 深度防御
- 9.4.1 防火墙
- 9.4.2 日志
- 9.4.3 入侵检测（和预防）系统
- 9.4.4 网络隔离
- 9.4.5 操作系统
- 9.5 一个示例
- 9.6 保持节俭
- 9.7 人的因素
- 9.8 黄金法则
- 9.9 内建安全
- 9.10 外部验证
- 9.11 小结
- 第10章 康威定律和系统设计
- 10.1 证据
- 10.1.1 松耦合组织和紧耦合组织
- 10.1.2 Windows Vista
- 10.2 Netflix和Amazon
- 10.3 我们可以做什么
- 10.4 适应沟通途径
- 10.5 服务所有权
- 10.6 共享服务的原因
- 10.6.1 难以分割
- 10.6.2 特性团队
- 10.6.3 交付瓶颈
- 10.7 内部开源
- 10.7.1 守护者的角色
- 10.7.2 成熟
- 10.7.3 工具
- 10.8 限界上下文和团队结构
- 10.9 孤儿服务
- 10.10 案例研究：RealEstate.com.au
- 10.11 反向的康威定律
- 10.12 人
- 10.13 小结
- 第11章 规模化微服务
- 11.1 故障无处不在
- 11.2 多少是太多
- 11.3 功能降级
- 11.4 架构性安全措施
- 11.5 反脆弱的组织
- 11.5.1 超时
- 11.5.2 断路器
- 11.5.3 舱壁
- 11.5.4 隔离
- 11.6 幂等
- 11.7 扩展
- 11.7.1 更强大的主机
- 11.7.2 拆分负载
- 11.7.3 分散风险
- 11.7.4 负载均衡
- 11.7.5 基于worker的系统
- 11.7.6 重新设计
- 11.8 扩展数据库
- 11.8.1 服务的可用性和数据的持久性
- 11.8.2 扩展读取
- 11.8.3 扩展写操作
- 11.8.4 共享数据库基础设施
- 11.8.5 CQRS
- 11.9 缓存
- 11.9.1 客户端、代理和服务器端缓存
- 11.9.2 HTTP缓存
- 11.9.3 为写使用缓存
- 11.9.4 为弹性使用缓存
- 11.9.5 隐藏源服务
- 11.9.6 保持简单
- 11.9.7 缓存中毒：一个警示
- 11.10 自动伸缩
- 11.11 CAP定理
- 11.11.1 牺牲一致性
- 11.11.2 牺牲可用性
- 11.11.3 牺牲分区容忍性
- 11.11.4 AP还是CP
- 11.11.5 这不是全部或全不
- 11.11.6 真实世界
- 11.12 服务发现
- DNS
- 11.13 动态服务注册
- 11.13.1 Zookeeper
- 11.13.2 Consul
- 11.13.3 Eureka
- 11.13.4 构造你自己的系统
- 11.13.5 别忘了人
- 11.14 文档服务
- 11.14.1 Swagger
- 11.14.2 HAL和HAL浏览器
- 11.15 自描述系统
- 11.16 小结
- 第12章 总结
- 12.1 微服务的原则
- 12.1.1 围绕业务概念建模
- 12.1.2 接受自动化文化
- 12.1.3 隐藏内部实现细节
- 12.1.4 让一切都去中心化
- 12.1.5 可独立部署
- 12.1.6 隔离失败
- 12.1.7 高度可观察
- 12.2 什么时候你不应该使用微服务
- 12.3 临别赠言
- 关于作者
- 关于封面
- 看完了
展开全部
评分及书评
4.8
4个评分
给这本书评了5.0读本书后获得以下几点收获：一、架构师应该像城市规划师那样专注在大方向上，我们需要保证系统不但能够满足当前的需求，还能够应对将来的变化。而且他们还应该保证在这个系统上工作的开发人员要和使用这个系统的用户一样开心。(作为架构师，不应该过多关注每个区域内发生的事情，而应该多关注区域之间的事情。这意味着我们应该考虑不同服务之间如何交互，或者说保证我们能够对整个系统的健康状况进行监控。) 二、微服务设计原则 1、围绕业务概念建模；2、接受自动化文化；3、隐藏内部实现细节；4、让一切都去中心化；5、高度可观察；
给这本书评了5.0微服务的精髓，就是促进小而自治、专注、协同，支持持续演进。是应业务和技术快速进化带来的高效交付实现要求而自然衍生的一种架构实践。讲了很多，底层还是对低耦合高内聚、自动化、可观察的极致性追求。
给这本书评了5.0微服务是一种分布式系统解决方案，推动细粒度服务的使用，这些服务协同工作，且每个服务都有自己的生命周期。因为微服务主要围绕业务领域建模，所以避免了由传统的分层架构引发的很多问题。微服务也整合了过去十年来的新概念和技术，因此得以避开许多面向服务的架构中的陷阱。
出版方
人民邮电出版社·图灵出品
图灵社区成立于2005年6月，由人民邮电出版社投资控股，以策划出版高质量的科技书籍为核心业务，主要出版领域包括计算机、电子电气、数学统计、科普等，通过引进国际高水平的教材、专著，以及发掘国内优秀原创作品等途径，为目标读者提供一流的内容。
