SpringCloud（分布式架构：概念）
注意：本篇文章并不教授怎么搭建微服务项目，微服务更多的是概念上面的理解，网上有很多案列，看完概念之后可以尝试自己动手搭建一下，请耐心阅读以下文章。
如果有需要源码的可以联系我，我上传了一套微服务架构的demo在码云上面
目录：
前言：
1.0 什么是SpringCloud？
1.1、微服务优缺点：
2.0 怎么去解决微服务出现的一些问题？
3.0 SpringCloud五大组件
3.1、Eureka，实现服务治理（服务注册与发现）
3.2、Ribbon（客户端的负载均衡器 ）
3.2.1、Ribbon和Nginx的区别（负载均衡）？
3.3、Hystrix（断路器）
3.3.1、服务熔断：
3.3.2、服务隔离：
3.3.3、服务降级：
3.3.4、服务雪崩：
3.3.5、服务限流：
3.4、Zuul（网关）
3.5、Config（配置中心）
前言：
我们都知道一个成熟的大型网站的系统架构并非一开始就设计的非常完美，也没有一开始就具备高性能、高并发、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步演变过来的，慢慢的完善的。 在这个过程中，开发模式、技术架构等都会随着迭代发生非常大的变化。 而针对不同业务特征的系统，各自都会有自己的侧重点，例如像淘宝这类的网站，要解决的重点问题就是海量商品搜索、下单、支付等问题; 像腾讯这类的网站，要解决的是数亿级别用户的实时消息传输;而像百度这类的公司所要解决的又是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。
1.0 什么是SpringCloud？
微服务是最近几年才出现的新名词，它在各大技术社区、博客、论坛和新闻报道中经常被提及，是程序员和架构师经常讨论的话题。的确，微服务已经是技术圈的热门话题，那么到底什么是微服务呢?微服务产生的意义又是什么呢？微服务有哪些优势和缺点？另外,微服与SOA 架构有什么关系？下面让我来为你逐一阐述。
将单体应用，根据功能和模块拆分成一个个独立的服务，这个独立的服务就是微服务。多个服务之间，通过轻量级的通行协议（http/rpc）互相配合，相互调用，对外提供统一的服务。这个架构就是微服务架构（分布式）。
1.1、微服务优缺点：
优点：
- 每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求
- 开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
-
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
- 微服务能使用不同的语言开发。
- 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。
-
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
- 微服务允许你利用融合最新技术。
- 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
- 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。
缺点：
- 开发人员要处理分布式系统的复杂性。
- 多服务运维难度，随着服务的增加，运维的压力也在增大。
- 系统部署依赖困难。
- 服务间通信成本高。
- 数据一致性的问题。
-
系统集成测试。
-
性能监控…
这里是SpringCloud的架构图：
2.0 怎么去解决微服务出现的一些问题？
SpringCloud还提供了一整套的分布式架构和一整套解决方案还有对应的组件，它这个框架不提供具体的服务，只解决服务与服务之间产生的问题。
2.1、如何知道其他服务？
针对这个问题推出了Erueka。可以使用中间件，每个服务一启动就往中间件里面注册一个，这样就可以清楚的知道每个具体的服务。
2.2、服务之间调用时如何进行负载均衡？
针对这个问题推出了Ribbon。在服务调用者里面添加一个组件。多个不同的客户端服务，把他们提供的地址拿过来。第一次分配到第一个服务器，第二次分配到第二个服务器，以此内推，实现客户端的负载均衡。
2.3、当调用服务时，被调用的服务宕机，怎么处理？
针对这个问题推出了Hystrix 。在服务端加上一个断路器组件，当服务挂掉的时候立即中断服务，保存数据，照成不必要的损失。
2.4、用户请求的路由问题？
针对这个问题推出了Zuul 。路由组件，由路由组件精准的去控制每个服务该往哪里走，避免服务堵塞。
2.5、多个微服务的配置管理问题？
针对这个问题推出了Config。配置中心组件，把所有服务所需的配置文件放入这个里面，集中解决。
3.0 SpringCloud五大组件
下面介绍一下SpringCloud五大核心组件和其功能。
3.1、Eureka，实现服务治理（服务注册与发现）
原理图：
SpringCloud提供了多种注册中心的支持，这其中就包括Eureka、ZooKeeper等，我们平时常用的也是这两种。回归正题，Eureka主要就是用来注册服务的，其中包括两部分：Eureka Client、Eureka Server
-
Eureka Client：包含服务提供者、服务消费者，主要负责服务注册、心跳续约与健康状况查询
-
Eureka Server：提供注册服务，各个节点启动后，都会在Eureka Server中注册，可用的节点信息可以在Eureka Server中的服务注册表中找到（Eureka Server之间通过复制的方式来完成数据的同步）
应用启动后，Eureka Client会向Eureka Server发送心跳，一般默认周期为30秒，如果Eureka在多个心跳周期内（一般为90秒）没有接受到某个节点的心跳，Eureka就会进入自我保护机制。
进入保护机制的提示语：
这其实是eureka的自我保护机制：
当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。
综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。在Spring Cloud中，
可以使用：eureka.server.enable-self-preservation = false 禁用自我保护模式。
3.2、Ribbon（客户端的负载均衡器 ）
原理图：
Ribbon是 Netflix公司开源的一个负载均衡的组件，它属于上述的第二种方式，是将负载均衡逻辑封装在客户端中，并且运行在客户端的进程里。Ribbon是一个经过了云端测试的IPC库,可以很好地控制HTTP和TCP客户端的负载均衡行为。
-
Ribbon是一个客户端的负载均衡器，他提供对大量的HTTP和TCP客户端的访问控制
-
Ribbon负载均衡策略：简单轮询、权重、随机、重试等多种策略
-
负责将同一个服务提供集群拉取到本地，进行客户端的负载均衡的组件
3.2.1、Ribbon和Nginx的区别（负载均衡）？
①、Nginx也叫服务器端的负载均衡，是处于架构方面的负载均衡，它是直接针对用户的请求，进行负载均衡，在服务器端就解决了这个问题。
②、Ribbon是客户端里面所添加的一个负载均衡，是在引用内部起效果的，而且它是将服务提供的列表拿到本地，进行轮循或者采用随机算法的这种方式进行负载
Ribbon资源浪费怎么解决？
多个服务消费者都需要自己的ribbon用于负载均衡，有点浪费资源。
解决方案：
springCloud提供了解决方案：把服务消费者里面的内容都抽离出来，定义一个接口，类似负载均衡的实现类，自动帮我们进行负载均衡。提供了一个专门的feign组件（@LoadBalanced）注解，它是一个面向接口的负载均衡组件，底层还是使用（restTemplate+ribbon），需要导入相关依赖。
3.3、Hystrix（断路器）
原理图：
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
Hystrix提供两个命令，分别是HystrixCommand、HystrixObservableCommand，通常是在Spring中通过注解和AOP来实现对象的构造
3.3.1、服务熔断：
简单来说，就是我们生活中的“保险丝”。如果熔断器打开，就会执行短路，直接进行降级；如果熔断器关闭，就会进入隔离逻辑。
默认触发熔断器的条件为：最近一个时间窗口（默认为10秒），总请求次数大于等于circuitBreakerRequestVolume Threshold（默认为20次）并且异常请求比例大于circuitBreakerError ThresholdPercentage（默认为50%），此时熔断器触发
3.3.2、服务隔离：
这种模式就像对系统请求按类型划分成一个个小岛的一样，当某个小岛被火烧光了，不会影响到其他小岛。例如可以对不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源。这种模式使用场景非常多，例如将一个服务拆开，对于重要的服务使用单独服务器来部署，再或者公司最近推广的多中心。
3.3.3、服务降级：
本来会请求正常的服务，现在因为服务不可用，给我们返回一点点预期的结果，这个预期的结果就没有去怎么使用资源了，就是告诉我们此服务已宕机，或者此服务异常之类的
3.3.4、服务雪崩：
在分布式架构系统中，因某个服务不可用，导致扇出（就是像一把扇子一样，你调用我，我调用其他两个，其他两个调用更多的服务）的服务也宕机，进而整个服务崩溃
3.3.5、服务限流：
在分布式架构系统中，因某个服务不可用，导致扇出（就是像一把扇子一样，你调用我，我调用其他两个，其他两个调用更多的服务）的服务也宕机，进而整个服务崩溃
3.4、Zuul（网关）
原理图：
网关相当于一个网络服务架构的入口，所有网络请求必须通过网关转发到具体的服务。主要功能：统一管理微服务请求、负载均衡、动态路由、权限控制、监控、静态资源处理等Zuul作为路由网关组件，在微服务架构中有着非常重要的作用，主要体现在以下6个方面。
- Zuul、Ribbon以及 Eureka相结合，可以实现智能路由和负载均衡的功能，Zuul能将请求流量按某种策略分发到集群状态的多个服务实例。
- 关将所有服务的API接口统一聚合，并统一对外暴露。外界系统调用API接口时都是由网关对外暴露的 API 接口，外界系统不需要知道微服务系统中各服务相互调用的复杂性。微服务系统也保护了其内部微服务单元的API 接口，防止其被外界直接调用，导致服务的敏感信息对外暴露。
- 网关服务可以做用户身份认证和权限认证，防止非法请求操作API 接口，对服务器起到保护作用。
- 网关可以实现监控功能，实时日志输出，对请求进行记录。
- 网关可以用来实现流量监控，在高流量的情况下，对服务进行降级。
- API接口从内部服务分离出来,方便做测试。
3.5、Config（配置中心）
每个微服务都具有自己的配置文件，当项目大的时候，这样子维护起来非常麻烦，操作繁琐，为了便于管理微服务的配置文件，针对这个提供了一个叫配置中心的组件spring cloud - config，也分为服务端和客户端两部分，在需要配置文件的地方加上client，连配置中心，把配置文件统一的交由配置中心进行管理，只要在这里修改，在其他的就可以一起同步修改。这就是为什么需要配置中心的原因
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
SpringCloud Config分为服务端和客户端两部分。如图所示：
Config Server服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。
Config Client客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。
如同我上面所说，微服务架构，更多的是概念上面的一些问题。并不提供具体的服务，只解决服务与服务之间产生的问题。多去看一下概念，然后总结，用自己的话和学到的东西去教授别人，这样才能从中发现自己缺点与不足。
学习的道路永无止境，加油！