SpringCloud组件相关

时间 2019-11-16

标签 springcloud 组件相关繁體版

原文原文链接

1、前言

原文地址：https://mp.weixin.qq.com/s/mwn2X0G9UgUDz1sgGgL1mAhtml

认识个人朋友可能都知道我这阵子去实习啦，去的公司说是用SpringCloud(但我以为使用的力度并不大啊~~)…前端

因此，这篇主要来说讲SpringCloud的一些基础的知识。(我就是现学现卖了，主要当作我学习SpringCloud的笔记吧！)固然了，个人水平是有限的，可能会有一些理解错的的概念/知识点，还请你们不吝在评论区指正啊~~java

SpringCloud GitHub Demo(看完文章的同窗能够本身练手玩玩)：nginx

https://github.com/ZhongFuCheng3y/msc-Demogit

项目结构图：程序员

2、集群/分布式/微服务/SOA是什么？

像我这种技术小白，看到这些词(集群/分布式/微服务/SOA)的时候，感受就是高不可攀的(高大尚的技术！！)。就好像刚学Java面向对象的时候，在论坛上翻阅资料的时候，无心看到"面向切面编程"，也认为这是高不可攀的(高大尚的技术！！)。github

但真正接触到"面向切面编程"的时候，发现原来就是如此啊，也没什么大不了的。只不过当时被它的名字给唬住了…算法

不知道各位在刚接触这些名字集群/分布式/微服务/SOA的时候，有没有被唬住了呢？？spring

下面我就简单说说这些名词的意思编程

2.1什么是集群

如下内容来源维基百科：

计算机集群简称集群是一种计算机系统，它经过一组松散集成的计算机软件和/或硬件链接起来高度紧密地协做完成计算工做。在某种意义上，他们能够被看做是一台计算机。集群系统中的单个计算机一般称为节点，一般经过局域网链接，但也有其它的可能链接方式。集群计算机一般用来改进单个计算机的计算速度和/或可靠性。通常状况下集群计算机比单个计算机，好比工做站或超级计算机性能价格比要高得多

集群技术特色：

经过多台计算机完成同一个工做，达到更高的效率。
两机或多机内容、工做过程等彻底同样。若是一台死机，另外一台能够起做用。

在维基百科上说得也挺明白的了，我来举个例子吧。

小周在公司写Java程序，但公司业务在发展，一个Java开发者可能忙不过来，小周有的时候也得请个假呀。因而请了3y过去一块儿作Java开发。平时小周和3y就写Java程序，但3y可能有事要回学校一趟。没事，公司还有小周作Java开发呢，公司开发还能继续运做。

3y跟小周都是作Java开发。
3y来了，小周的工做能够分担一些。
3y请假了，还有小周在呢。

我写了一个910便利网发布到服务器去了，如今愈来愈多的人访问了，访问有点慢，怎么办？？？很简单，(只有充钱才能变强)，加配置吧(加cpu，加内存)。升级完配置以后，访问人数愈来愈多，因而发现又不由用啦，在这台机器上加配置已经解决不了了，怎么办？？？很简单，(只有充钱才能变强)，我再买一台服务器，将910便利网也发布到新买的这台服务器上去。

特色：

这两台服务器都是运行同一个系统--->910便利网

好处：

原本只有一台机器处理访问，如今有两台机器处理访问了，分担了压力。
若是其中一台忘记缴费了，暂时用不了了。不要紧，还有另外一台能够用呢。

集群：同一个业务，部署在多个服务器上(不一样的服务器运行一样的代码，干同一件事)

2.2什么是分布式

如下内容来源维基百科：

分布式系统是一组计算机，经过网络相互链接传递消息与通讯后并协调它们的行为而造成的系统。组件之间彼此进行交互以实现一个共同的目标。

我也来举个例子来讲明一下吧：

如今公司有小周和3y一块儿作Java开发，作Java开发通常jQuery，AJAX都能写一点，因此这些活都由咱们来干。但是呢，3y对前端不是很熟，有的时候调试半天都调不出来。老板认为3y是真的菜！因而让小周专门来处理前端的事情。这样3y就高兴了，能够专心写本身的Java，前端就专门交由小周负责了。因而，小周和3y就变成了协做开发。

3y对前端不熟(能写出来)，但在调试的时候可能会花费不少时间
小周来专门作前端的事，3y能够专心写本身的Java程序了。
都是为了项目正常运行以及迭代。

