SpringCloud入门理解
这是来自菜鸡选手的搜罗集合。侵权删。
一、什么是微服务
微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。降低各个服务之间的耦合，防止修改一个模块时牵一发而动全身。目前企业常用的微服务架构主要有SpringCloud和Dubbo。
二、SpringCloud 与 SpringBoot的关系
SpringBoot是Spring推出的用于解决传统框架配置文件冗余、装配组件繁杂的基于maven的解决方案，旨在快速搭建单个微服务。
SpringCloud是解决各个微服务之间协调与配置，服务之间的通信、熔断、负载均衡等整合各个微服务的框架。Spring Cloud 并不重复造轮子，而是将市面上开发得比较好的模块集成进去，进行封装，从而减少了各模块的开发成本。换句话说：Spring Cloud 提供了构建分布式系统所需的“全家桶”。
SpringCloud依赖于SpringBoot。而SpringBoot并不依赖于SpringCloud,甚至还可以和Dubbo进行优秀的整合开发。
三、SpringCloud常用模块--服务发现
对于Dubbo服务指一个接口，而对SpringCloud来说，一个服务代表一个工程。当SpringCloud需要调用一个服务时，即需要调用一个工程，需要知道工程的ip与端口号。
传统应用中，服务实例的网络地址是相对静态的，你的代码可以从一个很少更新的配置文件中读取网络地址。在一个现代的，基于云的微服务应用中，这个问题就变得复杂多了，服务实例的网络地址是动态分配的。而且，由于自动扩展，失败和更新，服务实例的配置也经常变化。这样一来，你的客户端代码需要一套更精细的服务发现机制。
具体内容推荐一篇博客，清晰易懂
https://blog.csdn.net/u011277123/article/details/88994535
四、SpringCloud常用模块--客户服端负载均衡
https://blog.csdn.net/qq_20619819/article/details/81089997
负载均衡分为两种，一种是服务端负载均衡，一种是客户端负载均衡。
服务端负载均衡：分为两种，一种是硬件负载均衡，还有一种是软件负载均衡。
重点看软件负载均衡：主要是在服务器上安装一些具有负载均衡功能的软件来完成请求分发进而实现负载均衡，常见的就是Nginx。Nginx采用的是反向代理技术，代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
正向代理：客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。
反向代理：客户并不知道代理是转交请求并获得数据返回，客户以为此服务器即原始服务器，反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。
无论是硬件负载均衡还是软件负载均衡都会维护一个可用的服务端清单，然后通过心跳机制来删除故障的服务端节点以保证清单中都是可以正常访问的服务端节点，此时当客户端的请求到达负载均衡服务器时，负载均衡服务器按照某种配置好的规则从可用服务端清单中选出一台服务器去处理客户端的请求。这就是服务端负载均衡。
客户端负载均衡，Ribbon是一个基于HTTP和TCP的客户端负载均衡器，当我们将Ribbon和Eureka一起使用时，Ribbon会从Eureka注册中心去获取服务端列表，然后进行轮询访问以到达负载均衡的作用，服务端是否在线这些问题则交由Eureka去维护。那么这个时候发现这两者的机制差不多，都是通过心跳维护有效服务清单列表，不同之处在于清单列表的存储位置。在Spring Cloud中我们如果想要使用客户端负载均衡，方法很简单，开启@LoadBalanced注解即可，这样客户端在发起请求的时候会先自行选择一个服务端，向该服务端发起请求，从而实现负载均衡。
五、SpringCloud常用模块--服务网关
https://www.jianshu.com/p/6ed93de6f42a
为什么要使用网关？
API网关的出现的原因是微服务架构的出现，不同的微服务一般有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成完成一个业务需求，如果让客户端直接与各个微服务通信，会出现以下的问题。
1、客户端会多次请求不同的微服务，增加了客户端的复杂性。
2、存在跨域请求，在一定场景下处理相对复制。
3、认证复杂，每个服务都需要独立的认证。
4、难以重构，随着项目的迭代。可能需要重新划分微服务。如果客户端与微服务直接通信，那么重构将会很复杂。
5、某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难。
以上的问题可以借助API网关来解决。API网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过API网关这一层。也就是说，API网关可以完成安全、性能、监控等功能，而服务提供者可以专门的完成具体的业务逻辑。
六、SpringCloud常用模块--断路器
在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
为了解决这个问题，业界提出了断路器模型。
