微服务：灵活的软件架构 pdf mobi txt 2024 电子版 下载

微服务是一种实现软件模块化的方案，具有可替代性强、可持续开发、可独立伸缩、可持续交付等优点，克服了传统单体部署成本过高和不够灵活的缺点。使用微服务架构能鼓励开发团队采用不同于以往技术栈的新技术，并能有效地简化基础设施和运维工作。

本书围绕架构和组织的主题，详细介绍了微服务的各个方面，不仅告诉你什么是微服务、为何要使用微服务，而且还提供了基于Java、Spring Boot、Docker和Spring Cloud实现的详尽示例，通过实践来阐释微服务的理念。各章节的“动手实践”部分能帮助你加深对微服务的理解。无论是管理者、开发人员还是架构师，都能从阅读本书中受益。

● 掌握微服务的基本概念，并学习如何有效地将其整合到遗留应用中

● 学习微服务的系统架构、集成、通信、测试等实现技术，应用包括CQRS和事件溯源在内的高级架构技巧

● 学习如何最大化微服务的容错性和稳定性

● 采用Java、Spring Boot、Docker和Spring Cloud实现完整的示例应用

● 采用Amazon Lambda、OSGi、Java EE、Vert.x、Erlang和Seneca探索纳米服务

● 理解微服务对团队、技术领导者、产品负责人和相关业务人员的影响

第一部分　动机和基础知识

第1章　预备知识　　2

1.1　微服务概述　　2

1.2　为什么采用微服务　　3

1.3　挑战　　5

1.4　总结　　6

第2章　微服务应用案例　　7

2.1　遗留电商应用的技术更新　　7

2.2　开发一个新的信号系统　　13

2.3　总结　　15

第二部分　微服务是什么，用还是不用

第3章　什么是微服务　　18

3.1　微服务的大小　　18

3.2　康威定律　　24

3.3　领域驱动设计与限界上下文　　27

3.4　为什么要远离标准数据模型　　32

3.5　微服务要不要包含UI　　34

3.6　总结　　35

第4章　采用微服务的原因　　37

4.1　技术优势　　37

4.2　组织上的优势　　42

4.3　业务方面的优势　　44

4.4　总结　　45

第5章　挑战　　47

5.1　技术挑战　　47

5.2　架构　　50

5.3　基础设施与运维　　52

5.4　总结　　53

第6章　微服务与SOA　　55

6.1　什么是SOA　　55

6.2　SOA与微服务的区别　　59

6.3　总结　　62

第三部分　微服务的实现

第7章　微服务系统架构　　68

7.1　领域架构　　68

7.2　架构管理　　71

7.3　调整架构的技术　　75

7.4　增长的微服务系统　　81

7.5　别错过出口：如何避免微服务的退化　　84

7.6　微服务与遗留应用　　86

7.7　潜在的依赖　　91

7.8　事件驱动架构　　92

7.9　技术架构　　93

7.10　配置与协调　　95

7.11　服务发现　　97

7.12　负载均衡　　99

7.13　可伸缩性　　102

7.14　安全性　　104

7.15　文档与元数据　　109

7.16　总结　　110

第8章　集成与通信　　112

8.1　Web与UI　　112

8.2　REST　　121

8.3　SOAP与RPC　　123

8.4　消息　　124

8.5　数据复制　　126

8.6　内部接口与外部接口　　128

8.7　总结　　130

第9章　单个微服务架构　　133

9.1　领域架构　　133

9.2　CQRS　　134

9.3　事件溯源　　136

9.4　六边形架构　　138

9.5　容错性和稳定性　　141

9.6　技术架构　　144

9.7　总结　　146

第10章　微服务与微服务系统的测试　　148

10.1　为什么需要测试　　148

10.2　如何测试　　149

10.3　降低部署的风险　　153

10.4　系统整体的测试　　154

10.5　遗留应用与微服务的测试　　157

10.6　各个微服务的测试　　159

10.7　消费者驱动的契约测试　　160

10.8　技术标准的测试　　163

10.9　总结　　164

第11章　微服务的运维及持续交付　　165

11.1　微服务运维的挑战　　165

11.2　日志　　167

11.3　监控　　171

11.4　部署　　176

11.5　联合部署还是独立部署　　179

11.6　控制　　180

11.7　基础设施　　180

11.8　总结　　184

第12章　微服务架构的组织效应　　186

12.1　微服务的组织效益　　186

12.2　康威定律的替代方案　　189

12.3　微观架构与宏观架构　　191

12.4　技术领导力　　196