个人910便利网已经部署到两台服务器去了，可是愈来愈多的人去访问。如今也逐渐承受不住啦。那如今怎么办啊？？那继续充钱变强？？做为一个理智的我，确定得想一想是哪里有问题。如今910便利网的模块有好几个，全都丢在同一个Tomcat里边。

其实有些模块的访问是很低的(好比后台管理)，那我可不能够这样作：将每一个模块抽取独立出来，访问量大的模块用好的服务器装着，没啥人访问的模块用差的服务器装着。这样的好处是：1、资源合理利用了(没人访问的模块用性能差的服务器，访问量大的模块单独提高性能就行了)。2、耦合度下降了：每一个模块独立出来，各干各的事(专业的人作专业的事)，便于扩展

特色：

将910便利网的功能拆分，模块之间独立，在使用的时候再将这些独立的模块组合起来就是一个系统了。

好处：

模块之间独立，各作各的事，便于扩展，复用性高
高吞吐量。某个任务须要一个机器运行10个小时，将该任务用10台机器的分布式跑(将这个任务拆分红10个小任务)，可能2个小时就跑完了

分布式：一个业务分拆多个子业务，部署在不一样的服务器上(不一样的服务器，运行不一样的代码，为了同一个目的)

2.3集群/分布式

集群和分布式并不冲突，能够有分布式集群

如今3y的公司规模变大了，有5个小伙子写Java，4个小伙子写前端，2个小伙子作测试，1个小伙子作DBA。

Java，前端，测试，DBA的关系看做是分布式的
5个Java看做是集群的(前端，测试同理)…

2.4分布式/微服务/SOA

其实我认为分布式/微服务/SOA这三个概念是差很少的，了解了其中的一个，而后将本身的理解往上面套就行了。不必细分每一个的具体概念~~(固然了，我很期待有大佬能够在评论区留言说下本身的见解哈)

参考资料：

分布式与集群的区别是什么？https://www.zhihu.com/question/20004877
分布式、集群、微服务、SOA 之间的区别https://blog.csdn.net/heatdeath/article/details/79038795

3、CAP理论

从上面所讲的分布式概念咱们已经知道，分布式简单理解就是：一个业务分拆多个子业务，部署在不一样的服务器上

通常来讲，一个子业务咱们称为节点。

若是你接触过一些分布式的基础概念，那确定会听过CAP这个理论。就好比说：你学了MySQL的InnoDB存储引擎相关知识，你确定听过ACID！

首先，咱们来看一下CAP分别表明的是什么意思：

C：数据一致性(consistency)

全部节点拥有数据的最新版本

A：可用性(availability)

数据具有高可用性

P：分区容错性(partition-tolerance)

容忍网络出现分区，分区之间网络不可达。

下面有三个节点(它们是集群的)，此时三个节点都可以相互通讯：

因为咱们的系统是分布式的，节点之间的通讯是经过网络来进行的。只要是分布式系统，那颇有可能会出现一种状况：由于一些故障，使得有些节点之间不连通了，整个网络就分红了几块区域。

数据就散布在了这些不连通的区域中，这就叫分区

如今出现了网络分区后，此时有一个请求过来了，想要注册一个帐户。

此时咱们节点一和节点三是不可通讯的，这就有了抉择：

若是容许当前用户注册一个帐户，此时注册的记录数据只会在节点一和节点二或者节点二和节点三同步，由于节点一和节点三的记录不能同步的。

这种状况其实就是选择了可用性(availability)，抛弃了数据一致性(consistency)

若是不容许当前用户注册一个帐户(就是要等到节点一和节点三恢复通讯)。节点一和节点三一旦恢复通讯，咱们就能够保证节点拥有的数据是最新版本。

这种状况其实就是抛弃了可用性(availability)，选择了数据一致性(consistency)

3.1再次梳理一下CAP理论

通常咱们说的分布式系统，P：分区容错性(partition-tolerance)这个是必需的，这是客观存在的。

CAP是没法彻底兼顾的，从上面的例子也能够看出，咱们能够选AP，也能够选CP。可是，要注意的是：不是说选了AP，C就彻底抛弃了。不是说选了CP，A就彻底抛弃了！

在CAP理论中，C所表示的一致性是强一致性(每一个节点的数据都是最新版本)，其实一致性还有其余级别的：

