微服务分布式架构基础与实战：基于Spring Boot + Spring Cloud

分布式可以理解为人体器官，人体可看成分布式系统，大脑是注册中心的集群，四肢与器官是提供服务的微服务，前进的距离是微服务运行之后的返回值，消耗的体力是微服务中处理的逻辑，影响的记忆是某些微服务对数据库的增删改查。

工作需要，阅读加上实践，获益良多

我收获了分布式架构的优与劣以及它的发展过程。 1.之所以使用分布式系统，主要有两方面原因，一是增大系统容量，二是加强系统可用 。 2.一方面，由于单个机器的性能无法满足越来越大的任务量 ，应对大规模应用场景需要多台机器 ，所以需要 垂直或拆分业务系统，使其变成一个分布式架构 。 3.另一方面，当业务越来越关键时架构中不能够存在单点故障 是一个系统因为一台机器的问题导致整体的不可用 所以需要分布式架构 荣誉系统，消除单点故障，提高整个系统架构的可用性 。 3.除此之外，分布式系统还有模块重用度高 、开发和发布速度快、扩展性更高，团队协作流程 更完善等优势。 4.然而，所有的技术方案都是有得有失，分布式系统在解决上述问题的同时 也在系统设计，管理和运维等方面带来了很多问题 。为了解决这些问题以及衍生出来的子问题 就出现了 很多架构方式和 技术方法。 5.分布式系统的发展，从上世纪的模块化编程、面向世界设计、基于接口或构架设计自然演化出来了基于服务的架构基于服务的架构——SOA。 6.最开始的SOA架构与单体架构差别不大 服务和服务之间是高度耦合的。后来开始使用一个标准协议或中间件来联动其他关联的服务 。再后来出现了微服务架构 ，每个微服务都能独立完成运行，单体的数据库被微服务这样的架构分散在不同的服务中 。 7.微服务在集成，测试，运维和，服务管理等方面比较麻烦 需要Paas层的支持 。

还好。起码一个人写的，前后风格统一。

读者作为Java开发人员。粗略学习了一个月，感觉收货颇丰。一下是个人对于微服务的见解：传统的基于单块架构，对应传统的基于瀑布模型的传统软件开发，已不能适应互联网时代软件开发的要求。互联网应用的特点是，尽快发布简陋的版本，再根据外部反馈小规模快速迭代，拥抱变化。这就要求传统的软件工程要相应去哥新，以满足新要求。对于互联网公司的程序员/技术管理者/产品经理，一定要明白上面的道理，所谓的快速迭代绝对不只是版本发布周期变快了，而是整个一套方法论和工程实践都要调整。比如一周一个迭代版本，一周时间按传统模式你需求文档还没有敲定呢，人家就要求新版本上线，程序员如何写代码，测试人员如何测试都要调整。如何调整，答案就是xxx。微服务架构，即尽量将无相关的业务分离成独立的服务，通过RESTful互相间通信。读者总结了微服务出现的背景： 1 互联网软件两点特点：快速变化和用户量大； 2 敏捷方法深入人心，小步快步，快速迭代； 微服务的优势： 1 单个服务开发快速； 2 服务之间业务解耦； 3 总体架构可演进； 微服务的不足： 1 分布式系统增加了总体系统的复杂性； 2 性能开销变大； 3 运维复杂度高，测试、集成、发布、监控； 微服务架构配套的DEVOPS开发运维模式 DEVOPS的核心就是，团队垂直整合，内部充分信任，紧密沟通，可运行的产品大于文档！DEVOPS工具集包括：Docker轻量级虚拟化、代码静态检查工具、持续集成和持续发布工具、日志聚合工具、监控与告警机制、以及自动化测试。消息队列是异常编程模式的一项重要技术！是远程异步调用的基础。在大型分布式尤其是多层级分布系统中，同步调用的时延将变得不可接受！REST：资源 表述 状态转移 统一接口，其中统一接口有4中操作方式。 GET，获取资源；　OST，新建资源；　UT，更新资源；DELETE，销毁资源。 使用微服务架构改造已有项目是一项复杂棘手的工作。一般建议优先采用逐步迭代切换的模式，一步一步替换直至最后全部变为新的。总的来书，这本书的内容是值得去研究的。

以前没有过分布式经验，不过尼玛的成都面试全都要问分布式，于是找了点分布式的资料和书来看，说实话分布式确实挺难的，一开始看文档乱七八糟的资料网上太多了，也很杂，不过这本书由浅到深的讲了分布式架构，对很多东西进行了总结归纳，很合适刚入门和基础稍微差一些的人阅读，不用浪费时间去网上一堆东西里面去筛选适合自己的

编写的形势比较新颖，易于理解，也不会像一般的书那样看久了就会觉得鼓噪，没兴趣了，书的内容不错，讲解的浅显易懂，这是我最新好的一本书了