12.5　DevOps　　197

12.6　当微服务遇上传统的IT组织　　198

12.7　与客户的接洽　　201

12.8　可复用代码　　202

12.9　能否采用微服务而不改变组织　　204

12.10　总结　　206

第四部分　技术

第13章　微服务架构示例　　210

13.1　领域架构　　210

13.2　基本技术　　212

13.3　构建　　216

13.4　使用Docker进行部署　　217

13.5　Vagrant　　218

13.6　Docker Machine　　222

13.7　Docker Compose　　223

13.8　服务发现　　226

13.9　通信　　228

13.10　容错性　　230

13.11　负载均衡　　234

13.12　集成其他技术　　235

13.13　测试　　236

13.14　基于JVM的微服务在Amazon Cloud中运行的实践　　237

13.15　总结　　239

第14章　纳米服务技术　　241

14.1　为什么采用纳米服务　　241

14.2　纳米服务：定义　　243

14.3　Amazon Lambda　　244

14.4　OSGi　　245

14.5　Java EE　　248

14.6　Vert.x　　251

14.7　Erlang　　252

14.8　Seneca　　255

14.9　总结　　257

第15章　把微服务用起来　　259

15.1　为什么选择微服务　　259

15.2　微服务实践之路　　260

15.3　微服务：能否落地　　260

15.4　总结　　261

作者简介：

埃伯哈德·沃尔夫（Eberhard Wolff）

技术咨询公司innoQ的研究员，一位立足于业务和技术交汇点、拥有超过15年经验的架构师和咨询师。他曾在多个国际会议上发表过演讲和报告，担任多个会议的委员会成员，并撰写了100多篇文章及多本图书。他的技术关注点是现代架构，主要涉及云计算、持续交付、DevOps、微服务和NoSQL。

译者简介：

莫树聪

计算机硕士，毕业于浙江大学，先后供职于网易、Yeahmobi，目前是一名运维开发工程师，关注容器、云计算、后端开发、机器学习等领域。

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：微服务：灵活的软件架构在线阅读

在线听书地址：微服务：灵活的软件架构在线收听

在线购买地址：微服务：灵活的软件架构在线购买

暂无原文赏析，正在全力查找中！

书籍介绍

微服务是一种实现软件模块化的方案，具有可替代性强、可持续开发、可独立伸缩、可持续交付等优点，克服了传统单体部署成本过高和不够灵活的缺点。使用微服务架构能鼓励开发团队采用不同于以往技术栈的新技术，并能有效地简化基础设施和运维工作。

本书围绕架构和组织的主题，详细介绍了微服务的各个方面，不仅告诉你什么是微服务、为何要使用微服务，而且还提供了基于Java、Spring Boot、Docker和Spring Cloud实现的详尽示例，通过实践来阐释微服务的理念。各章节的“动手实践”部分能帮助你加深对微服务的理解。无论是管理者、开发人员还是架构师，都能从阅读本书中受益。

● 掌握微服务的基本概念，并学习如何有效地将其整合到遗留应用中

● 学习微服务的系统架构、集成、通信、测试等实现技术，应用包括CQRS和事件溯源在内的高级架构技巧

● 学习如何最大化微服务的容错性和稳定性

● 采用Java、Spring Boot、Docker和Spring Cloud实现完整的示例应用

● 采用Amazon Lambda、OSGi、Java EE、Vert.x、Erlang和Seneca探索纳米服务

● 理解微服务对团队、技术领导者、产品负责人和相关业务人员的影响

• 作者： 发布时间：2023-12-25 17:18:36

  。。。很魔幻

• 作者：dd 发布时间：2011-07-17 23:08:04

  读完即亡。

• 作者：大沐 发布时间：2011-03-08 16:25:59

  教材也就这个水平了

• 作者：sp42 发布时间：2023-05-25 23:57:28

  偏理论 没啥用

• 作者：马德里的格里柯 发布时间：2022-03-25 19:22:11

  因为第二部纪事太精彩，显得第一部平淡。对比来看第一部就是个引，哈定老头辞职引发一系列后续事件。

• 作者：沉默是豆 发布时间：2010-09-11 20:23:55

  根本不是也不可能零首付，题目就是为了吸引眼球。交易手法现在也未必适用啊。

