行为设计学读后感_微服务设计读后感10篇

【www.cubkforchild.com--经济著作】

　　《微服务设计》是一本由[英] Sam Newman著作，人民邮电出版社出版的平装图书，本书定价：69.00元，页数：228，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。

　　《微服务设计》读后感(一)：大咖经验分享，十足干货

　　在中亚买了这本电子书，越看越喜欢，很对路的感觉，一个星期内利用上下班坐车时间看完了。

　　作为专业书，全书没有一行代码，这是非常难的的，但有比代码更复杂和深沉的思考。如果你没有做过类似系统，或没有从系统架构弹性的思维角度去考虑系统的组织和设计，对书中的很多内容可能会一带而过，但是只要你有做过或参与过，就很容易引起共鸣。是的，就是这样做的，如果当时我这样做就好了。这是我读这本书过程中，经常会生出这样的想法，想要拍案而起。

　　本书不会告诉你一个具体问题怎么解决，不针对任何一门语言或框架(虽然作者以JAVA背景说明的案例比较多，介绍的工具也大多是JAVA语言的)，不同技术领域的技术人员都可以阅读本书。

　　特别是第二，四，五，六，十一章，特别多干货。详细讲述了系统集成，分解，日志，测试，监控，缓存，分布式等会遇到的问题和解决方案。有几个方案我也用到过，有些没用上的以后可以试试。

　　比如，”系统架构和组织架构是相互影响的“，“保证API的技术无关性”，“断路器”，“单一服务单一服务器”。。。

　　也曾经在一些方面遇到过坑。例如“单一服务单一服务器”，我们之前在一台服务器上部署了多个系统，用了1，2年都很正常。这时候，某个系统要新增一个服务，需要升级php版本，这样做肯定会影响其它子系统。而且，用的服务器是ubuntu 12.01的，支持不了php升级。这样就尴尬了。最后，只能找个php 山寨写法解决这个问题。

　　曾经做过一个消息队列系统，在调用下游服务的时候也考虑了超时因素，但是正如书上说的，如果下游服务挂了，还是重复去请求，每次都超时，会导致任务一直堆积，而且也可能导致整个消息队列缓慢。作者介绍了断路器的方案，很有价值。

　　这本书值得多读几遍，会有更多心得

　　《微服务设计》读后感(二)：两个超越

　　一千个人眼中就会有一千个哈姆雷特，这句话可能大家都很熟悉，那么我要问一个问题，这一千个哈姆雷特到底有没有高地上下之分呢？我的答案是有的，而且我相信大家也会同意这一点，尽管评判角度不同，高地上下的具体结果也不同。微服务同样也是这个道理，尽管微服务是一个软件开发中的技术问题，相对于文学作品中的人物，显得确定性更大一些，但是这种确定性还是没有大到可以让人们在这个问题上达成绝对共识，更何况微服务这种技术思想本身和它的具体技术实现都处于流变之中，不断演进不断变化，所以这种共识本身也处于不断演进之中。因为共识不可得，所以共识就不再重要，真正重要的反而是关于问题的高见，而本书显然就是关于微服务的一种高见或者是高见的组合。 之所以本书在微服务问题上有见地，在与本书能够从系统论或者是从一种应用构建整体环境的角度看待微服务，超越了一般观点只是停留在软件开发、软件架构这个层次上谈微服务。具体来讲有以下几个超越，第一个是超越了技术，从业务技术一体化的角度谈微服务。就想传统SOA时代一样，一般观点总是在反复强调软件要高内聚、低耦合，实现软件服务化，服务提供者要隐藏实现细节，只暴露契约接口，做到独立自主，其修改和调整不影响消费者。但是以上这些只是目标和原则的混合，更多的是技术上的追求，但是更重要的问题是我们怎样划分服务领域，依据是什么，功能还是业务，服务领域到底是多大为好，好的依据和评判标准又是什么？作者在这些问题上提出了自己的经验和洞见，也只有在这些问题上有了清晰的思路，业务问题和微服务技术才有了真正的桥梁，否则只会出现站在技术上望业务，得到似是而非的解决方案。二是超越了软件开发本身。微服务本身是软件架构和开发技术，但是这种技术需要一个配套的支撑环境来支持才可以真正发挥它的作用和价值，体现这种架构的优势，如果只及一点不及其余，只关注微服务的技术实现这个环节的事情，不考虑操作系统、硬件、虚拟化等方面技术和资源的综合考虑和配套，微服务的价值也不可很好的体现。作者在这方面的贡献就是综合考虑了操作系统的虚拟化、容器化、微服务配套的CD和CI、微服务环境下的安全、规模化和系统扩展问题，基于开阔的视野、丰富的经验，提供了一套系统的微服务思维模板。尽管单独拿出其中某一块来感觉都不是特别详实，略感单薄，但是作为整体来讲覆盖全面，对于项目中涉及微服务的人事来讲是一本快速发现并扫除盲点的好书， 也就是说可能本书不能告诉你所有的知识，但是可以第一时间告诉你应该考虑和关注哪些问题。也就是说这本书会提醒你考虑什么、怎么思考才是对的。