弱一致性：弱一致性是相对于强一致性而言，它不保证总能获得最新的值；
最终一致性(eventual consistency)：放宽对时间的要求，在被调完成操做响应后的某个时间点，被调多个节点的数据最终达成一致

可用性的值域能够定义成0到100%的连续区间。

因此，CAP理论定义的实际上是在容忍网络分区的条件下，“强一致性”和“极致可用性”没法同时达到。

参考资料：

CAP理论中的P究竟是个什么意思？https://www.zhihu.com/question/54105974
浅谈分布式系统的基本问题：可用性与一致性：https://m.aliyun.com/yunqi/articles/2709
分布式系统的CAP理论：http://www.hollischuang.com/archives/666
为何CAP理论在舍弃P的状况下，能够有完美的CA？https://www.zhihu.com/question/285878189
不懂点CAP理论，你好意思说你是作分布式的吗？http://www.yunweipai.com/archives/8432.html

扩展阅读：

浅谈分布式事务：https://m.aliyun.com/yunqi/articles/230242

4、SpringCloud就是这么简单

相信你们读到这里，对分布式/微服务已经有必定的了解了，其实单从概念来讲，是很是容易理解的。只是极可能被它的名字给唬住了。

下面我就来说讲SpringCloud最基础的知识~

4.1为何须要SpringCloud？

前面也讲了，从分布式/微服务的角度而言：就是把咱们一大的项目，分解成多个小的模块。这些小的模块组合起来，完成功能。

举个可能不太恰当的例子(现实可能不会这么拆分，但意思到位就行了)：

拆分出多个模块之后，就会出现各类各样的问题，而SpringCloud提供了一整套的解决方案！

注：这些模块是独立成一个子系统的(不一样主机)。

SpringCloud的基础功能：

服务治理： Spring Cloud Eureka
客户端负载均衡： Spring Cloud Ribbon
服务容错保护： Spring Cloud Hystrix
声明式服务调用： Spring Cloud Feign
API网关服务：Spring Cloud Zuul
分布式配置中心： Spring Cloud Config

SpringCloud的高级功能(本文不讲)：

消息总线： Spring Cloud Bus
消息驱动的微服务： Spring Cloud Stream
分布式服务跟踪： Spring Cloud Sleuth

5、引出Eureka

那会出现什么问题呢？？首当其冲的就是子系统之间的通信问题。子系统与子系统之间不是在同一个环境下，那就须要远程调用。远程调用可能就会想到httpClient，WebService等等这些技术来实现。

既然是远程调用，就必须知道ip地址，咱们可能有如下的场景。

功能实现一：A服务须要调用B服务

在A服务的代码里面调用B服务，显式经过IP地址调用：`http://123.123.123.123:8888/java3y/3`

功能实现二：A服务调用B服务，B服务调用C服务，C服务调用D服务

在A服务的代码里面调用B服务，显式经过IP地址调用：`http://123.123.123.123:8888/java3y/3`，(一样地)B->C，C->D

功能实现三：D服务调用B服务，B服务调用C服务

在D服务的代码里面调用B服务，显式经过IP地址调用：`http://123.123.123.123:8888/java3y/3`，(一样地)B->C

…..等等等等

万一，咱们B服务的IP地址变了，想一想会出现什么问题：A服务,D服务(等等)须要手动更新B服务的地址

在服务多的状况下，手动来维护这些静态配置就是噩梦！

为了解决微服务架构中的服务实例维护问题(ip地址)，产生了大量的服务治理框架和产品。这些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化管理。

在SpringCloud中咱们的服务治理框架通常使用的就是Eureka。

咱们的问题：

如今有A、B、C、D四个服务，它们之间会互相调用(并且IP地址极可能会发生变化)，一旦某个服务的IP地址变了，那服务中的代码要跟着变，手动维护这些静态配置(IP)很是麻烦！

Eureka是这样解决上面所说的状况的：

建立一个E服务，将A、B、C、D四个服务的信息都注册到E服务上，E服务维护这些已经注册进来的信息

A、B、C、D四个服务均可以拿到Eureka(服务E)那份注册清单。A、B、C、D四个服务互相调用再也不经过具体的IP地址，而是经过服务名来调用！

拿到注册清单--->注册清单上有服务名--->天然就可以拿到服务具体的位置了(IP)。
其实简单来讲就是：代码中经过服务名找到对应的IP地址(IP地址会变，但服务名通常不会变)

5.1Eureka细节

