1、关于Hystrix中fallbackMethod方法写得太简单中，书中只提到了简单的查询异常，多表数据插入及多表数据编辑的业务场景没有涉及，不知是否有比较简单可靠的解决方案。

2、SpringCloud与历史系统的整合，若企业中打算把原来系统的核心业务逻辑层由原来的webservice或http接口架构改为使用SpringCloud框架框架，应该怎么去做才能使现在系统的展现层内容改动最小。

3、缺少使用SpringCloud大型企业的案例，哪怕国外的公司也行，目前国内看到的案例都是一些比较小的公司在使用。

4、大型企业级应用SpringCloud框架的内容涉及的比较少，比如微服务集群生产环境版本的发布，如果不使用Docker技术，微服务提供者集群各个节点的版本怎么快速发布升级新版本。

5、SpringCloud框架的性能情况没有提到。

6、没有提到SpringCloud与Dubbo的对比，序言中有说到要把Dubbo迁移到SpringCloud，但没有提到原因。

1. 微服务架构概述

1.1. 微服务架构特点

1、每个微服务可独立运行在自己的进程中。2、一系列独立运行的微服务共同构建起整个系统。3、每个服务为独立的业务开发，一个微服务只关注某个特定的功能，如订单管理、用户管理等。4、微服务之间通过一些轻量的通信机制进行通信，如RESTfulAPI进行调用。5、可以使用不同的语言与数据存储技术。6、全自动的部署机制。

1.2. 微服务设计原则

1、单一职责原则

2、服务自治原则

3、轻量级通信机制（REST、AMQP、STOMP、MQTT）

4、微服务粒度（领域驱动设计原则）

1.3. 微服务架构技术选型

支持微服务的主流架构有：SpringCloud、Dubbo、Dropwiz-ard、Armada。

1.4. 微服务架构常用组件图

与之前整理的资料类似。

2. 微服务开发框架Spring Cloud

2.1. SpringCloud简介

1、SpringCloud是在SpringBoot基础上构建的，用于快速构建分布式系统的通用模式的工具集。是一个搭建分布式系统的生态环境。后续需要重点了解一下SpringBoot。

2、SpringCloud开发的应用程序非常适合在Docker或PaaS层上部署，所以又叫云原生应用（Cloud Native Application），是面向云环境的软件架构。

3、云原生《十二要素应用宣言(12-factor Apps)》参考附录。

2.2. 特点及版本

1、特点

适合于各种环境。开发、部署在PCServer或各种云环境（例如阿里云、AWS等）。

选型中立、丰富。如可支持Eureka、Zookeepter或Consul实现服务发现。

还有其它特点之前资料已整理。

2、版本命名

Spring Cloud是一个拥有诸多子项目的大型综合项目，原则上其子项目也都维护着自己的发布版本号。那么每一个Spring Cloud的版本都会包含不同的子项目版本，为了要管理每个版本的子项目清单，避免版本名与子项目的发布号混淆，所以没有采用版本号的方式，而是通过命名的方式。这些版本名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序，比如：最早的Release版本：Angel，第二个Release版本：Brixton，以此类推……。

Angel.SR6，Brixton.SR5中的SR6、SR5就是表示BUG版本修复次数。

3、SpringCloud/SpringBoot版本兼容性

Angel版本基于SpringBoot1.2.x构建，与SpringBoot1.3.x及以上版本不太兼容。

Brixton基于SpringBoot1.3.x构建，兼容1.4.x,不兼容1.2.x。

Camden基于1.4.x构建，也可使用1.5.x进行测试。

4、JDK版本

官方建议使用1.8版本，也通过配置支持1.7版本。

5、IDE

官方提供了：SpringToolSuite3.8.X的IDE，这是基于Eclipse的IDE，也可以使用Intellij IDEA等IDE。

6、Maven

3.3.x版本默认运行在JDK1.8之上，1.8以下版本要做额外配置。

3. 服务开发及服务注册与发现

3.1. 服务提供者与服务消费者开发

3.1.1. 服务提供者

1、开发编码

编码很简单，只需要引入springboot的依赖包、springcloud的依赖包、springMVC及maven包即可。其它代码与传统springMVC架构开发流程一样。

本书详细代码可参考（下同）：http://www.itmuch.com/advertisment/my-spring-book-code/

3.1.2. 服务消费者

1、开发编码

与服务提供者开发类似。

3.2. 服务提供者运行状态监控