　　《微服务设计》读后感(三)：什么时候你不应该使用微服务

　　最近几年我一直在微服务相关的工作，编码、学习模式、寻找并使用开源工具，到大会做分享…… 这本《微服务设计》我读起来还是有很多比较切身的感触的，这里记录下。

　　首先这本书最后一章有一段说的特别好，“你越不了解一个领域，为服务找到合适的界限上下文就越难……服务的界限划分错误，可能会导致不得不频繁地更改服务间的协作，而这种更改成本更高……”，软件行业从业者，尤其是那些已经不写代码的从业者，总会期望有银弹，但银弹终究是没有的，微服务也是。

　　我个人觉得微服务本质上是要解决一个 Scalability 的问题，这里的 Scalability 不仅仅是指应对用户量增加，还指业务复杂度增加，数据量增加，团队人员增加（具体参考《The Art of Scalability》一书）。微服务的一套方法论和具体实践方法给我们指了一条路，但路总是需要自己走的。

　　这本书的大量内容是对于其他书籍的提炼并用更现代化的语言阐述，例如，要理解微服务你不得不去阅读《领域驱动设计》（或者《实现领域驱动设计》），因为所有服务都是围绕领域来的；例如，要懂得如何应对大量服务的快速发布，你需要去阅读《持续交付》，再补充 Docker 相关的知识；例如，要学会如何保证大量服务交互时候的稳定性，你需要去阅读《Release It!》；此外，常见的分布式知识，如负载均衡、CAP理论，如何使用缓存，该学的你一样都不能拉下；对了，你还得知道 DevOps 以及如何监控你的系统和服务（可惜未见比较好的关于监控的书籍，有朋友知道的话请推荐）。

　　书中的第4，5章是我觉得比较有原创性的内容，怎么拆分一个巨型应用，第5章有很多切实的建议；而第4章告诉你，当你有一堆形状各异的服务的时候，他们之间集成可能会遇到什么麻烦，以及如何避免及应对。

　　不过，我不得不说，这书完全不适合编程新手阅读，因此书中几乎没有什么样例代码可以拿去实践的，而书中涉及了大量的开源工具，随便拉一个如 Hystrix, Dropwizard"s Metrics 都可以去研究好几天，我是非常佩服作者的视野的。

　　没打五星的另外一个原因是，我读毕没有感觉啊哈！意思就是，书的结构并没有给我一个清晰的系统或者脉络，我自认已经实践过了书中六七成的内容，心中也没有一个清晰的系统抽象，本来指望这本书能有所帮助，然而还是失望了。

　　如果你在维护巨型应用并濒临死亡，那么还是应该走微服务这条活路的，但可以想象死而复生的道路比死亡本身难很多。

　　《微服务设计》读后感(四)：组织架构和工程架构