Eureka专门用于给其余服务注册的称为Eureka Server(服务注册中心)，其他注册到Eureka Server的服务称为Eureka Client。

在Eureka Server通常咱们会这样配置：

    register-with-eureka: false     #false表示不向注册中心注册本身。
    fetch-registry: false     #false表示本身端就是注册中心，个人职责就是维护服务实例，并不须要去检索服务

Eureka Client分为服务提供者和服务消费者。

但极可能，某服务既是服务提供者又是服务消费者。

若是在网上看到SpringCloud的某个服务配置没有"注册"到Eureka-Server也不用过于惊讶(可是它是能够获取Eureka服务清单的)

极可能只是做者把该服务认做为单纯的服务消费者，单纯的服务消费者无需对外提供服务，也就无须注册到Eureka中了

eureka:
  client:
    register-with-eureka: false  # 当前微服务不注册到eureka中(消费端)
    service-url: 
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

下面是Eureka的治理机制：

服务提供者

服务注册：启动的时候会经过发送REST请求的方式将本身注册到Eureka Server上，同时带上了自身服务的一些元数据信息。
服务续约：在注册完服务以后，服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活着 ” 、
服务下线：当服务实例进行正常的关闭操做时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心：“我要下线了 ”。

服务消费者

获取服务：当咱们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单
服务调用：服务消费者在获取服务清单后，经过服务名能够得到具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方。

Eureka Server(服务注册中心)：

失效剔除：默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
自我保护：。EurekaServer 在运行期间，会统计心跳失败的比例在15分钟以内是否低于85%(一般因为网络不稳定致使)。 Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过时，尽量保护这些注册信息。

最后，咱们就有了这张图：

举个例子：

3y跟女友去东站的东方宝泰逛街，但不知道东方宝泰有什么好玩的。因而就去物业搜了一下东方宝泰商户清单，发现一楼有优衣库，二楼有星巴克，三楼有麦当劳。
在优衣库旁边，有新开张的KFC，在墙壁打上了很大的标识“欢迎KFC入驻东方宝泰”。
商家们须要定时交物业费给物业。
物业维持东方宝泰的稳定性。若是某个商家不想在东方宝泰运营了，告诉了物业。物业天然就会将其在东方宝泰商户清单去除。

优秀博文：

Spring Cloud Eureka详解：https://blog.csdn.net/sunhuiliang85/article/details/76222517
《Spring Cloud Netflix》 -- 服务注册和服务发现-Eureka 的使用：https://zhuanlan.zhihu.com/p/26472547
微服务架构：Eureka参数配置项详解：https://www.cnblogs.com/fangfuhai/p/7070325.html

6、引出RestTemplate和Ribbon

经过Eureka服务治理框架，咱们能够经过服务名来获取具体的服务实例的位置了(IP)。通常在使用SpringCloud的时候不须要本身手动建立HttpClient来进行远程调用。

可使用Spring封装好的RestTemplate工具类，使用起来很简单：

// 传统的方式，直接显示写死IP是很差的！
//private static final String REST_URL_PREFIX = "http://localhost:8001";

// 服务实例名
private static final String REST_URL_PREFIX = "http://MICROSERVICECLOUD-DEPT";

/**
 * 使用 使用restTemplate访问restful接口很是的简单粗暴无脑。 (url, requestMap,
 * ResponseBean.class)这三个参数分别表明 REST请求地址、请求参数、HTTP响应转换被转换成的对象类型。
*/
@Autowired
private RestTemplate restTemplate;

@RequestMapping(value = "/consumer/dept/add")
public boolean add(Dept dept) {
    return restTemplate.postForObject(REST_URL_PREFIX + "/dept/add", dept, Boolean.class);
}

为了实现服务的高可用，咱们能够将服务提供者集群。好比说，如今一个秒杀系统设计出来了，准备上线了。在11月11号时为了可以支持高并发，咱们开多台机器来支持并发量。

如今想要这三个秒杀系统合理摊分用户的请求(专业来讲就是负载均衡)，可能你会想到nginx。

其实SpringCloud也支持的负载均衡功能，只不过它是客户端的负载均衡，这个功能实现就是Ribbon！

负载均衡又区分了两种类型：

客户端负载均衡(Ribbon)

服务实例的清单在客户端，客户端进行负载均衡算法分配。
(从上面的知识咱们已经知道了：客户端能够从Eureka Server中获得一份服务清单，在发送请求时经过负载均衡算法，在多个服务器之间选择一个进行访问)

