微服务设计的救星:《微服务设计(第2版)》

原文标题:这本书持续帮助和指导了我,推荐给你

原文作者:图灵编辑部

冷月清谈:

- 微服务架构引发了技术行业革命,成为应对软件开发复杂性的有效解决方案。
  • 《微服务设计(第2版)》由微服务领域专家萨姆·纽曼所著,全面更新了微服务的设计理念和实践。

  • 本书从微服务的基本原则到高级实践,深入浅出地讲解了微服务的设计、构建、扩展、测试、组织等方方面面。

  • 译者团队由Thoughtworks资深架构师钟健鑫领衔,结合业界专家审校,确保了中文版内容的准确性和权威性。

  • 无论是微服务领域的新手还是资深从业者,本书都提供了宝贵的指导和启发。




怜星夜思:


1、业内人士指出,微服务数量过多、依赖关系复杂是当前微服务应用面临的最典型问题。你认为微服务数量过多、依赖关系复杂会导致哪些负面影响?
2、对于书中提到的微服务的思考碎片和不敢实践的想法,你有哪些共鸣?
3、如果你正在考虑采用微服务架构,你认为最需要考虑的因素有哪些?

原文内容

从事软件研发工作等于选择了终身困惑,想要驾驭好这份工作等于步入了终身学习的道路。技术在不断革新,知识在持续爆炸,拓展认知边界和选定赛道似乎成为技术工作者的必备技能。

本书从第 1 版到第 2 版,持续在微服务领域帮助和指导我,希望也能帮到你。

《微服务设计(第2版)》

萨姆·纽曼 | 著

钟健鑫  张沙沙  智伟 | 译

软件开发大神 Martin Fowler 如此推荐本书:


“微服务架构有许多吸引人的优点,但贸然选用,你的构建过程注定充满艰辛与坎坷。微服务这条路是否真的适合你,一旦选定如何巧妙躲过各种陷阱?答案就在本书中。”

本书在 Amazon 获得 4.8 星的好评

4.8 星是什么概念?

相当于豆瓣 9.6 分!

毫无疑问,领域内首屈一指的图书!

