springcloud-概念
一.架构演进过程
单体架构----分布式架构----SOA(eg.dubbo)服务治理架构----微服务
随着互联网的发展,需求的激增致使网站应用规模的扩大,最后转成了技术上的压力
系统架构因此也不断地演进、升级、迭代
1.1 集中式架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
存在的问题：
- 代码耦合，开发维护困难
- 无法针对不同模块进行针对性优化
- 无法水平扩展
- 单点容错率低，并发能力差
1.2 垂直拆分
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分：
优点：
- 系统拆分实现了流量分担，解决了并发问题
- 可以针对不同模块进行优化
- 方便水平扩展，负载均衡，容错率提高
缺点：
- 系统间相互独立，会有很多重复开发工作，影响开发效率
1.3 分布式服务
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
优点：
- 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率
缺点：
- 系统间耦合度变高，调用关系错综复杂，难以维护
1.4 服务治理架构（SOA）
SOA ：面向服务的架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键
以前出现了什么问题？
- 服务越来越多，需要管理每个服务的地址
- 调用关系错综复杂，难以理清依赖关系
- 服务过多，服务状态难以管理，无法根据服务情况动态管理
服务治理要做什么？
- 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
- 服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
- 动态监控服务状态监控报告，人为控制服务状态
缺点：
- 服务间会有依赖关系，一旦某个环节出错会影响较大
- 服务关系复杂，运维、测试部署困难，不符合DevOps思想
1.5 微服务
最后演变成了现在的微服务
二.微服务的特点
前面说的SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行拆分。因此两者非常容易混淆，但其实缺有一些差别：
微服务的特点：
- 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
- 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
- 面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
- 自治：自治是说服务间互相独立，互不干扰
- 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
- 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
- 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
- 数据库分离：每个服务都使用自己的数据源
- 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护
restful风格:统一请求路径,不同请求方式,完成不同操作
三.RPC和HTTP
无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？
常见的远程调用方式有以下2种：
- RPC：Remote Produce Call远程过程调用，类似的还有RMI（remote method invoke）。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表.
- Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。
现在热门的Rest风格，就可以通过http协议来实现。
如果你们公司全部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。
相反，如果公司的技术栈多样化，而且你更青睐Spring家族，那么SpringCloud搭建微服务是不二之选。在我们的项目中，我们会选择SpringCloud套件，因此我们会使用Http方式来实现服务间调用。
四.负载均衡Ribbon
Ribbon是Netflix发布的负载均衡器
负载均衡的作用是:告诉消费者应该调用诸多提供者中的哪一个
4.1问题:
在刚才的案例中，我们启动了一个user-service，然后通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问。
但是实际环境中，我们往往会开启很多个user-service的集群。此时我们获取的服务列表中就会有多个，到底该访问哪一个呢？
因为Eureka中已经集成了Ribbon，所以我们无需引入新的依赖。直接修改代码：
在RestTemplate的配置方法上添加@LoadBalanced注解：
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
4.2 默认采用懒加载
Ribbon默认是采用懒加载，即第一次访问时才会去创建负载均衡客户端。往往会出现超时。如果需要采用饥饿加载，即项目启动即创建，可以这样配置：
ribbon:
eager-load:
enabled: true
clients: user-service
五. Hystrix
Hystix,英文意思是豪猪，全身是刺，看起来就不好惹，是一种保护机制。
Hystrix也是Netflix公司的一款组件。
那么Hystix的作用是什么呢？具体要保护什么呢？
Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。
微服务中，服务间调用关系错综复杂，一个请求，可能需要调用1个或多个微服务接口才能实现，会形成非常复杂的调用链路：
如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。
如果此时，某个服务出现异常：
例如微服务I发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：
服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。
这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件，如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。 此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。
Hystix解决雪崩问题的手段主要是服务降级，包括：
5.1 线程隔离
5.2 服务熔断
5.3 SOA服务治理架构
SOA: 面向服务的架构
5.4 Http客户端工具
既然微服务选择了Http，那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很多的http客户端工具，能够帮助我们做这些事情，例如：
- HttpClient
- OKHttp
- URLConnection
六. feign（英译：伪装）
使用feign可以实现远程调用
6.1 负载均衡
集成
6.2 Hystrix
集成
6.3 请求压缩
6.4 日志级别
七.ZUUL网关
7.1 负载均衡
集成
7.2 熔断
集成
7.3 高可用(zuul集群)
7.4 Eureka
没有集成