微服务成功启示录
宋奕兴, 娄麒麟, 葛灿, 赵正阳 译
出版时间：2025年09月
页数：476
“这是一本出色的参考书，能够帮助你了解在小型且被充分授权的团队中，实现‘快速工作流’模式时会遇到的情况。对于任何具有前瞻性的组织来说，这都是必读之作。”
——Matthew Skelton
《团队拓扑学》联合作者，Conflux CE
微服务是一种极具效能的架构模式，可以为组织和客户创造价值。如果使用得当，微服务可以让你每天都对系统的不同部分进行数百次变更，从而加速交付。但如果处理不当，微服务只会让整个系统变得更加复杂。
在本书中，资深技术领导者 Sarah Wells 提供了实用且深入的建议，帮助组织顺利迁移到微服务架构。早在2013年，她便在《金融时报》率先构建了微服务架构，并在此过程中积累了丰富的实践经验。她将在书中分享从零开始构建微服务时需要采取的方法，并揭示可能会让你陷入困境的常见问题。此外，你还将学习如何在系统逐步成熟的过程中维护架构，同时尽量减少维护和支持的成本。
通过本书，你将学到：
● 微服务对软件开发模式和实践的影响。
● 成功构建和运行微服务架构所需的组织变革。
● 在迁移到微服务之前必须完成的关键步骤。
● 设计微服务架构时需要避免的陷阱，以及如何从错误中恢复。
——Matthew Skelton
《团队拓扑学》联合作者，Conflux CE
微服务是一种极具效能的架构模式，可以为组织和客户创造价值。如果使用得当，微服务可以让你每天都对系统的不同部分进行数百次变更，从而加速交付。但如果处理不当，微服务只会让整个系统变得更加复杂。
在本书中，资深技术领导者 Sarah Wells 提供了实用且深入的建议，帮助组织顺利迁移到微服务架构。早在2013年，她便在《金融时报》率先构建了微服务架构，并在此过程中积累了丰富的实践经验。她将在书中分享从零开始构建微服务时需要采取的方法，并揭示可能会让你陷入困境的常见问题。此外，你还将学习如何在系统逐步成熟的过程中维护架构，同时尽量减少维护和支持的成本。
通过本书，你将学到：
● 微服务对软件开发模式和实践的影响。
● 成功构建和运行微服务架构所需的组织变革。
● 在迁移到微服务之前必须完成的关键步骤。
● 设计微服务架构时需要避免的陷阱，以及如何从错误中恢复。
- 序
- 前言
- 第一部分 背景认知
- 第1章 理解微服务
- 1.1 微服务架构风格
- 1.1.1 服务集合
- 1.1.2 独立进程运行
- 1.1.3 轻量级通信机制
- 1.1.4 围绕业务能力构建
- 1.1.5 可独立部署
- 1.1.6 “Small”小型化
- 1.1.7 最小化集中管理
- 1.1.8 技术异构性
- 1.2 前驱方案与替代选项
- 1.2.1 单体架构
- 1.2.2 模块化单体架构
- 1.2.3 面向服务的架构
- 1.3 微服务生态系统
- 1.3.1 基础设施即代码
- 1.3.2 持续交付
- 1.3.3 公有云
- 1.3.4 新型部署模式
- 1.3.5 开发运维一体化（DevOps）
- 1.3.6 可观测性
- 1.4 微服务优势
- 1.4.1 独立可扩展
- 1.4.2 健壮性
- 1.4.3 小步快频，轻松发布
- 1.4.4 灵活的技术选型
- 1.5 微服务架构的挑战
- 1.5.1 网络延迟
- 1.5.2 技术资产复杂性
- 1.5.3 运维复杂性
- 1.5.4 数据一致性
- 1.5.5 安全
- 1.5.6 服务粒度的把控
- 1.5.7 变更管理
- 1.5.8 需要组织层面的调整
- 1.5.9 改变开发者体验
- 1.6 小结
- 第2章 高效软件交付
- 2.1 定期交付业务价值
- 2.1.1 高部署频率
- 2.1.2 缩短交付周期
- 2.1.3 进行实验
- 2.1.4 代码部署与功能发布分离
- 2.1.5 跨团队协作的架构管理
- 2.2 适应需求优先级变化
- 2.3 维持适当的服务水平
- 2.3.1 当发布出现问题时
- 2.3.2 及时感知核心服务故障
- 2.3.3 实现服务能力的快速局部恢复
- 2.3.4 避免故障连锁反应
- 2.4 专注于核心价值工作
- 2.5 避免从头再来
- 2.6 风险管理：维持在可控范围内
- 2.7 微服务架构适用性评估
- 2.8 小结
- 第3章 微服务是否合适
- 3.1 选择微服务的原因
- 3.1.1 应用组织规模扩张
- 3.1.2 开发者体验
- 3.1.3 隔离合规安全敏感业务模块
- 3.1.4 负载扩展
- 3.1.5 提高鲁棒性
- 3.1.6 提高灵活性
- 3.2 成功前提
- 3.2.1 领域认知
- 3.2.2 产品而非项目
- 3.2.3 领导层支持
- 3.2.4 追求自主权的团队
- 3.2.5 实现自主性的流程
- 3.2.6 技术成熟度
- 3.3 变革管理
- 3.4 坚持采用单体架构
- 3.4.1 实现零停机部署
- 3.4.2 构建模块化单体架构
- 3.5 分布式架构已成常态
- 3.5.1 云原生的崛起
- 3.5.2 意义重大
- 3.6 建议
- 3.6.1 从零开始
- 3.6.2 替换现有单体
- 3.6.3 衡量成功
- 3.7 小结
- 第二部分 组织架构与文化
- 第4章 康威定律与寻找合适的边界
- 4.1 康威定律
- 4.2 逆向康威策略
- 4.3 潜在边界划分方案
- 4.3.1 业务领域
- 4.3.2 地点
- 4.3.3 技术
- 4.3.4 合规性
- 4.3.5 失败容忍度
- 4.3.6 变更频率
- 4.3.7 建议
- 4.4 识别边界划分错误
- 4.5 小结
- 第5章 建立高效团队
- 5.1 组织文化
- 5.1.1 开放
- 5.1.2 学习
- 5.1.3 授权
- 5.1.4 面向变化的优化
- 5.1.5 韦斯特鲁姆模型
- 5.2 高效团队
- 5.2.1 通过自主性、精通度和目标感来激励
- 5.2.2 与业务领域对齐
- 5.2.3 合理的规模
- 5.2.4 跨职能和T 型
- 5.2.5 强所有权
- 5.2.6 持久性
- 5.2.7 可持续认知负荷
- 5.2.8 高信任度和高心理安全感
- 5.2.9 团队构成
- 5.3 优化流程
- 5.3.1 流对齐团队
- 5.3.2 赋能团队
- 5.3.3 复杂子系统团队
- 5.3.4 平台团队
- 5.4 小结
- 第6章 打造自主团队
- 6.1 什么是自主性
- 6.1.1 自主性为什么重要
- 6.1.2 自主性的限制
- 6.2 适度沟通
- 6.3 互动类型
- 6.3.1 协作型
- 6.3.2 服务型
- 6.3.3 促进型
- 6.4 支持自主性的工作方式
- 6.4.1 对齐目标
- 6.4.2 轻量化治理
- 6.4.3 信任但要验证
- 6.4.4 在技术上达成一致
- 6.4.5 个人贡献者角色
- 6.4.6 最小可行能力
- 6.4.7 创造学习空间
- 6.5 自主团队的责任
- 6.5.1 积极所有权
- 6.5.2 沟通与合作
- 6.5.3 遵守标准
- 6.5.4 维护一个团队页面
- 6.6 小结
- 第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 供应商工程
- 7.3.2 API, 模板，标准库和示例
- 7.3.3 服务目录
- 7.3.4 洞察力
- 7.4 设置预设路径
- 7.4.1 包含的能力
- 7.4.2 可选的意义
- 7.4.3 保持小规模
- 7.4.4 如何偏离预设路径
- 7.4.5 将宝藏带回平台
- 7.4.6 内部开发者门户
- 7.5 打造实用平台
- 7.5.1 确保需求被满足
- 7.5.2 营销我们的产品
- 7.5.3 留意问题的出现迹象
- 7.6 构建预设路径的核心原则
- 7.6.1 可选的
- 7.6.2 有价值的
- 7.6.3 自助的
- 7.6.4 被支持的
- 7.6.5 易用的
- 7.6.6 具有指导性的
- 7.6.7 可组合扩展的
- 7.7 衡量影响
- 7.8 工程赋能的正确时机
- 7.9 小结
- 第8章 确保“谁构建，谁运行”
- 8.1 为什么微服务意味着DevOps
- 8.1.1 按需发布
- 8.1.2 处理运维功能
- 8.2 以不同的方式进行构建
- 8.2.1 良好的运维手册
- 8.2.2 运行在其他人的服务器中
- 8.2.3 适应生产环境
- 8.3 在生产环境支持团队
- 8.3.1 专职的工作时间内运维支持
- 8.3.2 优化告警和文档
- 8.3.3 识别出幽灵森林
- 8.3.4 练习
- 8.4 非工作时间支持
- 8.4.1 允许人们选择退出
- 8.4.2 正式轮班制度vs全力以赴制度
- 8.4.3 确保呼叫很少
- 8.4.4 只针对关键系统
- 8.4.5 提供支持和指导
- 8.5 事故管理
- 8.5.1 无责备文化
- 8.5.2 上报事故
- 8.5.3 分配角色
- 8.5.4 事故期间
- 8.5.5 事故之后
- 8.5.6 从事故中学习
- 8.6 小结
- 第三部分 构建和运维
- 第9章 活跃的服务所有权
- 9.1 响应Log4Shell漏洞
- 9.2 一个反面教材：Equifax和Struts漏洞
- 9.3 开发过程中的所有权
- 9.3.1 强所有权
- 9.3.2 弱所有权
- 9.3.3 共享所有权
- 9.4 一旦服务功能完备了
- 9.4.1 空所有权
- 9.4.2 名义所有权
- 9.4.3 积极所有权
- 9.5 积极所有权的含义
- 9.5.1 代码管理
- 9.5.2 升级和修补
- 9.5.3 迁移
- 9.5.4 生产支持
- 9.5.5 文档管理
- 9.6 了解服务资产
- 9.6.1 自研软件
- 9.6.2 依赖
- 9.6.3 第三方软件
- 9.7 服务目录中需要什么
- 9.7.1 基于图的模型
- 9.7.2 API驱动
- 9.7.3 可扩展的
- 9.7.4 灵活的数据结构
- 9.7.5 提供整个资产的不同视图
- 9.8 所有权转让
- 9.8.1 成功的转让是什么样的
- 9.8.2 满足质量要求
- 9.8.3 运营方面的移交
- 9.8.4 替代
- 9.9 当我们陷入困境时
- 9.9.1 提供业务支持案例
- 9.9.2 从关键系统开始
- 9.9.3 尽力推测系统的所有者
- 9.9.4 从数据中交付价值
- 9.9.5 目标是持续优化
- 9.9.6 识别出负担过重的团队
- 9.9.7 服务不应永存
- 9.10 小结
- 第10章 得测试之利
- 10.1 为何测试
- 10.1.1 正确地实现功能
- 10.1.2 实现正确的功能
- 10.1.3 捕捉回归缺陷
- 10.1.4 满足服务质量要求
- 10.2 测试左移
- 10.3 什么才是好的测试
- 10.3.1 尽快尽早发现问题
- 10.3.2 易于修改
- 10.3.3 直指问题
- 10.4 测试的种类
- 10.4.1 测试金字塔
- 10.4.2 单元测试
- 10.4.3 服务测试
- 10.4.4 端到端测试
- 10.4.5 契约测试
- 10.4.6 连贯性测试
- 10.4.7 探索性测试
- 10.4.8 跨功能测试
- 10.5 生产环境测试
- 10.5.1 这安全吗
- 10.5.2 预生产环境不是模拟生产环境
- 10.5.3 总有别出心裁的用户
- 10.5.4 总有变化测试不到
- 10.5.5 不必把变更推给所有人
- 10.5.6 监控即测试
- 10.6 基础设施测试
- 10.6.1 混沌工程
- 10.6.2 测试故障切换和数据恢复
- 10.7 质量不只源于测试
- 10.8 当你陷入困境
- 10.8.1 自动化测试不足
- 10.8.2 无效的测试
- 10.9 小结
- 第11章 治理与标准化：找准平衡点
- 11.1 为什么要治理
- 11.2 了解技术资产
- 11.3 记录何种信息
- 11.4 指导原则与政策
- 11.4.1 指导原则自动化
- 11.4.2 指导原则的内容
- 11.4.3 金融时报的指导原则
- 11.5 共创指导原则
- 11.5.1 技术治理小组（TGG）
- 11.5.2 TGG的价值
- 11.6 技术选型
- 11.6.1 技术的生命周期
- 11.6.2 为商业价值而创新
- 11.6.3 用些无聊的技术
- 11.6.4 精简选择
- 11.6.5 哪些可以重复
- 11.6.6 改变总会发生
- 11.7 先洞察再行动
- 11.8 其他组织的治理故事
- 11.8.1 Monzo的治理
- 11.8.2 Skyscanner的治理
- 11.9 当你陷入困境
- 11.10 小结
- 第12章 内化弹性设计
- 12.1 什么是弹性
- 12.1.1 分布式系统的弹性
- 12.1.2 微服务的弹性
- 12.2 理解服务等级要求
- 12.2.1 服务等级目标（SLO）
- 12.2.2 错误预算
- 12.3 构建弹性服务
- 12.3.1 冗余
- 12.3.2 快速启动与优雅关闭
- 12.3.3 合理的超时时长
- 12.3.4 退避与重试
- 12.3.5 幂等化请求
- 12.3.6 保护自己
- 12.3.7 验证服务弹性
- 12.3.8 简化服务弹性设计
- 12.4 构建弹性系统
- 12.4.1 缓存
- 12.4.2 应对级联故障
- 12.4.3 降级行为
- 12.4.4 避免无效工作
- 12.4.5 异步调用
- 12.4.6 故障切换
- 12.4.7 备份与恢复
- 12.4.8 灾难恢复
- 12.5 构建弹性平台
- 12.5.1 外部弹性
- 12.5.2 内部工具
- 12.6 验证系统弹性
- 12.6.1 混沌工程
- 12.6.2 测试备份和重置
- 12.6.3 熟能生巧
- 12.6.4 负载测试
- 12.6.5 从事故中学习
- 12.6.6 一次只做一件事
- 12.7 当你陷入困境
- 12.8 小结
- 第13章 生产环境中的系统实践
- 13.1 微服务的运维挑战
- 13.1.1 技术多样性的支持难题
- 13.1.2 基础设施的短暂性
- 13.1.3 快速变更
- 13.1.4 警报过载
- 13.1.5 弹性机制掩盖系统降级
- 13.2 内置可观测性
- 13.2.1 日志
- 13.2.2 监控和度量
- 13.2.3 日志聚合
- 13.2.4 OpenTelemetry
- 13.2.5 关注事件
- 13.2.6 分布式追踪
- 13.2.7 归档观测数据
- 13.3 打造工具
- 13.4 聚焦问题
- 13.4.1 正确告警
- 13.4.2 健康检查
- 13.4.3 监控业务成效
- 13.4.4 了解系统常态
- 13.5 故障应急指南
- 13.6 故障排查
- 13.6.1 维护核心文档
- 13.6.2 洞察变更轨迹
- 13.6.3 外源性故障隐患
- 13.6.4 工具特性分析
- 13.7 从事故中学习
- 13.8 当你陷入困境
- 13.9 小结
- 第14章 保持系统演进
- 14.1 挑战源自何处
- 14.2 减轻变更冲击
- 14.2.1 做长久打算
- 14.2.2 规范路径的价值
- 14.2.3 选择托管服务和SaaS方案
- 14.2.4 提供API接口
- 14.2.5 不可变的一次性基础设施
- 14.2.6 退役和弃用
- 14.3 变更的分类
- 14.3.1 紧急变更
- 14.3.2 计划内的次要变更
- 14.3.3 计划内的重大变更
- 14.4 应对变更
- 14.4.1 技术资产的全景管理
- 14.4.2 制定指导性政策
- 14.5 做出决策
- 14.5.1 决策权归属
- 14.5.2 工作排期权衡
- 14.6 管理变更
- 14.6.1 保持清晰
- 14.6.2 保持沟通
- 14.6.3 保持同理心
- 14.6.4 执行
- 14.7 当你陷入困境
- 14.8 总结
- 后记
- 附录A 微服务评估
- 附录B 推荐阅读
书名：微服务成功启示录
作者：Sarah Wells 著
译者：宋奕兴, 娄麒麟, 葛灿, 赵正阳 译
国内出版社：中国电力出版社
出版时间：2025年09月
页数：476
书号：978-7-5239-0156-4
原版书书名：Enabling Microservice Success
原版书出版商：O'Reilly Media
本书封面上的动物是一只欧洲石鸡（学名：Saxicola rubicola），因其叫声听起来像是两块石头碰撞而得名。它们主要生活在欧洲，但也可以在北非或西亚的部分地区找到。
在夏季，雄性石鸡的羽毛颜色与美国知更鸟相似，橙色的胸部、深色的头部和胸部以及白色的斑点。雌性石鸡和冬季的雄性石鸡通常呈各式棕色。无论是雄性还是雌性，它们的翅膀都非常短。不出所料地，由于翅膀较短，它们仅进行短距离迁徙，甚至可能不迁徙。它们偏好的栖息地包括泥炭沼泽、湿地、灌木丛和草地，巢穴通常建在地面上，主要以昆虫为食。
石鸡在繁殖季节（通常为两到三个巢）内会形成一夫一妻制，但不是终身制。父母双方都会照顾幼鸟。母鸟会在一窝中孵化四到六枚蛋，孵化期为13~14 天。幼鸟孵化后约12~16 天开始离巢，此时母鸟开始建造下一个巢，而雄鸟则继续喂养幼鸟几天。
在夏季，雄性石鸡的羽毛颜色与美国知更鸟相似，橙色的胸部、深色的头部和胸部以及白色的斑点。雌性石鸡和冬季的雄性石鸡通常呈各式棕色。无论是雄性还是雌性，它们的翅膀都非常短。不出所料地，由于翅膀较短，它们仅进行短距离迁徙，甚至可能不迁徙。它们偏好的栖息地包括泥炭沼泽、湿地、灌木丛和草地，巢穴通常建在地面上，主要以昆虫为食。
石鸡在繁殖季节（通常为两到三个巢）内会形成一夫一妻制，但不是终身制。父母双方都会照顾幼鸟。母鸟会在一窝中孵化四到六枚蛋，孵化期为13~14 天。幼鸟孵化后约12~16 天开始离巢，此时母鸟开始建造下一个巢，而雄鸟则继续喂养幼鸟几天。
购买选项
|
© 2026，奥莱利技术咨询(北京)有限公司。版权所有。 传真: +86-10-88097463 京ICP备05003502号 |
|