SpringCloud（多种框架组件技术集合的总框架）笔记

微服务

微服务的由来

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

为什么需要微服务

在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太 高，新系统稳定性的收敛也需要一些时间。

微服务与单体架构区别

• （1）单体架构所有的模块全都耦合在一块，代码量大，维护困难。 微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
• （2）单体架构所有的模块都共用一个数据库，存储方式比较单一。 微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单 个模块对应自己的数据库。
• （3）单体架构所有的模块开发所使用的技术一样。 微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

微服务本质

多个微服务可以部署在不同的服务器上，由nginx转发请求对应的服务器运行。

（1）微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等微服务还可以使用远程数据库（阿里云）
多个微服务可以部署在不同服务器，nginx进行请求转发 甚至可以拆开分别开发微服务 等。
（2）微服务的目的是有效的拆分应用，实现敏捷开发和部署 。 （3）微服务提倡的理念团队间应该是 inter-operate, not
integrate 。inter-operate是定义好系统的边界
和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本
维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

什么样的项目适合微服务

微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。

微服务开发框架

目前微服务的开发框架，最常用的有以下四个：
Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）
Dubbo：http：//dubbo.io
Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）
Consul、etcd&etc.（微服务的模块）

Spring Cloud简介

SpringCloud
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

SpringCloud是基于整合多种组件技术的总称，是很多框架组件的集合。

Spring Cloud和Spring Boot是什么关系

• Spring Boot 是 Spring 的一套快速配置脚手架，可以基于 Spring Boot 快速开发单个微服务， Spring Cloud 是一个基于 Spring Boot 实现的开发工具；
• Spring Boot 专注于快速、方便集成的单个微服务个体，Spring Cloud 关注全局的服务治理框架；
• Spring Boot 使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，SpringCloud很大的一部分是基于 Spring
  Boot来实现，必须基于Spring Boot开发。
• 可以单独使用Spring Boot开发项目，但是Spring Cloud离不开 Spring Boot。

因此Spring Cloud版本需要根据使用的Spring Boot版本进行选择。

Spring Cloud 小版本分为 :

• SNAPSHOT ： 快照版本，随时可能修改
• M ： MileStone ， M1 表示第 1 个里程碑版本，一般同时标注 PRE ，表示预览版版。
• SR ： Service Release ， SR1 表示第 1 个正式版本，一般同时标注 GA ： (GenerallyAvailable), 表示稳定版本。

Spring Cloud相关基础服务组件（需要匹配SpringBoot框架版本）

以下基础服务组件整合到一起的框架总称为SpringCloud

• 服务发现——Netflix Eureka （Nacos）
• 服务调用——Netflix Feign
• 熔断器 ——Netflix Hystrix
• 服务网关 ——Spring Cloud GateWay
• 分布式配置——Spring Cloud Config （Nacos）
• 消息总线 —— Spring Cloud Bus （Nacos）

Httpclient主要用户程序方法与程序方法之间的相互请求（模拟浏览器对相应程序方法的请求）

Nacos（微服务注册中心–消息中间件）

实现微服务之间的实例方法的调用。
软件开发需要遵循高内聚，低耦合标准
Nacos可以使微服务项目之间无需通过maven导入便可以使用微服务中的功能，maven导入微服务项目导致微服务项目之间耦合才能调用不同的微服务项目方法

Nacos 是阿里巴巴推出来的一个新开源项目，是一个更易于构建云原生应用的动态服务发现、配置 管理和服务管理平台。Nacos致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos 帮助您更敏捷和容易 地构建、交付和管理微服务平台。 Nacos是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原 生范式) 的服务基础设施。

配置步骤

就是让各个服务知道对方的存在，然后要用的时候用某种办法联系起来
Nacos下载地址
localhost 、 127.0.0.1 、0.0.0.0 、本地IP的区别
IP：定位服务器位置
端口号：定位程序在服务器运行位置
Nacos注册的服务名和微服务端口号相对应，可以通过服务名得到根路径端口号（http://localhost:端口号）从而实现Feign的调用转发

Feign（微服务调用）

• Feign是Netflix开发的声明式、模板化的HTTP客户端， Feign可以帮助我们更快捷、优雅地调用HTTP API。
• Feign支持多种注解，例如Feign自带的注解或者JAX-RS注解等。
• Spring Cloud对Feign进行了增强，使Feign支持了Spring MVC注解，并整合了Ribbon和Eureka，从而让Feign的使用更加方便。
• Spring Cloud Feign是基于Netflix feign实现，整合了Spring Cloud Ribbon和SpringCloud Hystrix，除了提供这两者的强大功能外，还提供了一种声明式的Web服务客户端定义的方式。
• Spring Cloud Feign帮助我们定义和实现依赖服务接口的定义。在Spring Cloud feign的实现下，只需要创建一个接口并用注解方式配置它，即可完成服务提供方的接口绑定，简化了在使用SpringCloudRibbon时自行封装服务调用客户端的开发量。

