@[toc]

前言

本篇博客是SpringCloud的学习笔记，主要介绍SpringCloud中的基础组件，若文章中出现相关问题，请指出！

所有博客文件目录索引：博客目录索引(持续更新)

一、微服务基础

微服务拆分，从单体架构开始演变；微服务扩展。

微服务重要模块：

服务化：把传统的单体应用中的本地方法调用，改造成通过RPC、HTTP产生的远程方法调用。

---

1.1、微服务两大门派

核心组件对比

微服务两大门派：SpringCloud与Dubbo

• SpringCloud：众多子项目，包含许多成熟的框架。
• Dubbo：高性能、轻量级的开源Java RPC框架，提供了三大核心能力，面向接口的远程方法调用，智能容错和负载均衡以及服务自动注册与发现。(Dubbo提供的能力只是SpringCloud的一部分子集)

• 虽然说其中的一些核心组件Dubbo并没有提供，但是其可以整合其他第三方的优秀开源组件。
• 分布式配置：百度(disconf)、淘宝(diamond)
• 服务跟踪：京东开源(Hydra)
• 批量任务：当当开源(Elastic-Job)

通信协议

RPC vs REST(http)

• RPC：整体效率比较高，传输同样的内容体量更小，传输更快。缺点：①服务提供方与调用方接口依赖方式太强，并不是通用的协议，要想调用需要找到对应的依赖，代码级别有强依赖。②对平台敏感，难以简单复用。
  • 体量较大
• REST：不存在代码级别的强依赖，可能定义的内容与实际提供的接口有不一致的情况。
  • 提供了中文、英文文档。文档详细。

选型：

1. RPC的话是原本阿里开发出来的组件，并没有提供一些对应的其他组件所以增加了我们要整合第三方组件的难度。
2. SpingCloud(Spring的产品)是专注于微服务领域框架，从发展到现在仍然在高速迭代，几乎考虑到了服务治理的方方面面，开发起来比较简单遍历。(更胜一筹)

两者都是十分有效的工具，根据实际业务以及组内技术栈来进行选择。

---

1.2、服务化拆分

第一阶段：主要目标是快速开发和验证想法。(将项目的各个模块进行开发打包在一起集成开发测试与运维，这是最高效节省成本的方式)

• 如开发社交APP，可以只开发聊天、信息流功能与评论功能。如果产品用户喜欢我们可基于原本上面增加新的功能并进行开发来吸引更多用户。

第二阶段：一旦团队开发人员超过10人，就需要考虑服务化拆分了。每个工程师开发的服务不能超过三个，精力有限。

• 不适合拆分情况：①小团队，技术基础较薄弱。应该用团队比较熟悉的技术栈，同时逐渐招聘有经验的工程师再去考虑服务化与拆分。②流量不高，压力小，业务变化也不大。(如管理系统，管理请假、年度目标、绩效、发工资等等功能，由于是企业内部流量是不高的，不需要对性能做过多的优化，一般对于这类项目单体就能搞定)。③对于延迟很敏感的低延迟高并发系统。(因为微服务会比单体的时延要高，具有网络延迟损耗，需要去考虑)
• 拆分情况：①纵向拆分(根据业务去拆分，如关联比较紧的，功能比较独立的，个人主页)。②横向拆分，主要是按照公共领域拆分，如将用户服务拆分成横向出来，将这个功能提供给各个模块(能够达到大量复用)。

微服务重要模块：服务描述、注册中心、服务框架、负载均衡、熔断与降级、网关。

---

二、Demo项目使用到组件梳理

Eureka(server注册中心，client进行连接注册)

基本知识

此时又两个服务：①提供课程类型接口。②提供课程价格接口。

Eureka：服务注册与发现。用于定位服务，只需要使用服务访问的标识符就能够访问到该服务了。其他服务使用client即可连接到Eureka的server端。

• 例子：如114、物业，起到中间人的作用。在一定时间内发送一个心跳表示当前状态是活跃的。

服务提供者：启动的时候把自己注册到Eureka上，其还需要进行续约，通过发射心跳，还要负责服务下线，需要进行通知Eureka Server。

服务消费者：获取服务，通过请求找到服务注册中心Eureka，把服务清单获取到，根据清单找到信息接着进行调用。

Eurake Server：服务中心，其职责就是维护花名册，具有失效剔除的功能。每个一段时间（大约60s）没有来续约就会将其剔除出去

