第六章 Spring Boot
1.Spring Boot
介绍：相当于模板，快速创建应用，每个服务项目通过boot引导创建，可定制成为任意服务。
特点：
1.快速构建Spring应用
2.内嵌tomcat、jetty容器，无须单独安装容器
3.简化maven、gradle配置
4.注解自动化配置Spring，实现零配置
5.与其他主流框架如Spring Cloud无缝集成
6.jar包直接运行
补充：官网或者某些IDE可定制化工程，界面选择需要的组件模块。
2.Spring Boot与微服务之间的关系
概述：它们之间没有直接关系。
1.Spring Boot不是微服务框架，只是个基础框架，只有加入了其他服务管理的组件后才叫微服务。
2.Spring Boot是目前Spring应用中最轻量级的，而微服务架构要求每个应用都必须轻量灵活，所以一定会用到Spring Boot。
p.s. Spring Cloud是微服务的实现方案之一，所以Spring Boot与Spring Cloud之间的关系，同上。（使用的工具是否属于微服务，可根据引用的包名判断，是来源于cloud还是boot）
第七章 Spring Cloud
1.Spring Cloud
优势：Spring Cloud是个庞大的工具包，与Spring一脉相承。只做集成的框架，无代码侵入，使用简单。
特点：
1.功能齐全。集成了很多公司优秀的开源框架，充分考虑并满足开发者的需求。
2.标准化。使用方式的标准化：maven或gradle引入依赖，注解打开开关，简单少量配置。
3.简单方便。使用上方便。
4.按需取用。只引入需要的组件。
5.轻量。每个组件都轻量。
6.易扩展、易维护。组件易拔插。
7.可复用性。组件间的可复用性很高（？）一个服务简单修改就能成为另一个服务，不用重新开发（？）
（以上并没认真整理出实质特点，并没有将特点和由特点带来的好处进行区分。例如，使用简单应该是由组件轻量和易拔插特性造成的结果）
2.发现注册中心 Eureka
概念：分布式系统中，注册中心发现服务、注册服务，并将所有的服务进行统一管理。
说明：
-Eureka是Netflix开发的服务发现框架。
-注册中心提供服务注册功能，采用客户端发现模式。
-服务的发现有2方式：服务端发现（服务端主动发现其他服务）和客户端发现（服务注册进服务端）。
（作者认为服务端与客户端是发现与被发现的关系，注册和被注册的关系）
（个人：服务端和客户端指的是Eureka Server和Eureka Client，Client指的是否是其他微服务项目？）
（个人：客户端发现模式与作者描述的服务发现的2个方式，是两件事情）
（个人：客户端发现模式指，各个客户端，从服务端获取所有服务列表，所有的请求直接指向各个服务，而非Eureka注册中心服务）
（个人：服务只有一种方式注册到服务端，而客户端模式指的是服务调用时候的差别？）
-Eureka仪表盘功能，页面直观监控所有服务状态。
-节点服务的心跳机制，动态刷新注册中心服务列表。
-客户端缓存，即使Eureka Server障碍“挂掉”，各个服务依然能通过客户端缓存的服务节点信息，继续被调用。
3.网关 Zuul
概念：网关为前台提供一个统一的服务入口，所有后台服务的聚合，同时实现鉴权、认证、安全、路由等作用。除了Zuul还有Nginx、Node.js等实现方式。
方向代理：正向代理代理的是客户端，服务端不知道客户端是谁；反响代理代理的是服务端，客户端不知道服务端是谁。
说明：Zuul是反向代理，代理了所有后台服务，前端请求不需要知道请求的服务端是谁，只需要交给Zuul，由其进行正确的路由。
4.客户端负载均衡 Ribbon
概念：通过采取某种策略为客户端选择一个服务端，从而尽可能减少对服务端的压力。策略是核心，有轮询、随机、响应时间加权等。Ribbon从Eureka获取的服务列表，在客户端调用服务实例时候，进行负载均衡。
用法备注：协议:/Ribbon服务IP:端口/请求服务路径，多个服务配置了相同的请求服务路径，但这些完全相同的服务项目通过不同端口号启动运行，Ribbon服务通过相同的路径负载调用这些的项目。
5.断路器 Hystrix
概念：容错管理工具，通过隔离、控制服务处理局部的延迟、故障，保证系统整体正常运行。
电路熔断器模式：熔断部分反应慢或大量超时的服务，使后续请求无法访问；隔一段时间后，允许部分请求通过，若正常调用，则恢复连接。不断熔断与恢复。
回滚降级fallback：当服务被熔断后，调用实现设定好的回滚fallback方法。方法中可以是用户提示或者返回备用数据等。
6.分布式配置中心 Spring Cloud Config
概念：配置管理工具，所有配置信息放在远程服务器上，集中管理集群配置。目前支持3中存储方式：本地资源、SVN和GIT。
特性：中心化、版本控制、动态更新（无需重启）、平台独立、语言独立。
配置演变：
1.硬编码，配置信息与代码耦合在一起 →
2.xml、properties、yml等配置文件中，配置信息与应用在一处，每次修改需要重新打包发布 →
3.文件系统，依赖操作系统（个人想法：独立于项目外，如本地文件、数据库、SVN、GIT等，但当多个项目时，各个项目独自使用其开发语言，分别从不同的存储方式上读取信息） →
4.云端存储，增加一个服务用于读取所有配置信息，配置信息允许以任意方式存储
∴使用何种配置方式，视实际情况而定
7.服务间调用 Feign
概念：Spring Cloud的一个组件，通过伪装者Feign来实施服务间的调用。
用法（简单说明）：被调用的服务无任何修改；调用方添加@FeignClient在DAO接口上，接口类中再定义各个调用的服务方法（将被调用的服务视为当前服务的DAO）。 p.s.Feign内部继承了Ribbon，即带有负载均衡功能
8.服务追踪及记录 Sleuth Zipkin
Sleuth
概念：Spring Cloud实现的一种分布式追踪解决方案，追踪一个请求发起的过程中，所有被调用的服务及其调用关系、时长，便于排查问题。
说明：Sleuth包含trace ID和span ID。一个请求一个trace ID，期间被调用的服务各有其span ID。类比快递，一张订单一个trace ID，快递经各个物流站点各有其span ID。
用法：每个服务都需要引入pom依赖；在服务方法内增加语句log.inf("xxx calling xx service")；控制台将输出[服务名，trace ID，span ID]info。
Zipkin
概念：日志聚合工具Zipkin，为Google论文Dapper的开源实现，解决服务全链路调用的追踪定位问题，并可视化展示。与Sleuth共同使用，支持多种语言。
用法：本身是一个服务项目，注册进发现中心；每一个服务同Sleuth一样都需要添加Zipkin的依赖；浏览器访问Zipkin服务地址，可视化查看调用关系及时长等信息，便于查询问题与低效率服务，达到高性能的优化目的。
9.Spring Cloud和Dubbo的比较
Dubbo：是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案。阿里巴巴SOA服务化管理方案的核心框架。
说明：Dubbo的阿里团队已经解散，作者认为是种逆淘汰（坏的淘汰好的），失败原因是开发者的懒惰，选择使用方便的工具，但国内还有很多公司选择使用。
对比：
1.Spring Cloud是一套完整的框架，自带体系。Dubbo只有服务管理这一块。
2.使用上，Spring Cloud集成组件十分方便。
3.背景上，各大国际大牌高科技公司，将自家框架开源，纳入Spring Cloud中，而Dubbo势单力薄。
第八章 相关技术和工具
1.Liquibase
概念：用于跟踪、管理和应用数据库变化的开源的数据库重构工具。
特性：支持多种主流数据库；支持多种格式的存储数据库脚本；支持上下文context，对应不同环境（测试、开发、生成）；支持代码分支和合并（如SVN版本控制）；自动生成运行结果便于DBAreview；集群安全的数据库升级；两个数据库差异比较；多种运行方式（maven、ant、command line等）；提供了Eclipse等的IDE插件；等等。
2.Swagger
概念：帮助使用者设计、构建、文档化，使用RESTful服务API（即生成、显示、测试RESTful服务）。
说明：使接口可视化，浏览器可查看并调用测试所有接口；接口文档与代码同步更新；接口文档自动化管理
3.Spring Security
服务的访问权限控制，类似shiro。
4.微服务架构的通信方式
同步：实现方式有面向方法的SOAP、面向资源的Rest、面向接口的RPC等（基本都被REST取代） p.s.Dubbo使用RPC，当当开发DubboX支持REST
REST：
概念：是一种软件架构风格，是一套规范，面向资源的服务。
主要特点：每个资源都有一个ID；连接资源在一起；使用标准方法；资源多重表达；无状态通信
优势：易开发，易维护（较之RPC、AXIS、CXF等，REST轻量，无代码的侵入耦合，不依赖平台与开发语言）；直观，所见即所得（URL易懂服务含义）
请求类型：GET获取资源；PUT更新资源；DELETE删除资源；POST创建资源
支持格式：JSON和XML
异步：结合消息队列使用。优点：1.遇到异常将会跳过，延迟处理，而同步时将在异常处阻塞，better late than never；2.吞吐能力强，消息队列本身是一种缓冲机制。
消息队列产品：JMS、ActiveMQ、Apache Kafka、RabbitMQ
5.微服编排 Netflix Conductor
概念：意义不明（一堆比喻与Conductor的工具特点，不涉及概念明确定义，与Conductor的作用说明）。对所有服务进行架构设计？
6.管理工具 JIRA
介绍：被业界认为最好的敏捷团队项目管理和开发管理工具，管理需求和缺陷BUG，通过敏捷看板功能，让团队专注提供迭代和增量价值。
第九章 测试相关
1.单元测试 Junit Mockito
Mock：Mock测试是单元测试的重要方法——测试过程中，对于某些不容易构造（如HttpServletRequest）或者不容易获取的复杂中对象（如JDBC中的ResultSet），使用一个虚拟对象（Mock对象）来创建，以便进行测试的方法。Mock最大作用是单元测试的解耦。
Mockito：最好的Mock测试框架。特点：1.可以Mock任何对象；2.使用非常简单；3.验证结果更加自由；4.可以验证行为、顺序等；5.可以连续调用。
使用备注：另外学习，该书写得凌乱。注意@Mock和@InjectMocks的区别。PodamFactory自动补全实体类的数据的使用。@Before启动前setUp()的初始化代码。MocMVC模拟客户端请求。
2.接口测试 Swagger
说明：接口测试也叫契约测试。在持续集成、持续交付的过程中，接口的变化难免，如何方便地通知调用方。使用Swagger，及时更新接口文档，方便接口测试。
3.代码质量管理工具 Sonar
概念：是一个代码质量管理的开放平台。通过插件机制，可以集成不同的测试工具、代码分析工具，以及持续集成工具（如Jenkins）。
特点：
1.设置质量门槛，直观的看到工程质量是否达标。
2.能看到总体健康程度，以及专门针对从测试的覆盖率和重复2个重要指标。
3.代码规则检查工具，可检测不符合标准的代码和潜在的bug和缺陷。
4.其他：检测注释不足或过多；统计代码行数；整合DevOps；集中管理质量。
使用：下载配置并启动Sonar，安装插件，创建工程，本地项目pom.xml中引入配置，mvn启动，在Sonar的工程页面查看测试结果：质量门槛是否Passed状态、Bug数量、代码异味、单元测试数量及覆盖率、代码重复率