SpringcloudActuator提供了很多监控端口，可以使用http://IP:port/endpoint的形式访问这些端点，可以实时了解应用程序的运行状况。整合Actuator功能只需要在项目添加一个依赖即可。然后可以通过http://IP:port/health、http://IP:port/info方式监控。如果项目中整合了Hystrix断路器组件，也可监控Hystrix状态。

3.3. 服务发现Eureka

3.3.1. 架构介绍

 https://img-blog.csdn.net/20170614104413370?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvRGVscGhpYW5kbGl1/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center

1、Application Service  服务提供者。

2、Application Client 服务消费者。

3、Make Remote Call 调用RESTfulAPI的行为。

4、Us-east-1c、Us-east-1d等都在一个物理机房(zone）Eureka集群中，它们都属于us-east-1这个Region(Region可理解为跨机房的Eureka集群)

5、Eureka包含两个组件：EurekaServer与EurekaClient，采用C/S架构：

EurekaServer:提供服务发现，各个微服务启动时，会向EurekaServer注册自己的信息（IP、端口、微服务名称等），EurekaServer会存储这些信息。

EurekaClient：是一个java客户端，用于简化与EurekaServer的交互。

6、微服务启动后，会同期性的（默认30秒）地向EurekaServer发送心跳以续约自己的“租期”。

7、如果EurekaServer在一定时间没有接收到某个微服务实例的心跳，EurekaServer会注销该实例（默认90秒）。

8、默认情况下EurekaServer同时也是EurekaClient，多个EurekaServer实例，互相之间通过复制的方式，来实现服务注册表中数据的同步。

9、EurekaClient会缓存服务注册表中的信息，减少EurekaServer的压力。

3.3.2. 编写EurekaServer

添加spring-cloud-starter-eureka-server的依赖，然后在启动类添加EurekaServer注解即可。

3.3.3. 编写EurekaClient

添加spring-cloud-starter-eureka的依赖，然后在启动类添加EurekaClient注解即可。

疑问：一个EurekaServer既是S又是C，启动方法名上注解的内容不是很多？

3.3.4. EurekaServer高可用

可通过运行多个实例并互相注册的方式实现高可用部署，EurekaServer实例会彼此增量地同步信息，从而确保所有节点数据的一致性。

3.3.5. EurekaServer安全访问用户认证

在项目中引入3.3.2.编写spring-cloud-starter-security的依赖，然后在配置文件中增加用户名与密码，则客户端口在注册的时候需提供用户认证信息才可访问。

3.3.6. EurekaServer的REST端点

作用是提供给其它语言编写的EurekaClient注册到EurekaServer,为整合历史系统提供了接口。

4. 客户端负载均衡Ribbon

4.1. 介绍

Ribbon是Netflix发布的负载均衡器，有助于控制http与tcp客户端的行为，为Ribbon配置服务提供者地址列表后，它就可基于某种负载均衡算法自动地帮消费者去请求。它提供了多种常用算法，也可以自定义算法。此组件是实现服务消费者端的负载均衡。

在SpringCloud中，当Ribbon与Eureka配合使用时，Ribbon可自动从EurekaServer获取服务提供者地址列表，并基于负载均衡算法请求其中一个服务提供者实例。它也可脱离Eureka单独使用。

4.2. 实现方式

在服务消费者项目中加入spring-cloud-starter-ribbon的依赖,并在调用处RestTempLate添加@LoadBalanced注解即可。

5. 使用Feign实现声明式REST调用

5.1. 简介

Feign是Netflix开发的声明、模板化的HTTP客户端，可以帮助服务消费者便捷、优雅的调用HTTPAPI。可以支持对请求的数据压缩操作。并可以创建完整的客户端日志信息。

5.2. 使用

在服务消费者项目中加入spring-cloud-starter-feign的依赖,创建一个Feign接口，并添加@FeignClient注解即可。

6. 使用Hystrix实现容错处理

6.1. 实现容错的手段

1、雪崩效应

常把“基础服务故障”导致“级联故障”的现象称为雪崩效应，它描述的是服务提供者不可用导致消费者不可用，并将不可用逐渐放大的过程。

2、容错方法论

为网络请求设置超时、使用断路器模式

6.2. Hystrix实现容错

它是Netfilx开源的一个延迟和容错库，用于隔离访问远程系统、服务或第三方库、为防止级联失败，从而提升系统的可用性与容错性。实现机制如下：

1、包裹请求：使用HystrixCommand包裹对依赖的调用逻辑，每个命令在独立线程中执行。

2、跳闸机制：错误率超过一定阀值可自动或手动跳闸，停止请示该服务一段时间。

3、资源隔离：为每个依赖维护一个小型线程池（或者信号量），如果该线程池已满，发往该依赖的请求就被立即拒绝，是排队等待。

4、监控：可近乎实时的监控运行指标和配置的变化。

5、回退机制：当请求失败、超时、被拒绝或断路器打开时，执行回退逻辑。回退逻辑可由开人员自行提供，例如返回一个缺省值。

目前来看这种机制在调用多个服务时的开发工作量比较大。

6、自我修复：断路器打开一段时间后，会自动进入”半开“状态。

6.3. 在服务消费者项目使用Hystrix

在服务消费者项目中加入spring-cloud-starter-hystrix的依赖,在启动类上添加@EnableCircuitBreaker或@EnableHystrix注解即可。

6.4. Hystrix断路器状监控的深入理解

监控失败阀值默认为：5秒钟内20次失败，达到值后断路器才会打开。执行回退逻辑并不代表断路器已经打开，请求失败、超时、被拒绝以及断路器打开时等都会执行自定的回退逻辑。

6.5. Hystrix断路器与Feign一起使用

6.6. Hystrix的监控

它除了容错，还提供了近乎实时的监控，HystrixCommand和HystrixOberverableCommand在执行地，会生成执行结果和运行指标，比如每秒执行的请求数、成功数等。同时还可以支持可视化监控数据。

6.7. 使用Turbin聚合监控多个微服务数据

7. 微服务跟踪Sleuth

7.1. Sleuth介绍

1、springcloudSleuth为SpringCloud提供了分布式跟踪的解决方案，大量借用了Google Dapper、Twitter Zipkin和Apache HTrace的设计。能够跟踪每个请求，了解请求经过哪些微服务、请求耗时时间、网络延迟、业务逻辑耗费时间等指标，有助于分析系统瓶颈、解决系统问题。

2、Sleuth术语

Span(跨度)：基本工作单元。用一个64位的ID唯一标识，span被启动或停止时，记录了时间信息。初始化span为称为“root span”,该span的id与trace的ID相等。

Trace(跟踪)：一组共享”root span”的span组成的树状结构称为”trace”，tarce也用一个64位的ID唯一标识。

Annotation(标注)：用来记录事件的存在，其中核心annotation用来定义请求的开始与结束，包括：

CS（客户端发送）:客户端发起一个请求，描述了span的开始。

SR（服务器接收端）:服务器端获得请求并准备处理它，如果用SR减去CS时间戳，就能得到网络延迟。

SS（服务器端发送）：表明完成请求处理（当响应发回客户端时），如果用SS减去SR时间戳，就能得到服务端处理请求所需时间。

CR（客户端接收）：span结束的标识，客户端成功接收到服务器端的响应，如果CR减去CS时间戳，就能得到从客户端发送请求到服务器响应的所需时间。

7.2. Sleuth使用

添加spring-cloud-starter-sleuth的依赖，然后在配置文件中增加日志显示的级别即可。

7.3. Sleuth与ELK配合使用

7.4. Sleuth与Zipkin配合使用

Zipkin提供一个非常友好的界面来帮助分析追踪数据。

1、编写ZipkinServer

2、微服务整合Zipkin

8. 微服务配置信息统一管理

可支持：configserver可以统一管理微服务的配置、配置内容的加解密、自动或手动刷新配置信息、与Eureka配合一起使用、用户认证、集群高可用等 。详细内容待补充。

9. 微服务网关Zuul

可支持服务安全、文件上传、容错与回退、自定义过滤器、聚合微服务、集群高可用、使用

Sidecar整合非JVM微服务等。详细内容待补充。

10. Springcloud常用问题

1、Eureka注册服务慢，因为心跳时间默认为30秒。

2、已停止的微服务节点注销慢或不注销，清理同期为90秒，

3、微服务的IntanceID可以通过配置文件自定义。

4、Hystrix/Feign整合Hystrix后首次请求失败原因：Hystrix默认超时时间1秒，如果1秒内得不到响应，就会进入fallback逻辑，由于Spring的懒加载机制，首次请求比较慢，可以修改默认时间来解决。

11. Springcloud与Docker

可支持：将微服务运行在docker上、使用DockerCompose编排微服务（编排Springcloud微服务、编排高可用的EurekaServer、编排高可用SpringCloud微服务集群及动态伸缩）等。详细内容待补充。