实现

需要专门一个springboot服务作为一个Eurake Server来作为注册中心，其会暴露出自己制定的注册中心地址，通过配置文件中配置。

接下来我们将对应提供服务的springboot项目改造为指定Eurake Client，同样引入依赖，配置指定的注册中心，其表示的客户端去将自己的服务注册到Eurake Server上去！

---

Feign(远程服务调用)

声明式、模板式的HTTP客户端，调用远程服务的请求，基于接口与注解的方式实现的。

集成Feign：

1. 添加依赖、添加Feign client注解
2. 编写client，接口形式，添加指定远程调用的方法要一致。在该接口上添加@FeignClient，表明其是一个Feign客户端。注解中的内容则是对应的服务名。
3. 使用：同样是编写一个控制器，通过依赖注入的形式拿到client的代理类，接着就像是调用本地的方法一样进行调用远程其他服务的接口。

---

Ribbon(负载均衡)

负载均衡类型

客户端负载均衡(Ribbon)：用在服务内部的。在调用的时候，若是有多个节点都能够提供服务，由指定调用的人来决定调用哪个服务，其不会让某个节点压力很大。

服务端负载均衡(Nginx)：所有的请求先达到nginx，由它来进行请求的分发与转发。

策略

RandomRule：表示随机策略。

RoundRobinRule：表示轮询策略。能够平衡各个节点的压力。

ResponseTimeWeightedRule：加权，根据每一个Server的平均响应时间动态加权。

---

Hystix(断路器)

进行远程调用的时候，某个服务出现了延迟，由于我们可能是远程调用的多个服务，一旦最先调用的服务出现了延迟情况，那么后面的服务将会无法调用。

功能：当某一个单元发生故障的时候，可以利用断路器将其隔离出去，类似于电路，快速优雅的构建一个断路的功能。

当某一个服务发生问题的时候，会返回一个默认的响应(一个默认的错误响应)，而不会让用户进行长时间的等待，这样也不会让线程因为调用故障的缘故而导致占用的资源不释放，避免了在分布式系统中问题的蔓延。失败是不可避免的，无论是谁都不能做到百分之百的可用。

功能实现：

1. 添加断路器依赖。添加断路器打开配置手动开启。
2. 为启动类添加注解：@EnableCircuitBreaker。
3. 在之前Feign指定的client接口的注解中添加一个配置项，为fallback=xxx.class，该class类需要我们进行自己定义
   • xxx.class类需要实现client接口并重写方法，该方法中的内容则是我们在进行断路时要返回的内容可以由我们自己来进行定义。

如何测试？将指定调用远程的服务关闭即可测试出效果！

---

网关(Zuul)

基础知识

为什么需要网关？

• 若是没有网关，就会出现签名校验、登陆校验冗余问题。通过SpringCloud Zuul来进行解决网关的问题。

其会与Eurake进行组合，也是Eurake的一个client会自动进行注册到Eurake上去。也会由此通过Eurake获取其他服务的信息。有了信息之后网关会自动将这些信息进行注册，也就是说会把访问进行收口。

例如你的一个服务在8081，另一个服务在8082，而你的网关在8083，此时你调用一个服务的功能不需要去管指定的端口，而是直接请求8083，网关会帮你进行正确的转发。在Zuul中会对一系列信息进行校验，校验都通过才能够向后进行访问。

最主要作用：API网关会允许您将API请求(内部或外部)路由到正确的位置。

最重要两个功能：统一鉴权、正确路由。

集成

Zuul是一个独立的模块，需要新建一个服务，同样也作为一个client

1、首先将自己注册到Eureake注册中心

2、引入依赖

3、配置路由地址

功能实现：

1. 实现路由功能。
   • 仅仅只是调用的端口不同而已(指向网关)，后面的主机名还是以前对应的服务，即可实现通过Zuul来进行统一鉴权转发。并且我们可以通过配置文件来对指定的服务模块名称进行统一管理。
2. 实现过滤器。

过滤器说明：

1. pre过滤器在路由请求之前运行。
2. route过滤器可以处理请求的实际路由。
3. post路由请求后运行过滤器。
4. error如果在处理请求的过程中发生错误，则过滤器将运行。

过滤器实现：

1. 实现ZuulFilter抽象类，包含四个方法：类型(上面提到的四种)、顺序、是否启用以及核心处理方法。