SpringCloud入门知识总结

架构：
(1)集中式架构：将所有功能都部署在一起，以减少部署节点和成本。
优点：
系统开发速度快
维护成本低
适用于并发要求较低的系统
缺点：
代码耦合度高，后期维护困难
无法针对不同模块进行针对性优化
无法水平扩展
单点容错率低，并发能力差

(2)垂直拆分：根据业务功能对系统进行拆分。
优点：
系统拆分实现了流量分担，解决了并发问题
可以针对不同模块进行优化
方便水平扩展，负载均衡，容错率提高
缺点：
系统间相互独立，会有很多重复开发工作，影响开发效率

(3)分布式服务：将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
优点：
将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率
缺点：
系统间耦合度变高，调用关系错综复杂，难以维护

(4)面向服务架构（SOA)：它是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
SOA缺点：每个供应商提供的ESB产品有偏差，自身实现较为复杂；应用服务粒度较大，ESB集成整合所有服务和协议、数据转换使得运维、测试部署困难。所有服务都通过一个通路通信，直接降低了通信速度。

(5)微服务架构：使用一套小服务来开发单个应用的方式或途径，每个服务基于单一业务能力构建，运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，并能够通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
微服务的特点：
单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
自治：自治是说服务间互相独立，互不干团队独立：每个服务都是一个独立的开发团队，人数不能过多。
技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人相干
前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动端开发不同接口 。
数据库分离：每个服务都使用自己的数据源 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护。

SpringCloud：不是一个组件，而是一个组件的整合，常见的组件有(Eureka注册中心，Gageway网关，Ribbon负载均衡，Feign服务调用，Hystrix熔断器）。
(1)SpringCloud 和Dubbo有哪些区别
定位不一样：dubbo的定位始终是一个RPC框架，而SpringCloud的目标是微服务下的一站式解决方案，目前Dubbo和SpringCloud只能二选一。
(2)SpringBoot和SpringCloud
SpringBoot就是spring的封装，专注于方便的开发单个个体模块或者是微服务。
SpringCloud是关注于全局的微服务协调治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来是一套综合的解决方案，SpringBoot可以离开SpringCloud单独使用,而SpringCloud离不开SpringBoot。

Eureka：

(1)相较于zookeeper
<1>没有监听，其是由心跳机制监控（服务提供者通过http的方式向Eureka刷新自己的状态）。
<2>不同于zookeeper的使用方式，Eureka并非是安装的第三方软件，而是嵌入在项目中的一个服务。
<3>zookeeper在集群时采用主从复制的方式，当leader挂掉后，其他节点将进行选举制，此时zookeeper变得不可用，而Eureka采用cluster方式，不存在leader。
<4>Eureka的访问是基于RESTful。
(2)Eureka高可用（集群的搭建）
<1>采用cluster方式，互相保存信息。
<2>在当前Eureka中注册其他Eureka的访问路径。
(3)Eureka相关注解
<1>@EnableEurekaServer
<2>@EnableDiscoverClient或@EnableEurekaClient（二选一）

Ribbon:
(1)相较于Nginx
<1>存在于客户端，而Nginx则是一个集成式的LB插件，即单独存在。
<2>功能上，Ribbon仅用于负载均衡，而Nginx可用于静态页面的存储，用于弥补tomcat服务器的不足，以及处理高并发和限流等。
<3>Ribbon基于轮询和随机两种算法。

Hystrix：

(1)什么是雪崩
当一个服务出现异常，此时这个服务占用的线程不会释放，当服务器处理完其他服务时，就会继续向当前服务提供线程，直至服务器的线程均被此服务占用，此时服务器因不能处理其他服务而崩掉。
(2)什么是服务降级
当服务判定失败时，返回fallback，释放当前服务占用的线程，且后续不再调用此服务，确保服务器的正常运行。
(3)什么是线程隔离
用户请求不直接访问服务，而是使用线程池中空闲的线程访问服务，加速失败判断时间。
(4)Hystrix
<1>综合线程隔离与服务降级功能。
<2>相关注解
main中：@SpringCloudApplication（是一个Eureka客户端、SpringBoot、熔断器客户端三合一的注解）
单个方法–controller中：@HystrixCommand(fallbackMethod=“返回自定义错误提示的方法的方法名”)//此方法返回值和参数必与调用方法相同。
一个controller中的多个方法–controller上：@DefaultProperties(fallbackMethod=“返回自定义错误提示的方法的方法名”) 此方法返回值为String且无参数，在需要进行熔断判断的方法上加@HystrixCommand即可

Feign：
(1)Feign的作用
自动凭借服务提供方路径，实现微服务的调用。
(2)如何启用Feign
<1>相关注解
main中：@EnableFeignClient
自定义的接口中：@FeignClient(“服务提供方在Eureka中的注册名称”)
且此自定义接口的方法要有RESTful风格请求和对应参数（参照服务提供者对应方法的访问路径去除端口前部分），此时完成的拼接未http：//服务提供方在Eureka中的注册名称/请求路径/参数
再在controller中的方法调用此接口方法即可，但需传入对应参数值。

Getway
不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会有以下问题：
客户端多次请求不同的微服务，增加了客户端的复杂性
存在跨域问题
认证复杂，每个服务都需要独立认证
难以重构，将一个服务拆分成若干个服务，当服务端发生改变，客户端也要跟着发生变化

主要功能：过滤和路由
优点：
安全，只有网关对外暴露，微服务可以隐藏在内网中，通过防火墙保护
同一认证授权
减少客户端与各个微服务之间的交互次数
易于监控，可以通过网关搜集监控数据并将其推送到外部系统进行分析

SpringCloud Config：分布式配置中心，即所有服务在配置中心拉取对应配置信息，一般借由git实现配置中心的存储，用于多个服务的调用。
SpringCloud Bus：用于实时更新git中的配置文件内容，而不用每次修改都需要重启服务才能有效。

项目综合大致架构：