　　gt; 如果你有四个小组开发编译器，那么你会得到一个四步编译器。

　　这是《新黑客字典》的说法。

　　另一种更学术化的说法是：

　　gt; 任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通架构保持一致。

　　如果一个系统很大，以至于开发的它的人分成了很多个小组。显然，一个小组负责一个模块是非常好的管理方式。

　　模块之间怎么交互？自然，我们可以直接调用，也可以使用服务来互相调用。

　　这本书讲述的就是如果使用服务来互相调用的方式来制作大项目的方式。

　　服务该怎么划分呢？书里面给出的准则是能够在2周内完成的。我的意见是开发人员也不要超过6个人，毕竟在一起吃饭，这是最多的人了。

　　很多服务，意味着很多服务器，也意味着严重的网络依赖。我们需要考虑应对机房故障，应对各种微服务特有的问题。时常演习，比如某机房坏掉了，或者地震洪水，网络丢包严重。

　　他提到技术有：

　　Java RMI

　　Thrift

　　rotocol buffers

　　Mongo

　　Cassandra

　　quid

　　Varnish

　　Zookeeper

　　Consul

　　acker

　　Vagrand

　　Eureka

　　wagger

　　HAL

　　《微服务设计》读后感(五)：微服务改造——拥有技术信仰团队的系统级重构

　　当PaaS（Platform as a service）已不是什么新鲜名词的时代，我们每天面对这各种各样的新兴技术名词，哪怕作为一名所谓的业内人士，我已然清晰地记得当2017年初的某个初晨，工位隔壁的同事兴奋地对我说“Hi，Bill 听说北京团队开始做FaaS了”时自己的一脸懵逼，心里暗想什么是FaaS（function as a service）？相比FaaS、CaaS之类的技术名词，微服务相对而言直观很多，看过简介之后大家都会有一个较为清晰的印象。

　　微服务的产生背景是什么？

　　从2011年Cloud Foundry的诞生到2013年docker横空出世以及时至今日已成为事实标准的Kubernates使得服务的部署、托管模式与旧时代基于物理机/虚拟机的直接部署、管理诀别。CI/CD等相关技术与思想大大加快软件开发（生产服务）的进程，而愈发智能、稳定的云端部署、托管平台同时又为大规模服务的管理、稳定性保证、快速水平扩容提供了支持。今天的应用面对的用户个性化需求纷繁，流量压力剧增。微服务化应用正是在此大背景之下应运而生。如果说Martin Fowler的《重构》一书向我们展示了代码层面的可扩展、可维护、追求卓越代码风格的相关技艺。那么本书便为我们展示了云计算基础设施日益完善的今天，大规模应用的系统架构级别的重构技艺。

　　统一思想

　　为什么我们需要微服务？

　　1、快速迭代（当今时代的生存法则），用户的需求、热点变化迅速，单一系统犹如一个巨兽，每个子系统必须完成整合才能完成一次迭代，这时某个迭代缓慢的子系统哪怕不存在兼容性问题也会拖慢整个团队的进度。

　　2、更为独立的子模块使得其可维护性、开发难度、迭代速度都得到提升；

　　3、可以更为精确定位每个子模块的性能瓶颈，为精确快速的系统水平扩容、服务升级提供可能；

　　4、降低技术团队人力成本，专有模块由专组维护，无论是从新人培养亦或是功能开发都更为节约人力，毕竟理解一个子模块远比理解整个系统简单。

　　为什么我们不需要微服务？

　　1、我们的应用还处于一个初期阶段，功能还很单一；

　　2、我们对于当前应用领域的理解还不够深入，目前尚无法合理的定义服务边界；

　　3、我们依赖的基础设施尚不具备微服务化改造后的系统稳定性保障。

　　我们的友军

　　1、完善的CI/CD及部署流程及系统（这是快速迭代、验证的保证）；

　　2、拥有技术信仰和乐于拥抱变化的团队；

　　3、对相关领域、应用场景和现有系统的深刻理解；