微服务间C层方法交互实现原理

Nacos注册绑定微服务名和端口号，Feign和Gateway网关基于微服务名识别拼凑微服务端口号

• 在application.properties中配置Nacos后，就可以根据服务名匹配对应微服务的访问端口号
• 然后通过Nacos注册的服务名对应的根路径端口号（http://localhost:端口号）还有Client方法的相对路径得到被调用端微服务Controller方法的绝对访问路径。
• 最终调用端就可以进行模拟浏览器调用（HttpClient）触发被调用微服务Controller方法实现功能了

注意

配置的URL路径需要和前端请求总服务路径一致，以便httpclient模拟浏览器调用端触发调用对应controller服务。
传参时注解的参数名以及参数变量名需要和调用端参数名一致
开发时可以直接将对应controller方法头cv过来然后修改合并为C层绝对URL并且添加@注解的参数名

下图是接口注入的具体信息。

Feign.FeignException$NotFound: status 404 reading 错误原因分析

• Client的方法URL和Controller层不一致
• 参数名未用注解指定@PathVariable(“参数名”)
• 传参时，String为空字符串（str=“”）
  
  Feign传参为空串时导致的Feign调用错误
  结论：new String();创建的对象并不为空，系统是分配了内存空间的，只是它没有赋值；String str=“”;str也不为空，只是赋值为空的字符串；String str=null;str为空，没有内存空间，什么也没有，不能调用它的属性，会有异常抛出

注意

Feign：被调用端Controller方法return Map/String等等基本数据类型则服务调用端和被调用端双方都有，若是return 自定义的Object，则同样需要双方都有对应自定义的Object类型，
可以在common模块引入Object类型则就可以实现双方都有对应的Object类型了。

注意

Feign调用端微服务启动时若是没启动被调用端微服务则运行到调用方法时报错。

Hystrix（熔断器–远程微服务的异常处理兜底方法）

Hystrix 是一个供分布式系统使用，提供延迟和容错功能，保证复杂的分布系统在面临不可避免的失败时，仍能有其弹性。
比如系统中有很多服务，当某些服务不稳定的时候，使用这些服务的用户线程将会阻塞，如果没有隔离机制，系统随时就有可能会挂掉，从而带来很大的风险。SpringCloud使用Hystrix组件提供断路器、资源隔离与自我修复功能。下图表示服务B触发了断路器，阻止了级联失败

微服务出现异常后兜底的方法
这就是Ribbon负载啊，部署一个服务到多个服务器，形成集群，然后就算一个宕机，也不影响这个服务运行

@PathVariable注解一定要指定参数名称，否则出错

Gateway网关

Gateway网关

Spring Cloud Config /Nacos—（统一微服务配置）

网课配置链接
将同一功能的微服务在Nacos统一配置中心文件
这样同一功能的微服务都能实现同步配置（修改数据库时只需要修改配置中心文件即可）

总结

• SpringCloud是整合多种组件功能的总称。（实现微服务低耦合的相互调用）
• 微服务相互调用实质：基于httpclient（URL）实现不同微服务之间controller方法的调用并处理。
• API接口的调用思想也是微服务思想的利用。
• 编写顺序：Nacos（微服务注册）-》Feign（微服务调用端）-》 Hystrix（熔断器兜底）
• nacos注册：服务端和调用端启动类@EnableDiscoveryClient和application配置文件-》Feign服务调用：调用端启动类@EnableFeignClients并配置接口方法-》Controller层Autowire实例化client进行调用微服务方法。
• 注意默认还要配置熔断器否则报错
• 实质上SpringCloud进行微服务的注册和调用实现的是服务器的负载均衡
  • 因为调用端微服务仍然是通过（HttpClient）URL触发对应微服务的服务器，不同微服务服务器实现不同功能 ，反观若是采用maven导入不仅会造成高耦合还会导致某单一服务器实现多种微服务任务量过重。

最终微服务架构的实现是通过让不同微服务模块运行在本地不同端口从而模拟微服务的不同地址再通过SpringCloud实现微服务注册以及微服务间调用，请求转发，负载均衡。

Nacos注册绑定微服务名和端口号，Feign和Gateway网关基于服务名识别拼凑微服务端口号
最终目的：拼凑出对应微服务Controller层方法的绝对访问路径(http://localhost:端口号/****) 才能通过HttpClient实现最终转发调用交互等功能