服务端负载均衡(Nginx)

服务实例的清单在服务端，服务器进行负载均衡算法分配

因此，咱们的图能够画成这样：

6.1Ribbon细节

Ribbon是支持负载均衡，默认的负载均衡策略是轮询，咱们也是能够根据本身实际的需求自定义负载均衡策略的。

@Configuration
public class MySelfRule
{
    @Bean
    public IRule myRule()
    {
        //return new RandomRule();// Ribbon默认是轮询，我自定义为随机
        //return new RoundRobinRule();// Ribbon默认是轮询，我自定义为随机

        return new RandomRule_ZY();// 我自定义为每台机器5次
    }
}

实现起来也很简单：继承AbstractLoadBalancerRule类，重写public Server choose(ILoadBalancer lb, Object key)便可。

SpringCloud 在CAP理论是选择了AP的，在Ribbon中还能够配置重试机制的(有兴趣的同窗能够去搜搜)~

举个例子：

3y跟女友过了几个月，又去东方宝泰了。因为记性很差，又去物业那弄了一份东方宝泰商户清单。
此次看到东方宝泰又开了一间麦当劳，一间在二楼，一间在三楼。原来生意太好了，为了能提升用户体验，在二楼多开了一间麦当劳。
这时，3y问女友：“去哪间麦当劳比较好？要不咱们抛硬币决定？”3y女友说：”你是否是傻，确定哪间近去哪间啊“

优秀博文：

撸一撸Spring Cloud Ribbon的原理-负载均衡策略：https://www.cnblogs.com/kongxianghai/p/8477781.html

7、引出Hystrix

到目前为止，咱们的服务看起来好像挺好的了：可以根据服务名来远程调用其余的服务，能够实现客户端的负载均衡。

可是，若是咱们在调用多个远程服务时，某个服务出现延迟，会怎么样？？

在高并发的状况下，因为单个服务的延迟，可能致使全部的请求都处于延迟状态，甚至在几秒钟就使服务处于负载饱和的状态，资源耗尽，直到不可用，最终致使这个分布式系统都不可用，这就是“雪崩”。

针对上述问题， Spring Cloud Hystrix实现了断路器、线程隔离等一系列服务保护功能。

Fallback(失败快速返回)：当某个服务单元发生故障（相似用电器发生短路）以后，经过断路器的故障监控（相似熔断保险丝）， 向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。
资源/依赖隔离(线程池隔离)：它会为每个依赖服务建立一个独立的线程池，这样就算某个依赖服务出现延迟太高的状况，也只是对该依赖服务的调用产生影响，而不会拖慢其余的依赖服务。

Hystrix提供几个熔断关键参数：滑动窗口大小（20）、熔断器开关间隔（5s）、错误率（50%）

每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，再也不调远程服务。
直到5s钟以后，从新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

Hystrix还有请求合并、请求缓存这样强大的功能，在此我就不具体说明了，有兴趣的同窗可继续深刻学习~

7.1Hystrix仪表盘

Hystrix仪表盘：它主要用来实时监控Hystrix的各项指标信息。经过Hystrix Dashboard反馈的实时信息，能够帮助咱们快速发现系统中存在的问题，从而及时地采起应对措施。

启动时的页面：

监控单服务的页面：

咱们如今的服务是这样的：

除了能够开启单个实例的监控页面以外，还有一个监控端点 /turbine.stream是对集群使用的。从端点的命名中，能够引入Turbine, 经过它来聚集监控信息，并将聚合后的信息提供给 HystrixDashboard 来集中展现和监控。

举个例子：

3y和女友决定去万达玩，去到万达的停车场发如今负一层已经大大写上“负一层已停满，请下负二层，负二层空余停车位还有100个！”
这时，3y就跟女友说：“万达停车场是作得挺好的，若是它没有直接告知我负一层已满，可能我就去负一层找位置了，要是一堆人跑去负一层但都找不到车位的话，恐怕就塞死了”。3y接着说：“看停车位的状态也作得不错，在停车位上头有一个感应(监控)，若是是红色就表明已被停了，若是是绿色就说明停车位是空的”。
3y女友不屑的说：“你话是真的多”

参考资料：

Hystrix ，为何说它是每一个系统不可或缺的开源框架？https://zhuanlan.zhihu.com/p/34304136
深刻理解Hystrix之文档翻译：https://zhuanlan.zhihu.com/p/28523060
谈谈我对服务熔断、服务降级的理解：https://blog.csdn.net/guwei9111986/article/details/51649240
Hystrix几篇文章《青芒》：https://segmentfault.com/u/yedge/articles