• 不怎么喜欢这本短篇集，而且虽说是女侦探，但书中的叙事口吻更像是男性。

  作者：卡神的日常踩雷 发布时间：2022-11-03 15:45:27

  这本书首次出版于1864年，是一本短篇集。

  作者是安德鲁·福雷斯特，我就不详细介绍了， 是詹姆斯·雷丁·韦尔的笔名，在大英图书馆出版这本书之前，我都没听说过这个作者。

  此书通常被认为是侦探小说中首次出现女侦探，而当时那个年代连女警察都没有。

  更有报纸说阿加莎·克里斯蒂书中的侦探马普尔小姐的灵感就来自此书。

  但在书中这个“女侦探”完全没有加以介绍，读者连她是高是矮都无法得知，性格也不鲜明，如果不是她自称“格兰登夫人”，我会更倾向于认为是男性口吻叙事的。

  小说的序章：我建议直接跳过，都是在讲侦探这个职业是不可缺少的。

  包括正文部分，都写了很多侦探的重要性，女侦探相比男性侦探优越在哪里，反反复复提醒了好多遍，看着很烦。

  这本书还是以我不太喜欢的第一人称叙述的，就故事性而言，我觉得不怎么好看。

  不过，人与人的区别真大，像我就不喜欢《女侦探》这本书，但确实看到有好几个人挺喜欢这本书的。

  还有，大英图书馆里，我目前看过的作品里，我最喜欢《豕背山奇案》，但上次看到推理小说吧里，居然有人说是烂作中的烂作。。晕

