微服务架构设计模式的读后感大全

《微服务架构设计模式》是一本由[美]　克里斯?理查森（Chris Richardson）著作，机械工业出版社出版的平装-胶订图书，本书定价：139元，页数：2019-5，特精心收集的读后感，希望对大家能有帮助。

　　《微服务架构设计模式》精选点评：

●有很多值得反复思考的地方，而且本书最好的地方在于对于一种模式的评价既有优点又有缺点，讲解方式又符合思考过程，非常赞。

●好书总是值得花时间去慢慢研读！希望可以读完~

●介绍了很多实施方法，分析了每种方法的利弊，落地还需更多实践

●一般吧，可读性还是弱一些

●完全脱离淘系来源框架如何实践微服务架构，外国友人如说是。saga的不少实现思路，都可以在国内找到影子。新鲜的概念不多，"事件溯源"这个功能我很受教。整体来说，本书就是帮你从代码包围中上升，之后俯瞰整个应用。

●对微服务从设计到实现、测试、集成都做了非常详细的描述，同时将微服务和领域驱动设计做了很好的结合，总体来说是微服务领域最为完整的一本书。

●有时间再写书评

●“没有银弹”这个大原则是架构师存在并决策的原因。

●微服务系统知识树

●对微服务相关的问题讲的非常清楚，全面，对微服务化后出现的各种问题都有相关的解决方案以及代码示例可供参考，各种相关概念总结的非常到位。值得一读

《微服务架构设计模式》读后感(一)：很实用的书籍

本书涵盖了一些非常流行的概念，比如处理事务的Sagas、构建事件驱动系统的CQRS，以及如何进行测试。本书涵盖了一些非常流行的概念，比如处理事务的Sagas、构建事件驱动系统的CQRS，以及如何进行测试。本书涵盖了一些非常流行的概念，比如处理事务的Sagas、构建事件驱动系统的CQRS，以及如何进行测试。

《微服务架构设计模式》读后感(二)：这本讲“模式”的书竟然这么实用

一般来说，设计模式类的书籍大多非常抽象，但是这本书竟然能把微服务构建和实施过程中的的细节（或坑点）讲的如此清楚，真的很难得。国内这两年也出过不少微服务的书，但大多是讲“术”而不是“道”，而我认为，对于微服务方案来讲，“术”是最容易搞定的，比如你来个SpringCloud全家桶，“术”的问题就基本解决，更何况，SpringCloud/SpringBoot本身非常容易上手使用，让大家有一种我学会它就会做微服务一样的错觉，有时候这种错觉真的会害死人，大家不妨看看身边有多少工程是为了微服务而微服务...而这本书，以“道”为主，清晰讲解实施微服务的过程中，我们需要关注哪些问题，解决方案有哪些，然后辅以“术”，让人读起来非常爽。另外，这本书不太适合初级工程师，比较适合有一定工程实践经验的中高级工程师或架构师们看看！

《微服务架构设计模式》读后感(三)：想清楚再动的实用派架构设计方法论

花了几个月时间读完了这本《微服务架构设计模式》，真正感受到以前那种找技术文章学习的方式是很不系统的，对很多概念似懂非懂。

这本书，成书结构非常简单合理。从微服务架构要解决的问题出发，迅速推入到服务的拆分策略（业务能力 vs DDD子域）。往下分别触及到微服务架构设计的一些关键设计问题：进程间通信(同步 vs 异步)，事务管理(基于补偿事务的saga)，业务逻辑设计（聚合模式），事件溯源（另外一种可能性），微服务架构中实现查询(CQRS)，API Gateway模式，测试策略(测试金字塔模型)，安全性/可配置/可观测，微服务应用部署(语言相关发布包 vs 虚拟机 vs 容器 vs K8s vs Serverless)。文章的最末，作者介绍了从单体结构往微服务架构的比较切实的重构策略(绞杀者应用)。

作者不是一个理论派，从头到尾穿插着一个具体案例及相关java实现代码去对理论做印证。作者的态度，也不是为了微服务架构而微服务——“提取一项实现对业务至关重要且不断发展的功能的服务是值得的！”。整个软件设计的思维高度，颇为值得赞赏。

目前工作中面临的也确实是个大的单体服务，里面有一些上帝类和边界不清的类关系，同时业务发展的并行压力也很大。这本书的很多介绍对目前的工作还是颇有参考意义的。微服务架构的每一个点，篇幅所限这本书还是浅尝辄止，如果有需要的话，顺着引子还需要接着往下找更深入的书看。

《微服务架构设计模式》读后感(四)：让我重新认识了微服务

微服务是针对公司某一复杂业务程序实现的设计模式, 与巨石架构(Monolith)是相对的.

微服务对应的应该是公司业务能力层级上的拆分与设计, 为了减少业务之间的耦合而导致相互拖累, 在对外业务能力不变的情况下, 在应用内部将能力拆分成一些微小服务. 也可以理解为是对巨石架构进行"解耦".

举个例子: 原先公司做的是一个外卖系统, 这个系统中可能包含了客户下单, 商家接单, 骑手配送等功能. 但是全部都打包在一个程序中. 发版时, 可能客户下单功能修改了功能, 导致商家没办法接单了. 或者商家接单功能实现的有问题, 导致整个应用程序挂掉, 现在用户下不了单, 骑手也没法接单, 整个公司的业务就瘫痪了. 然后, 在客户下单-商家接单-骑手配送这个大业务流程不变的情况下, 我们在外卖系统内部, 分成了多个服务, 各个服务之间使用 API 松耦合通信, 隔离影响. 比如, 客户下单服务, 专门处理客户下单这一业务, 并将生成的订单推送到消息代理 (如:kafka) 或直接推送给其他服务等, 它只要能保证完成它的职责即可. 后者, 就可以称之为 "微服务架构". 当然, 这只是一个例子, 实际情况会更加复杂.

在<<微服务设计模式>> 中对微服务的定义:

> 将应用程序构建为松耦合, 可独立部署的一组服务

书中也对"微"的大小给了定义:

> 大小的定义为能够由小团队开发服务

不用刻意地去追求服务的大小. 微服务的落地, 往往就会伴随着, 组织结构和开发的流程的改变, 由不同的 **小团队** 独立负某一服务.

像我们现在如果提到微服务, 就经常也会提到一些微服务框架 go-zero, go-micro 或者基础设施 docker, k8s 或者工具 gRPC, prometheus 之类的.

像这种框架和组件之类的只是一种技术工具. 他们并不能定义微服务, 他们可能只是为了克服微服务架构设计带来的某一些缺陷, 或者与微服务结合可以发挥出更大的价值.

举个极端的例子: 在你后端业务完全不划分的情况下, 你甚至可以在 go-zero 的框架基础上, 将你公司所有的业务打包进一个应用程序, 用docker打包, 并部署在k8s环境中, 再通过 gRPC 与前端通信. 你用到了很多著名的名词技术, 但是你实现出来应用的是巨石架构还是微服务架构呢？