8、引出Feign

上面已经介绍了Ribbon和Hystrix了，能够发现的是：他俩做为基础工具类框架普遍地应用在各个微服务的实现中。咱们会发现对这两个框架的使用几乎是同时出现的。

为了简化咱们的开发，Spring Cloud Feign出现了！它基于 Netflix Feign 实现，整合了 Spring Cloud Ribbon 与 Spring Cloud Hystrix, 除了整合这二者的强大功能以外，它还提
供了声明式的服务调用(再也不经过RestTemplate)。

Feign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign, 咱们能够作到使用HTTP请求远程服务时能与调用本地方法同样的编码体验，开发者彻底感知不到这是远程方法，更感知不到这是个HTTP请求。

下面就简单看看Feign是怎么优雅地实现远程调用的：

服务绑定：

// value --->指定调用哪一个服务
// fallbackFactory--->熔断器的降级提示
@FeignClient(value = "MICROSERVICECLOUD-DEPT", fallbackFactory = DeptClientServiceFallbackFactory.class)
public interface DeptClientService {


    // 采用Feign咱们可使用SpringMVC的注解来对服务进行绑定！
    @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
    public Dept get(@PathVariable("id") long id);

    @RequestMapping(value = "/dept/list", method = RequestMethod.GET)
    public List<Dept> list();

    @RequestMapping(value = "/dept/add", method = RequestMethod.POST)
    public boolean add(Dept dept);
}

Feign中使用熔断器：

/**
 * Feign中使用断路器
 * 这里主要是处理异常出错的状况(降级/熔断时服务不可用，fallback就会找到这里来)
 */