　　4、设计良好、具备可维护性的现存代码。

　　我们的敌人

　　1、丑陋的代码与一团乱麻的紧耦合依赖关系；

　　2、得过且过的敷衍态度（相信我，我已经在职业生涯中不止一次见到所谓的临时方便成为蹩脚的长期方案）；

　　3、不合理的KPI与绩效审核标准（没错，你没有看错），国内公司很多急功近利，大家都喜欢新的东西，而认为耗费人力去重构、改造一个蹩脚的系统的收益不足以歌功颂德。

　　战略实施

　　微服务化前置

　　1、本次参与微服务化改造的团队成员都对现有系统有较为深入的理解，熟悉相关技术栈，了解目前架构的组成与瓶颈；

　　2、我们已经准备好了CI/CD及微服务化中间过程测试环境、最终结果的生产环境；

　　微服务化进程

　　1、团队会议，大家一起解读、梳理现有架构可以拆分为多少个规模合理、职责清晰的子模块，并清晰辨识、定义新的服务边界；

　　2、确定微服务化各个子模块之间的通信、交互模式（Restful Api、RPC还是基于消息总线），选择合适的通信交互技术方案，这一部分可能兼具多种交互模式。

　　3、确定服务边界接口；

　　4、各个子模块负责人确定子模块的技术选型，开始开发迭代，同时保证单测。

　　5、每次迭代周期后进行集成、联调、功能测试。

　　微服务化后置

　　1、服务容量评估，新系统压测，确认线上资源配比；

　　2、线上部署，依赖成熟生产环境平台基础监控和服务治理方案提升稳定性、可用性。

　　3、测试流量接入，生产环境压测；

　　4、正式流量分批接入。

　　胜利后的世界

　　一群拥有技术信仰的同志们望着各个子模块之间的请求调用及系统稳定承接日益增长的流量，脸上洋溢着劳动过后收获成果的微笑，同时坚毅的眼神仿佛在说，“我们已准备好迎接新的挑战”。

　　《微服务设计》读后感(六)：很有广度的一本介绍微服务的书

　　本书是2016年出版的，英文版是2015年出版的，微服务算是比较新的一项技术（或思想）。本书以宏观的角度讲述了微服务的理论思想，从下面的目录架构也能看出来，作者在第2章用了一章的篇幅讲了微服务中的架构师角色。什么是微服务？ 微服务如何寻找平衡？ 如何测试？等等，这些问题作者在书中都作了解答。

　　书的广度很广，介绍了很多工具、架构以及书，深度就需要自己再探索。虽说是介绍微服务的，但很多思想对于分布式架构也能适用。总而言之，很是本扩展知识面的难得的好书~

　　写了详细书摘（包括书中提到的技术、扩展阅读的书、重要的图等），放在了自己的博客里，就不重复粘帖了~ 感谢作者。

　　书摘戳: O"Reilly出版《微服务设计》阅读整理

　　《微服务设计》读后感(七)：指路

　　职业目标是架构师, 专注方向是分布式和微服务. 把这两点确定后, 微服务设计是我看的第一本关于微服务的书.

　　春节在家囫囵吞枣的刷了一半, 这两天回公司, 周末把它看完了, 算是对微服务有了一个概念性的了解吧.

　　这本书主要对微服务的定义, 服务架构演化, 服务建模, 服务的集成, 单块服务的分解, 服务部署, 测试, 监控, 安全, 以及公司结构与服务结构的关系以及规模化时会遇到的负载均衡, 系统扩展, 缓存, 服务注册, 接口文档等等在微服务设计时会遇到的问题的各个方面进行了一个高屋建瓴的描述.

　　可以看出作者是一个经验非常丰富的工程师, 书比较新, 书中提到的一些技术方案和框架比较有借鉴意义.

　　同时对于我这个新人来说, 看完此书, 也对微服务有了个总的了解. 对以后的路有一定指导意义.

本文来源：http://www.cubkforchild.com/jjwk/45902.html