2019书单

一、《SpringBoot实战》第四版 Craig Walls 著 / 丁雪峰 译

目的
    简化Spring开发，快速搭建应用程序，让程序员专注业务开发。

核心
    1. 自动配置：通过发现classpath下的库为应用程序生成并注入相应的Bean，不再需要通过xml或代码形式声明Bean。

    2. 起步依赖：将具有支持某个功能的多个包整合在一个start起步依赖中，开发者只需要引入这个起步依赖，SpringBoot会帮我们添加这个起步依赖中涉及到的相关包(多个包的集合)，且这些包的引入都是经过测试的，不用担心包与版本的冲突问题。

    3. SpringBoot CLI 命令行界面（SpringBoot结合Groovy语言，在命令行下运行应用程序）。感觉用得不多，浏览而过。

    4. Actuator：监听程序在运行过程中内部情况，通过Web端点和shell界面向外界提供信息
         Spring应用程序上下文里配置的Bean
         Spring Boot的自动配置做的决策
         应用程序取到的环境变量、系统属性、配置属性和命令行参数
         应用程序里线程的当前状态
         应用程序最近处理过的HTTP请求的追踪情况
         各种和内存用量、垃圾回收、Web请求以及数据源用量相关的指标

共八章，前四章比较实用，第一章，概述SpringBoot；第二章，入门Demo，第三章，自定义配置，第四章，测试相关。

后四章主要讲Groovy，Grails在SpringBoot中的使用及SpringBoot应用程序的部署，感觉跟日常工作相关不大，快速浏览过了。

总结

    SpringBoot不是新技术，只是对已有的技术做了整合，简化了开发过程，并不难，此书也讲得比较浅，算是一个入门。

二、《RabbitMQ》  没有作者简介和书本介绍

        第一章 RabbitMQ及消息中间件简介
         实质：存储转发（个人认为）
         优点：解耦、异步、削峰、跨平台、可实现分布式系统的跨进程通信。
         缺点：系统复杂度提高(需要考虑消息丢失、消息重复消费等问题，还有就是代码阅读难度加大，例现有项目消息线路太多，刚上项目去整理业务线真是...)、系统稳定性降低(若消息中间件宕机或出故障，会导致消息未发出而得不到消费导致业务未正确执行下去)
         消息中间件需要解决的问题：消息顺序性、确保消息的正确消费，高可用稳定性等就不用说了。（待完善）
         RabbitMQ：支持多语言、多协议(基于AMQP：它是应用层协议的一个开放标准，以解决众多消息中间件的需求和拓扑结 构问题 。 它为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受 产品、开发语 言等条件的限制 。 )
       第二章 RabbitMQ入门
        RabbitMQ相关概念介绍：生产者、消费者、队列、交换器、路由键、绑定等。
        AMQP协议、RabbitMQ对AMQP的实现
       第三章 开发指南
        略
       第四章 RabbitMQ进阶(干货)
         死信队列、延迟队列、优先级队列、RPC实现、持久化、消息传输保障等
       第五章 RabbitMQ管理
         用户创建、权限管理与分配、应用启动关闭、日志、集群管理相关。
       第六章 RabbitMQ配置
         调优，略
       第七章 RabbitMQ运维
          集群、扩容、故障修复、监控相关
       第八章 跨越集群的界限
          看得比较略，讲了两种broker之间传递消息的方式。可用在但不限于消息堆积的场景。（较高阶，有需求时再作详细了解）
          

       第九章 RabbitMQ高阶
         存储机制、内存磁盘告警、流控、镜像队列；高级，略。
       第十章 网络分区
         高级，略。（没太看懂，大致是因为某些故障产生了隔离的网络，使某些broker处在隔离的网络中进而在生产和消费消息使发生错误，例如找不到目标队列或交换器）
       第十一章 RabbitMQ扩展
        消息追踪与负载均衡，高级；略。

这篇将消息中间件的讲得很棒：https://blog.csdn.net/qq_39470733/article/details/80576013

三、《Spring Cloud 微服务实战》 翟永超著
        笔记有点多，有点乱..

微服务化——>引发系列问题需要解决——>衍生各类框架解决问题

SpringCloud拥有全套解决方案

第二章 SpringBoot 略

第三章 服务治理Spring Cloud Eureka

第四章 客户端负载均衡 Spring Cloud Ribbon：主要说明了Ribbon实现负载均衡的原理以及源码分析

实际是通过使用了@LoadBalanced注解RestTemplate实现的。

第五章 服务容错保护: Spring Cloud Hystrix

传统架构应该也有这样的问题吧？

如上所说依赖隔离(使用线程池)可以避免服务之间的相互影响，那多相互依赖的服务是部署在同一台机器上了？

关于依赖服务的线程池隔离。应该是指调用方的，将调用依赖服务的线程池隔离
 

就算这个线程池满了被hang住，不会导致其他依赖服务的线程不可用，这样就不会导致本服务的整个不可用（例如服务A同时依赖B，C服务，接口b中依赖服务B，接口c中依赖服务C，若服务C一直未返回结果，将导致依赖服务C的线程池被耗尽，而调用依赖服务B的线程池不会受影响，接口b依然可以继续提供服务，整个A服务也可以继续提供其他服务）

按照我之前理解的是服务提供方的线程隔离(一台机器有多个服务)，这些服务肯定是在不同的进程中呀~~，比线程隔离得还厉害
依赖隔离，是指服务调用方还是提供方
问题点：补偿机制、持续交付平台
A——>B——>C——>A 出现循环调用怎么办？

容器化
eureka-client：获取可用的服务列表(服务发现)

Ribbon：客户端负载均衡，基于可用服务列表选择策略(服务消费者)
Feign：整合Hystix和Ribbon

需要注意的是：客户端并不是每次都去注册中心获取服务提供者的地址或者第一次拿了之后就再也不拿了。而是定时去注册中心获取服务提供者地址(因为存在服务提供者下线，某些服务提供者不可用的情况)，而服务提供者需要定时向注册中心汇报自己的情况(心跳检测)

第六章 Spring Cloud Feigin

封装了Ribbon，Hystrix，业务开发人员也不用写RestTemplate去调用服务了

Spring Cloud Ribbon重试机制

第七章 Spring Cloud Zuul

第八章 Spring Cloud Config

第九章 Spring Cloud Bus

不通过消息总线的话，则需要web hook多个微服务应用

第十章 消息驱动的微服务: Spring Cloud Stream 略

第十一章 分布式服务跟踪 Spring Cloud Sleuth 概览 （类似鹰眼?）
跟踪请求、服务的调用、响应、耗时情况(请求可来自消息、http、Zuul代理)，可以将该信息抽取到日志系统(Logstash、Zipkin)，进行日志分析、可视化等(ELK)，便于定位问题