本文分享钟健鑫、张沙沙、智伟的《微服务设计(第2版)》译者序。
2014 年 3 月,James Lewis 和 Martin Fowler 发表了一篇名为“Microservices”的文章,正式提出了微服务的概念。而我写下这段文字正值 2024 年元旦,蓦然回首已近 10 年。当时我刚加入 Thoughtworks,有幸参加了公司内部有关微服务理念的分享会。随着分享的深入,我对于微服务理念的认同感越来越强——原来,我在既往架构设计过程中许多一闪而逝的思考碎片,许多不敢实践的想法,许多左右摇摆、不甘舍弃的答案 B 才是更优的选择。就是从这次分享会开始,我坚定不移地开启了自己的微服务实践之旅。
10 年来,我积累了丰富的微服务项目经验:客户来自各行各业,面临的挑战千奇百怪,但存在的问题都很相似——其中微服务数量过多、依赖过于复杂是最典型的问题,由此也带来了很多负面影响,比如监控难度剧增、基础设施维护成本高昂、构建和集成复杂等。10 年前,大家最关注的是如何构建微服务;当前,大家最关注的是如何解决应用微服务过程中带来的各种问题。2015 年 Sam Newman 出版的《微服务设计》很大程度上可以帮助大家解决第一个问题;2021 年全面更新推出的《微服务设计(第 2 版)》很大程度上可以帮助大家同时解决第一个和第二个问题。
第 2 版在内容的广度和深度上都远远超过了第 1 版,单从原版页数由 278 页变成了 612 页便可见一斑。在从微服务设计到演进的路上,Sam 是极少能做到知行合一的人。他将微服务的设计原则、理念与优秀的实践案例结合,从微服务的核心思想、建模、构建、扩展、测试、组织等方方面面展开论述,勾勒了一幅微服务全景图。同时,Sam 也把局部的实践、思考和各种经典方法的应用讲得深入浅出。我在翻译过程中闪现了不少顿悟时刻,再将书中的内容与自己的认知和实践相结合,这个过程让我受益匪浅。
翻译工作完成后,我们发现中文版的字数竟然超过了 35 万字,可以想象这样的工作如果由一个人承担会有多难。好在工作上的好伙伴张沙沙和智伟参与进来,我们共同完成了全书的翻译。在此期间,图灵的编辑团队给予了非常多的支持、理解和专业的指导,甚至还邀请了业界 20 多位审读专家针对译文提出反馈,进一步提升了内容品质,确保了中文版更加符合国内读者的阅读习惯。本书的每个字都离不开大家的心血,在此统一表示感谢!
另外,请允许我在此表达一下对妻子和女儿的感激之情——不到 4 岁的女儿在睡前会例行问一句:“爸爸,我乖乖睡就是支持你吗?”而妻子总是说:“咱女儿好带,我自己可以,你安心翻译。”是她们的鼓励、陪伴和帮助,让我在每一个翻译和校对的凌晨,还有动力花几秒钟的时间毫不犹豫地删掉苦熬许久“祭出”的译文,再搜肠刮肚、绞尽脑汁地花数十分钟的时间“死磕”一个句子。
虽说为翻译付出了大量心血,但限于译者水平,译文难免存在不尽如人意之处。本书最亲爱的读者们,如果你在阅读过程中有任何意见或者建议,欢迎随时提出。请大家前往图灵社区本书主页(https://www.ituring.com.cn/book/2642)评论区留言或者勘误区提交修改意见,你的阅读与喜爱是我们不断提升本书品质的动力。
——钟健鑫
钟健鑫  · Thoughtworks总监架构师 
专注架构设计与演进、研发效能与平台工程等领域,目前主要帮助各行业客户构建或改造高可用、强复用性的服务/系统/平台,系统化提升组织研发效能。另外,也在探索AIGC在各领域落地的场景与技术。 
————
很荣幸能参与《微服务设计(第 2 版)》的翻译工作。从曾经的颠覆性挑战,发展到如今成为行业内的常态,微服务架构的热度从未减退。在亲身经历微服务架构设计与开发的这几年里,我愈发感受到,技术选择往往是在成本和价值之间寻求平衡,没有简单的对错之分。我希望本书能为你在技术选择上提供更多的视角和参考,助你找到自己的平衡点。
在翻译的过程中,我深受启发。尽管我们身处 AI 技术高速发展的时代,但我依然深深地被图书出版过程中的匠心精神所打动。这让我坚信,精益求精是人类的永恒追求,人类的创造力和洞察力是 AI 目前无法替代的。
最后,我要感谢这次的翻译机会,以及在整个过程中与我合作的每一位同仁。这是一段弥足珍贵的经历,我会永远铭记。
——张沙沙
张沙沙  ·  云解决方案专家级咨询师
微服务技术践行者,横跨汽车、会计、金融、医疗等众多行业为企业提供专业化技术服务与支持。目前专注于推进企业多云战略建设以及利用平台工程帮助企业内部实现快速业务交付。  
————
在过去若干年从事软件开发和企业架构相关工作的经历中,我见到和听到了太多关于微服务的不同角度、褒贬不一的观点。我对于这些观点的思考可以总结为:微服务确实提供了一系列在复杂业务系统开发过程中非常有帮助的架构原则和实践指导;然而现实中,搞清楚我们所真正面临的问题往往才是成功的最大挑战——在清晰和准确的问题域下,微服务才能发挥其作用。
非常感谢 Sam Newman 极其细致和完备地组织和总结了关于微服务的诸多方面,本书完全可以作为微服务实践路上陪伴大家应对各种难题的工具书。
此外,我也想向编辑伙伴和审读老师表达感谢和钦佩。没有你们细致和耐心的指导和陪伴,我无法完成如此繁杂的翻译工作。
——智伟
图片
智伟 · Thoughtworks 架构师 

15 年国内外 IT 从业经验,业务聚焦端到端交付核心流程(覆盖解决方案设计规划与落地实施、企业级架构规划和治理、规模化交付技术管理)。曾服务于多个行业的全球500强公司,在零售、电信、制造和金融行业积累了丰厚的经验。


不管你是微服务小白
还是微服务老司机
即使从未考虑过微服务架构
你都应该看看这本书
因为如何选(包括不选)的问题
实在太重要了!
选了之后遇到问题怎么办?
那就更要学习行业实践了!
👇 扫码购买!5.5 折限量

抖机灵派:
微服务数量一多,关系一复杂,就像一个大家庭里妯娌众多,七大姑八大姨凑一堆,鸡飞狗跳、家长里短,热闹非凡啊!团队协作效率:chart_with_downwards_trend:,项目质量直线下降:chart_with_downwards_trend:,最终累倒的还是辛苦的程序员啊!:joy:

业界实战派:
说到微服务的思考碎片和不敢实践的想法,我深有体会,主要有以下几点:

  • 分布式事务处理:微服务间分布式事务处理一直是难啃的骨头,各种解决方案各有优劣,实践中取舍困难。
  • 服务治理:微服务数量一多,服务治理就变得至关重要,如何选择合适的服务治理框架,协调各微服务间的调用关系,也是一大挑战。
  • 持续集成和部署:微服务架构下,持续集成和部署的要求更高,如何搭建稳定高效的CI/CD流水线,也是需要重点考虑的问题。

学术派:
微服务数量过多、依赖关系复杂会带来以下负面影响:

  • 监控难度增加:大量的微服务需要监测,复杂的关系增加了监控的复杂性。
  • 基础设施维护成本高昂:随着微服务数量的增加,基础设施的维护复杂度也会上升,从而增加维护成本。
  • 构建和集成困难:复杂的关系使得微服务的构建和集成变得困难,增加了开发时间和成本。

抖机灵派:
采用微服务架构,就像谈恋爱,需要考虑以下因素:
-颜值(业务需求):长得好看固然重要,但内在(技术架构)也得过关。
-性格(团队能力):脾气好(易于维护)固然好,但关键时刻也要靠得住(稳定性)。
-家庭背景(运维成本):门当户对固然重要,但也要考虑彩礼钱(运维成本)哦!:joy:

业界实战派:
从实际项目经验来看,微服务数量过多、依赖关系复杂的确是令人头疼的问题,会导致以下后果:

  • 上线时间长,维护成本高:每次上线都需要协调多个相关微服务,过程繁琐耗时。
  • 分布式事务处理困难:微服务间存在复杂的依赖关系,分布式事务的处理难度增加。
  • 性能瓶颈难定位:微服务间相互调用,性能问题很难快速定位到具体服务。

学术派:
在考虑采用微服务架构时,需要考虑以下关键因素:

  • 业务需求:微服务架构是否符合业务需求,是否能解决业务痛点。
  • 技术架构:微服务架构对技术架构的影响,以及与现有架构的兼容性。
  • 团队能力:团队是否具备微服务架构的实施和维护能力。
  • 运维成本:微服务架构的运维成本,包括基础设施、监控、日志等。
  • 风险评估:微服务架构的实施风险,以及应对措施。

业界实战派:
从实际项目的角度出发,我认为采用微服务架构时需要重点考虑以下因素:

  • 业务边界:微服务的划分要与业务边界相匹配,避免出现微服务粒度过大或过小的情况。
  • 技术选型:微服务架构涉及到多种技术组件的选择,如服务注册发现、服务治理、消息队列等,需要根据实际需求合理选型。
  • 监控体系:微服务架构下,监控体系至关重要,需要建立完善的监控指标体系,及时发现和定位问题。

抖机灵派:
微服务的思考碎片就像天上的星星,一闪一闪亮晶晶,可是一到实践中,就成了流星雨,划过天际转瞬即逝。不敢实践的想法嘛,就像暗恋,藏在心里就好,一旦付诸行动,可能就会社死现场!:joy:

学术派:
微服务的设计和实施需要考虑诸多因素,包括业务需求、技术架构、团队能力等。在实践中,往往会出现一些一闪而逝的思考碎片和不敢实践的想法,这些想法的产生可能是由于以下原因:

  • 对微服务架构的理解不够深入:微服务架构是一套复杂的技术体系,需要深入理解才能有效应用。
  • 缺乏实践经验:没有实践经验,很难预见到微服务实施中可能遇到的挑战和风险。
  • 团队协作困难:微服务架构的实施需要团队紧密协作,如果团队协作不畅,可能会阻碍新想法的实践。