![微服务设计 - [英] Sam Newman](https://static.book345.com/covers/s/9787115420268.jpg)
书籍介绍
本书全面介绍了微服务的建模、集成、测试、部署和监控，通过一个虚构的公司讲解了如何建立微服务架构。主要内容包括认识微服务在保证系统设计与组织目标统一上的重要性，学会把服务集成到已有系统中，采用递增手段拆分单块大型应用，通过持续集成部署微服务，等等。
AI导读
核心看点
- 全面讲解微服务建模、集成、测试与部署
- 强调架构需与组织结构及战略目标匹配
- 提供从单体应用向微服务演化的实践指南
适合谁读
- 寻求系统架构转型的软件工程师
- 关注微服务落地实践的技术管理者
- 希望提升系统可扩展性的开发者
读前提醒
- 建议结合项目经验阅读，避免空谈概念
- 注意书中关于技术债务与治理的讨论
- 理解微服务并非银弹，需权衡利弊
读者共识
- 内容全面实用，是微服务领域的经典之作
- 部分读者认为内容偏理论，代码示例较少
- 中文版翻译质量参差不齐，建议参考原文
本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。
精彩摘录
- "聚在一起，就如何做事情达成共识是一个好主意。但是，花时间保证人们按照这个共识来做事情就没那么有趣了，因为在各个服务中使用这些标准做法会成为开发人员的负担。我坚信应该使用简单的方式把事情做对。我见过比较奏效的两种方式是，提供范例和服务代码模板。"
- "编写文档是有用的，... 但是开发人员更喜欢可以查看和运行的代码。 创建服务代码模板不是某个中心化工具的职责，也不是指导我们应怎样工作的架构团队的职责。应该通过合作的方式定义出这些实践，所以你的团队也需要负责更新这个模板。 我也见过一个团队的士气和生产力是如何被强制使用的框架给毁掉的。基于代码重用的目的，越来越多的功能被加入到一个中心化的框架中，直到把这个框架变成一个不堪重负的怪兽。 你还需要知道，重用代码可能引入的危险。在重用代码的驱动下，我们可能会引入服务之间的耦合。... 一些我接触过的团队，把服务代码模板简单地做成了一个共享的库依赖，这时他们就要非常小心地防止对 DRY 的追求导致系统"
- "这个组织逐渐决定对团队进行扩容，增加了一个巴西团队来分担一部分工作。系统被划分成两部分，一部分面向前端，该部分不保存任何状态，如图 3-4 所示；后端部分就是一个简单的数据存储，通过 RPC 提供服务。基本上你可以理解为，把一个代码库中的仓储层变成了一个独立的服务。 后来发现，需要频繁地同时修改两个服务。两个服务都是偏底层的、RPC 风格的方法调用，而这是非常不稳定的。这个服务接口也很繁琐，会导致性能问题。这就导致了对 RPC 批处理的需求。我把这种架构称为洋葱架构，因为它又很多层，而且当纵切这些层次时，我只想哭。"
- "细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜。"
- "Domain-driven design. Continuous delivery. On-demand virtualization. Infrastructure automation. Small autonomous teams. Systems at scale. Microservices have emerged from this world."
- "bounded contexts make excellent seams"
- "many of our working practices around deployment and host management are an attempt to optimize for scarcity of resources"
- "Test Journeys, Not Stories"
作者简介
作者简介：
Sam Newman
是ThoughtWorks公司的技术专家、ThoughtWorks内部系统架构师，同时还为全球的客户提供咨询服务。他在开发和IT运维方面与全球多个领域的公司有过合作。
译者简介：
崔力强
阿里巴巴技术专家，目前专注于持续交付相关的产品开发。曾在ThoughtWorks任职多年，从事软件定制开发、敏捷软件开发的相关咨询等工作，帮助过数个团队和项目进行精益需求管理、软件设计、自动化测试和持续集成等实践。微信号：blade_1986
张骏
2010年加入ThoughtWorks公司。作为开发人员、项目经理、资深敏捷教练和资深咨询师，在金融、电信和能源服务行业的大型复杂业务系统的设计、开发、管理、咨询等方面有丰富的经验。曾为国内外诸多客户提供软件设计、开发以及咨询服务。拥有10年工作经验，在Scrum、看板、规模化敏捷等方法论，以及精益需求管理、自动化测试、持续集成、领域驱动设计、微服务等具体实践方面都有丰富的积累。微信号：zhangjun695339
目录
用户评论
微服务即大服务！没前提预研实践，一言不合就微服务就是个不定时炸弹。
微服务并不神秘，只是用了一个新词解释已经存在的事物。
很有用的方法论
内容还是很practical的，涉及构建一个复杂的、可扩展系统的方方面面（主要是技术上的），存储、部署、测试、安全、监控等基本都提到了，可以作为设计复杂系统时的checklist。但美中不足的是尽管作者针对某些议题提了一些自己的best practice，但也有很多难题作者没有提出几乎任何解决方案，有点失望。翻译得比较糟糕，推荐看原文。
没有太多的技术细节，不少设计上的理念梳理是意外的惊喜。包括战略、原则、实施的边界、对组织的认识以及 TW 出色的一些战术。一分扣给翻译。
说实话没啥新东西。。。
3.5，讨论范围很广但不算很深，读起来有启发但收获略散，作者的前瞻性很强，趋势预测基本没出问题
优秀
无工作经验选手读这种东西是不是没啥用… 只能说看完更想去 ThoughtWorks 和 Netflix 了（
这本书非常务实，语言直白而不是堆砌高大上的术语，所描述的问题和场景，正是我们工程实践的现实。
微小、增量的演进，是最佳的架构演进模式。
业务和技术不确定的新系统，应该保持单体一段时间，等系统能够稳定下来，团队能识别出稳定的边界，才能决定如何划分。
在微服务环境中，开发人员很难只在自己的小世界中编写代码。微服务的意义是避免系统行为和知识的重复，高度自治的团队和自动化至关重要。
限界上下文和数据库的拆分，只能根据实际的业务模式和组织架构，并没有银弹。
也没有免费的午餐，降低局部复杂性的同时，整体肯定会变得很复杂，直到形成商业模式的竞争壁垒，同时产生远大于系统运行成本的收益。
编程的时候，大量的工作都是枯燥的定义模型，在不同的层和服务之间解耦，就意味着需要独立定义，独立演化，就有了设计和转换的成本
下载
收藏