@Component // 不要忘记添加，不要忘记添加
public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService> {
    @Override
    public DeptClientService create(Throwable throwable) {
        return new DeptClientService() {
            @Override
            public Dept get(long id) {
                return new Dept().setDeptno(id).setDname("该ID：" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭")
                        .setDb_source("no this database in MySQL");
            }

            @Override
            public List<Dept> list() {
                return null;
            }

            @Override
            public boolean add(Dept dept) {
                return false;
            }
        };
    }
}

调用：

9、引出Zuul

基于上面的学习，咱们如今的架构极可能会设计成这样：

这样的架构会有两个比较麻烦的问题：

路由规则与服务实例的维护间题：外层的负载均衡(nginx)须要维护全部的服务实例清单(图上的OpenService)
签名校验、登陆校验冗余问题：为了保证对外服务的安全性，咱们在服务端实现的微服务接口，每每都会有必定的权限校验机制，但咱们的服务是独立的，咱们不得不在这些应用中都实现这样一套校验逻辑，这就会形成校验逻辑的冗余。

仍是画个图来理解一下吧：

每一个服务都有本身的IP地址，Nginx想要正确请求转发到服务上，就必须维护着每一个服务实例的地址！

更是灾难的是：这些服务实例的IP地址还有可能会变，服务之间的划分也极可能会变。

http://123.123.123.123

http://123.123.123.124

http://123.123.123.125

http://123.123.123.126

http://123.123.123.127

购物车和订单模块都须要用户登陆了才能够正常访问，基于如今的架构，只能在购物车和订单模块都编写校验逻辑，这无疑是冗余的代码。

为了解决上面这些常见的架构问题，API网关的概念应运而生。在SpringCloud中了提供了基于Netfl ix Zuul实现的API网关组件Spring Cloud Zuul。

Spring Cloud Zuul是这样解决上述两个问题的：

SpringCloud Zuul经过与SpringCloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中得到了全部其余微服务的实例信息。外层调用都必须经过API网关，使得将维护服务实例的工做交给了服务治理框架自动完成。
在API网关服务上进行统一调用来对微服务接口作前置过滤，以实现对微服务接口的拦截和校验。

Zuul天生就拥有线程隔离和断路器的自我保护功能，以及对服务调用的客户端负载均衡功能。也就是说：Zuul也是支持Hystrix和Ribbon。

关于Zuul还有不少知识点(因为篇幅问题，这里我就不细说了)：

路由匹配(动态路由)
过滤器实现(动态过滤器)
默认会过滤掉Cookie与敏感的HTTP头信息(额外配置)

9.1可能对Zuul的疑问

Zuul支持Ribbon和Hystrix，也可以实现客户端的负载均衡。咱们的Feign不也是实现客户端的负载均衡和Hystrix的吗？既然Zuul已经可以实现了，那咱们的Feign还有必要吗？

或者能够这样理解：

zuul是对外暴露的惟一接口至关于路由的是controller的请求，而Ribbonhe和Fegin路由了service的请求
zuul作最外层请求的负载均衡，而Ribbon和Fegin作的是系统内部各个微服务的service的调用的负载均衡

有了Zuul，还须要Nginx吗？他俩能够一块儿使用吗？

个人理解：Zuul和Nginx是能够一块儿使用的(毕竟咱们的Zuul也是能够搭成集群来实现高可用的)，要不要一块儿使用得看架构的复杂度了(业务)~~~

参考资料：

微服务与API网关（上）: 为何须要API网关？：http://blog.didispace.com/hzf-ms-apigateway-1/
谈谈 API 网关：https://www.jianshu.com/p/b52a2773e75f
谈谈微服务中的 API 网关（API Gateway）：https://www.cnblogs.com/savorboard/p/api-gateway.html
API网关性能比较：NGINX vs. ZUUL vs. Spring Cloud Gateway ：http://www.360doc.com/content/18/0208/05/46368139_728502763.shtml
谈API网关的背景、架构以及落地方案：http://www.infoq.com/cn/news/2016/07/API-background-architecture-floo
zuul和nginx：https://zhuanlan.zhihu.com/p/37385481

10、引出SpringCloud Config

随着业务的扩展，咱们的服务会愈来愈多，愈来愈多。每一个服务都有本身的配置文件。

既然是配置文件，给咱们配置的东西，那不免会有些改动的。

好比咱们的Demo中，每一个服务都写上相同的配置文件。万一咱们有一天，配置文件中的密码须要更换了，那就得三个都要从新更改。

在分布式系统中，某一个基础服务信息变动，都极可能会引发一系列的更新和重启

Spring Cloud Config项目是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，client经过接口获取数据、并依据此数据初始化本身的应用。

简单来讲，使用Spring Cloud Config就是将配置文件放到统一的位置管理(好比GitHub)，客户端经过接口去获取这些配置文件。
在GitHub上修改了某个配置文件，应用加载的就是修改后的配置文件。

SpringCloud Config其余的知识：

在SpringCloud Config的服务端，对于配置仓库的默认实现采用了Git，咱们也能够配置SVN。
配置文件内的信息加密和解密
修改了配置文件，但愿不用重启来动态刷新配置，配合Spring Cloud Bus 使用~

使用SpringCloud Config可能的疑问：application.yml和 bootstrap.yml区别

https://www.cnblogs.com/BlogNetSpace/p/8469033.html

总结

本文主要写了SpringCloud的基础知识，但愿你们看完能有所帮助~

SpringCloud的资料也不少，我整理一些我认为比较好，想要深刻的同窗不妨看看下边的资源~~~

SpringCloud系列文章参考资料：

史上最简单的 SpringCloud 教程 | 终章https://blog.csdn.net/forezp/article/details/70148833
Spring Cloud基础教程《程序员DD》http://blog.didispace.com/Spring-Cloud%E5%9F%BA%E7%A1%80%E6%95%99%E7%A8%8B/
Spring Cloud 系列文章《纯洁的微笑》：http://www.ityouknow.com/spring-cloud.html
SpringCloud系列文章：https://www.cnblogs.com/woshimrf/tag/SpringCloud/
SpringCloud系列文章《狂小白》：https://www.cnblogs.com/huangjuncong/tag/SpringCloud/
SpringCloud官方文档：http://projects.spring.io/spring-cloud/
Spring Cloud 中文文档：https://springcloud.cc/spring-cloud-dalston.html#_appendix_compendium_of_configuration_properties

参考书籍：

《SpringCloud 微服务实战》

SpringCloud GitHub Demo(看完文章的同窗能够本身练手玩玩，写好了ReadMe了)：

https://github.com/ZhongFuCheng3y/msc-Demo

可能感兴趣的连接：

文章的目录导航(微信公众号端)：https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang
文章的目录导航(PC端)：http://www.zhongfucheng.bitcron.com/post/shou-ji/pcduan-wen-zhang-dao-hang
海量精美脑图：http://www.zhongfucheng.bitcron.com/post/shou-ji/nao-tu-da-quan