• 如何成为一名优秀的DevOps

  作者：牛皮糖 发布时间：2014-04-24 12:03:37

  自从12年，开始选型研发team的CI工具链的选项和搭建，在经过了近一年的摸索后，13年初开始全权负责公司内部的持续集成系统的流程设计和工具链的搭建，压力山大。

  当时阅读了包括持续交付在内的一些技术书籍，借鉴了一些开源社区的CI体系以及工具链，Openstack社区的持续集成流程和规范给我了非常大的帮助，参与了一些国内的技术讲座，Qcon上百度的乔梁所做的持续集成分享给我了诸多启发。

  《持续交付》是我手头唯一的纸质参考书，也是市面上屈指可数讲述持续交付的书籍。

  这类书讲得是道，方法论，也就是做事的方法，但不会深入技术细节。

  因为每家公司的业务不同，技术栈不同，研发团队的组成也不尽相同，虽然此书以Java开发作为范例，主要是来说明某些点上做进一步的阐述。

  每本书给人的启发不尽相同，它给我的最大感触是建立一套成体系的规范的流程非常重要。

  那么说到持续集成，那么就来叨叨下怎么成为一名顶级的DevOps工程师。

  软件世界的战场

  如果你对devops的概念不是很了解的话，没有关系，可以先跳到维基百科阅读一下DevOps条目。有了模模糊糊的概念之后， 我们先抛开所有市面上对于devops的各种夸大和炒作，首先来思考一下为什么近年来会出现这么一个职位。

   

  在软件开发中，一个人可以孤军奋战身兼数职：产品设计，开发，测试，运维等等。无需考虑多人协作带来的沟通成本，很好地控制项目进度。

  可惜，这种美好景象仅在小项目或者项目初期会出现，一个优秀的产品往往是由众多子项目组成，是一个庞大的系统工程，需要多人的协作才能使之如期交付。

  在一个公司的研发部门中，每一个项目常常会涉及到开发团队，测试团队，运维团队。项目leader在设计好架构和确定技术路线之后，会将开发任务按功能和模块分给开发团队，开发人员完成开发后，交给测试人员进行测试，反复迭代直到通过集成测试完成预期目标，交给运维团队去完成产品的交付或上线。期间会有项目经理持续跟踪进度。是曾相识么，这就是软件公司以及互联网公司中最常见的软件开发的场景了。

   

  这个过程看上去不是挺不错的么，有什么问题？

  问题很大，就像是在谈现实和理想。

  首先，技术主管给出的架构并不是那么合理，并且也没有做到把业务完全解耦和模块化，在开发过程中，才发现那些看似相互独立的开发工作，还有强依赖关系。

  接着，在给出的技术路线中使用了一些很cool的语言，开发框架，设计模式，但是暗中布满了密密麻麻还没跌过的坑，留下了运维隐患。在随后的线上运维中，相关的开发/运维人员发现了一些很诡异的现象却只能抓耳挠腮。

  然后，开发人员的水平参差不齐，在随手写出惊为天书的代码的同时，还免费附赠了一堆已知和未知的bug，导致后人在接替工作或维护的时候，几乎看不懂前人留下的神奇符号，然后就是重构，重构，重构。

  同时，代码的版本管理毫无章法，最终在部署的时候出现了大量问题。

  随后，测试人员拿到刚出炉的代码后直呼开发人员坑爹却没能力挽狂澜擒下所有臭虫，留下了一些未知的bug，这些彩蛋将会伴随着运维人员手机上的午夜凶铃逐一浮现。

  终于到了集成的日子，每个小组拿着子系统/模块/组件ABCDE进行整合，跑集成测试的时候发现了各种不可预料的问题，原定本周交付的项目突然变得无法预期。

  最后，代码终于到了运维人员的手里，接力棒到了最后一公里，这里将会是最混乱的战场：运维人员参考开发人员给出的部署文档，进行部署，可惜有些开发人员的文档写得很烂，更多的是不写文档，跑过来递给运维人员一支芙蓉王，你只需要执行我精心准备的start.sh就可以运行了。接着，运维人员对软件进行编译，打包，有时被后面虎视眈眈的项目经理逼得丢弃了节操，怎么快捷就怎么来，KPI is more important，直接上源码。在经过几次测试后，胆战心惊地把软件交付给了客户，或是将服务上线。

  那么，接力棒传送就此结束了吗？ 在随后的日子里，运维人员每晚都会被该死的报警短信吵醒，为了业务赶紧恢复正常，开发人员测试也没写赶紧把bug hotfix了，有的甚至直接在线上环境就进行了修改。

  接着大家就睡觉了，一觉起来的时候已经忘记了昨晚发生的一切，直到某日，开发人员把新的升级包部署上去，结果旧bug又复活了，同时新版本又引入了新的bug，服务无法正常启动。运维人员需要进行回滚操作，但是预先就没有考虑回滚策略，只好手动进行回滚操作，却发现数据库表格式居然也变了…

  另外一边的世界是客户的浏览器：503 Service UnAvailable。 卧槽，这是什么破网站。

  然后Boss在听完业务部经理的汇报后，怒气冲冲地召集了研发部的所有老大们。研发，测试，运维的老大们开始了激烈的相互吐槽...

   

  全剧终。

   

  我们该怎么办

   

  大量的事实表明，在大型企业中会滋生更多的“我们 VS 他们”的部落文化而阻碍了生产力。而且这些部落文化并不仅限于“开发 VS 运维”，同时也存在于“产品 VS 销售”，“市场 VS 开发”以及“开发 VS 质量保证”等。

  在实际的场景中，开发组老大为了争取在XX技术会议上吹嘘一番，总是乐于往新版本里引入新技术新框架，加入尽可能多的新特性；而运维组老大出于对运维稳定性的考虑，总是倾向于变化越少越好。项目经理则总是希望开发进度越快越好，为了进度不停逼迫开发人员砍掉一些测试，等等等。

   

  如果，我是说如果：

  如果，负责架构的哥们，可以把解耦做得再好点。

  如果，负责技术路线的哥们，可以从运维的角度出发，多使用一些成熟的技术。

  如果，开发人员再努力一些，提高本身的代码质量。

  如果，测试人员的覆盖率再高一些，多捉住几只臭虫。

  如果，运维人员再经验丰富一些，熟悉市面上所有主流和新兴的技术，会使用先进的自动化工具来进行部署和监控。

  可惜，没有如果。

  对于架构的设计需要长时间高强度的积累，不是用心就能做到完美的。

  新技术的使用将会提高生产力，同时带来潜在的隐患，仅通过数天时间的技术调研而不深入使用是无法断言手上正握着的双刃剑到底是哪一面对着自己。

  开发人员的水平是受诸多因素影响的，你不可能对着最牛逼的那个开发者按ctrl+c,ctrl+v。

  测试只是减少故障发生的概率，而不能避免没有bug。

  同样的，运维人员也不可能对于每种技术细节了如指掌。

   

  你应该干什么

   

  上述是我们很难去改变的。

  但是

  这时候你出现了，大吼一声我是DevOps。

  别人以看外星人的眼神瞪着你：DevOps这个职位存在的意思是什么？

  我们的存在是为了团队的和谐和幸福。

  我们现在都很苦逼，你能帮助我们摆脱这种困境？

  我们将会采用统一的规约和完善的工具链来改善当前的僵局。

   

  统一的代码管理

  首先在代码的版本控制上必须有一个统一标准，细致到仓库的命名和分类，代码分支的规约以及软件的发布周期管理都必须有一个统一规范来约束。

  为什么这需要由DevOps来做？首先，研发、测试和运维部门都是会涉及到代码的管理，因此需要有人来统一所有部门的代码管理，其次在版本控制和分支开发规范上，使得所有人员只需要阅读同一份文档，就可以完成相应的协同工作，例如某开发小组喜欢用master作为develop分支，而其他小组则用master分支作为production分支，这将导致运维人员在部署时就需要分散精力去区别对待。

   

  严格的代码审查机制

  其次在代码的质量上，引入代码审查机制，让有经验的开发人员来审查其他人的代码，从而来减少bug，提高代码的质量。

  当然人工审查并不能保证代码的万无一失，在每次代码提交中，就应该附带相应的测试代码，通过自动化的测试工具，确保每次提交的代码逻辑上符合期望。

  同时，将只有通过了测试和人工审查的代码入库并打包。

   

  频繁的集成构建

  从项目可以进行集成的当天起，所有项目将被进行频繁地集成构建，运行单元测试，功能测试，人肉测试等等，并将构建失败的错误日志发送给相关人员，然后找出导致这次集成失败的原因，并且必须在当天解决。

  频繁的集成构建把留到最终的集成风险平摊到了每一天，使得项目的开发进度变得可控。

   

  生产环境的所有操作拒绝人工干预

  我们将使用生命周期管理和系统配置管理工具编写部署代码，在编写这些脚本前，你需要和开发/运维人员反复地沟通，在规范问题上不要做任何的妥协，直到完成目标。最后将这些部署代码交付给运维人员，所有的软件部署通过工具自动完成而无需人工干预。

   

  加强各小组间的沟通

  在软件开发的整个流程中，开发不懂运维，运维不懂开发是很常见的事情，因为我们要加强各小组间的沟通，我们会去了解DBA们为什么会讨厌那几个做后端的开发人员，运维人员为什么会在埋怨某个项目的部署。

   

   

  这里我隐藏了许多细节，从大体上给出了DevOps的主要职责所在。

   

  看到这里，你应该会眼前一亮，devops的职责之一是规范，规范是保证团队协作有序进行的先决条件。

  其次使用持续集成工具链如Gitlab,Jenkins,Gerrit,Foreman,Puppet等来替代人工操作，使用自动化的方法来减少重复劳动和避免人为造成的失误。

  另外一个重要工作是沟通，促进各种团队间的协作。

   

  我们需要专职的DevOps人员吗

   

  如果你发现你已经在做上述事情中的某一些时，其实你已经在做devops相关的工作了。那么是否可以让众人各领相应的活儿，而不需要设这么一个职位？

  我的回答是不可以。

  一个职位对应着一份职责。

  如果你是一个开发人员，运维小组的代码管理混乱你会去关心吗，你会为此负责吗？

  如果你是一个运维人员，开发小组的代码没有人审查也没有跑测试就推到仓库中，你会去关心，你会为此负责吗？

  但是如果你是devops人员，你必须纠正混乱的代码管理，你必须在源头上掐死没有人工审查和没有跑过测试的代码提交。

  所以，我们需要一个负责devops的人员。

  不过我并不赞同在一个小团队中设置一个专职的devops人员，在我看来，一个devops工程师，首先他得是一个合格的开发/测试/运维人员，devops表明他还担负着另一个重要的职责。

   

  因为，假如devops脱离了实际的岗位，就犹如纸上谈兵一般，无法触碰团队中的痛点，就无法解决实际问题。

  因此，一个“兼职”的devops才是我心目中理想的devops工程师。

   

  关于Top

  很庆幸你能耐着性子能阅读到这里，如果能胜任以上工作，恭喜你，你就是一个合格的DevOps工程师了。

  等等，文章的题目不是写着如何成为一名Top DevOps Engineer么？！

  额，我不认为想要成为顶级的Devops工程师仅仅通过阅读一篇陈词滥调的文章就能够速成的。实际上devops的活儿并不好做，作为devops必须强势，必须有话语权，否则你怎么去摆平研发，测试，运维组；作为devops必须熟悉甚至精通每个领域，否则你怎么去制定一套规范合理的规约；作为devops必须熟悉各种持续集成的工具，否则你怎么挑选符合团队实际需求的工具链；作为devops必须善于交流，否则你怎么去掌握每个人的真实想法。在成为一名devops之前，你应该有计划地把精力投入到Dev,Test和Ops各个领域，站在他们的角度来思考问题，然后再回到DevOps的位子上来，再去rethink应该怎么做。

  DevOps需要你去不断地尝试和调整，不要害怕失败和挫折，它们是积累宝贵经验的源泉，但是绝对不要在同样的坑里摔倒第二遍。 我喜欢这句话：所谓专家，就是在一个很小的领域里把所有错误都犯过了的人。