《微服务架构与实践》读后感10篇
《微服务架构与实践》是一本由王磊著作，电子工业出版社出版的平装图书，本书定价：65.00，页数：236，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《微服务架构与实践》读后感(一)：梳理下概念
这本书比较泛泛而谈, 适合用来梳理下微服务的概念. 前面对微服务技术发展的总结不错, 后面实践部分的配置意义不大(细节可以 Google). 贴一下笔记.
## 单块架构
随着时代的发展, 软件系统中的逻辑通常被分为 3 层结构: 表示层, 业务逻辑层, 数据访问层. 分层是在逻辑上的, 最终构建成一个发布包, 运行在同一个进程中, 这就是单块架构.
单块架构易于部署(所有功能都会打成一个包), 易于水平伸缩(增加新的节点, 直接运行). 但仍面临挑战:
开发上的挑战:
1) 随着团队的增加, 团队中沟通协调的成本显著(非线性)增加.
2) 随着单块应用代码量的增加, 对代码做修改的成本显著(非线性)增加, 部署流水线时间增加. 容易陷入”修复越多, 缺陷越多”的恶性循环.
4) 技术栈难以升级, 代码量的增加导致依赖固化, 难以升级
性能上的挑战:
1) 容易水平扩展, 但扩展不能充分利用资源. 比如 cpu 和 内存, 如果整体应用偏向 cpu, 那么每个节点都会有闲置的内存资源; 反之, 每个节点都有闲置的 cpu 资源.
## 微服务架构
关键就是”拆”: 将单一应用拆分为一组服务, 服务间互相协调, 配合. 具体来说, 每个服务运行在独立的进程中, 能被独立地部署到生产环境; 服务间通过通信机制相互配合(RESTful API / 专有协议).
具体来说, 先要考虑以下几点:
**粒度**
微服务的粒度遵循业务逻辑上的单一职责和团队上的独立.
**轻量级通信**
**独立性**
开发团队, 测试, 构建, 部署的独立, 数据库独立
难点在数据一致性/异步, 同时在性能和运维监控(配置, 部署, 监控报警, 日志收集)方面面临挑战. 因为微服务粒度更小, 功能和边界清晰, 功能方面的问题更少, 而服务构建方面比传统的单块应用复杂(DevOps).
## 实践
基于 GitHub, Docker Hub, Snap-CI 来构建持续交付流水线. 主要是工具的配置, 几页几页的配置项, 水分多.
**日志聚合**
用的 Splunk. 又是讲的如何配置
**监控报警**
用的 Nagios.
## 持续交付
RUP -> 敏捷 -> XP -> Scrum -> 精益创业 -> DevOps 过程中一直降低交付成本, 提高效率. 我的理解是, 尽量压缩开发与产品间的空间, 提升开发 -> 部署 -> 使用过程的一致性(连续性). 微服务化导致应用更多, 联系更复杂, 粒度更小, 发布更频繁; 因此需要把以前的编译/打包/发布改成了更精细的流水线.
**持续集成**
Jenkins
**轻量级通信**
1. 当前的 RPC: Thrift / protocol buffers. 面向对象的 RPC.
2. RESTful 风格: 基于 HTTP, 因此有性能问题(对比二进制协议)
3. 消息队列. 典型的场景是: 注册后系统发送邮件. 触发消费事件的两种模式: 1) 消费者定时 pull 2) 发布者发布时 push
《微服务架构与实践》读后感(二)：书评书评
应邀来评价一下这本书～
对于曾经在TW呆过一阵的人来说，看到这本书的目录很是心喜。因为几乎概括了TW现阶段推行的所有东西。从章节设计上还是十分用心的，涵盖了一种很‘时尚’的开发模式中的方方面面，ruby开发中的api框架grape，异步队列框架sidekiq，tdd（或者说准bdd--rspec），pact测试;虚拟化的docker，aws;devops要知道的splunk，nagios等;敏捷开发中的snapci;restful api设计中的hal等。
但是这意味这一件事，要么这本书巨厚无比，要么只是泛泛而谈。
而实际上，这本书的页码大概是两百多页，所以是相对宽泛型的介绍型的。
读者在看之前最好已经具备了一定的ruby技能，aws技能，另外对tdd至少也要有一定认识，并且认为其是必要的才行。否则，读起来意义就不大了。
整体来说，读后的感觉是标题太小，内容太大，页数太少，略显跳跃。如果你在tw呆过，你会知道这里的内容实际真的是源于真实项目中的实践，但是如果你不整ruby，也用不起/了aws，那么这本书中的实践一词可能就略显苍白了。
或许这本书更适合改成《ruby云端微服务敏捷开发实践》之类的名字，然后把内容增至600页左右，让每个读者都能相对容易的实践其中的例子而不是只是想读软工的书那般草草略过，同时对于每个章节也更加深入的谈一些，才更有推广性。考虑到中国国情，最好把aws改成aliyun，splunk换成elk套件。还有就是书中的代码排版和贴图真心一般般了，能不能把aws的模板和snapci的回显示压缩或略去呢？本身页数少，章节多，不够深入了，这两部分的代码又占据了一些页码实在让人于心不忍了。
愿下一版能改善这些问题。
《微服务架构与实践》读后感(三)：该书帮助我理清了LXK项目2.0重构的思路
传统的基于单块架构，对应传统的基于瀑布模型的传统软件开发，已不能适应互联网时代软件开发的要求。互联网应用的特点是，尽快发布简陋的版本，再根据外部反馈小规模快速迭代，拥抱变化。这就要求传统的软件工程要相应去哥新，以满足新要求。
对于互联网公司的程序员/技术管理者/产品经理，一定要明白上面的道理，所谓的快速迭代绝对不只是版本发布周期变快了，而是整个一套方法论和工程实践都要调整。比如一周一个迭代版本，一周时间按传统模式你需求文档还没有敲定呢，人家就要求新版本上线，程序员如何写代码，测试人员如何测试都要调整。如何调整，答案就是xxx。
微服务架构，即尽量将无相关的业务分离成独立的服务，通过RESTful互相间通信。
1 互联网软件两点特点：快速变化和用户量大；
2 敏捷方法深入人心，小步快步，快速迭代；
微服务的优势：
1 单个服务开发快速；
2 服务之间业务解耦；
3 总体架构可演进；
微服务的不足：
1 分布式系统增加了总体系统的复杂性；
2 性能开销变大；
3 运维复杂度高，测试、集成、发布、监控；
微服务架构配套的DEVOPS开发运维模式！
DEVOPS的核心就是，团队垂直整合，内部充分信任，紧密沟通，可运行的产品大于文档！DEVOPS工具集包括：Docker轻量级虚拟化、代码静态检查工具、持续集成和持续发布工具、日志聚合工具、监控与告警机制、以及自动化测试。
消息队列是异常编程模式的一项重要技术！是远程异步调用的基础。在大型分布式尤其是多层级分布系统中，同步调用的时延将变得不可接受！
REST：资源 表述 状态转移 统一接口，其中统一接口有4中操作方式。
GET，获取资源；
OST，新建资源；
UT，更新资源；
DELETE，销毁资源。
使用微服务架构改造已有项目是一项复杂棘手的工作。一般建议优先采用逐步迭代切换的模式，一步一步替换直至最后全部变为新的。
《微服务架构与实践》读后感(四)：一群牛鬼蛇神相互吹捧的书
优点 1.微服务的概念介绍 2.微服务相关流程 3.测试理论 4.微服务改造举例(略简单) 缺点 1.docker部分内容过时了 2.废话和重复的话太多(通篇都有这个问题) 4.基于ruby介绍微服务，但变成了推销ruby 5.书中图画的又大又丑，明显是为了浪费版面才真么弄的 最令我觉得恶心的为这本书出来吆喝的这些人，呵呵，我要牢牢记住他们，免得后续再被忽悠~~一群相互吹捧的人