目录
一、系统架构演变
1.集中式架构
（1）集中式架构，是指由系统的所有业务单元，都集中部署到一台或者多台服务器组成的中心节点上
（2）图解
（3）优点
部署方便
（4）缺点
①不能水平扩展：承载的并发量小 【注】水平扩展：同时增加多个服务器实现负载 垂直扩展：提高单台服务器的性能
②代码耦合性强，不利于功能的扩展
（5）应用场景
小型项目，访问量比较低
2.垂直架构
（1）将系统的各个模块拆分，分别部署在不同的服务器
（2）图解
（3）优点
①提高的并发：将不同的模块部署到不同的服务器，对访问量比较大的模块，进行集群增加服务器的操作，充分的节约服务器的成本
②方便水平扩展，可以针对某个模块进行定向优化
（4）缺点
代码重复度高，不同模块之间的功能有重复
3.分布式服务
（1）垂直架构代码重复度高，维护困难，分布式将核心的业务模块抽离出来，互相调用
（2）图解
（3）优点
①提高了代码的复用率
（4）缺点
①系统调用关系复杂，系统的结构不好管理，服务之间通过接口去调用，需要开发各种接口，调用结构过程比较复杂
4.SOA架构
（1）面向服务架构：因为分布式服务之间的调用接口关系不好管理，所以SOA架构将服务进行集中管理（ESB），服务之间的通讯通过ESB进行集中式管理
（2）图解
（3）优点
①服务被注册中心进行管理，简化了服务之间的调用关系
（4）缺点
-
服务间会有依赖关系，一旦某个环节出错会影响较大
-
服务关系复杂，运维、测试部署困难
5.微服务架构
（1）微服务架构是从SOA架构演变过来的，微服务架构比SOA架构的服务更加细粒度化，每个服务之间互不影响，都有自己独立的数据库，独立的redis，采用restful风格的API，也就是HTTP协议+JSON格式进行传输，更加轻量化。
（2）图解
（3）优点
①单一职责，服务之间互不干扰
②去中心化：服务之间的通讯使用restful风格
（4）缺点
①分布式系统的复杂性比较高，运维的难度比较大
6.微服务和SOA的区别
（1）微服务是由SOA演变过来的，微服务相比较SOA更加细粒度化，微服务的服务之间的通讯使用的是restful风格，SOA服务之间的通讯使用的是ESB进行中心化管理，微服务的通讯采用的是HTTP协议+JSON格式（restful）进行通讯，比较轻量；SOA使用的时HTTP+XML方式进行通讯，所以数据传输的速度比微服务慢一些;SOA可能存在数据库之间的共享，但是微服务强调每个服务都是单独的数据库，保证每个服务之间互不影响。
二、服务的调用方式
常见的远程调用方式有以下两种
1.RCP
（1）基于TCP协议（相对于HTTP更加底层），速度快些
（2）自定义数据传输格式
（3）代表的技术时WebService和dubbo
2.HTTP
（1）基于TCP协议
（2）规定了传输格式（json）
（3）消息封装臃肿，速度慢一些
（4）对技术的提供方和调用方没有技术限制
3.两者的使用场景
公司的技术栈都是java的情况下使用dubbo比较好
公司的技术栈比较丰富使用SpringCloud
三、SpringCloud的概念
SpringCloud和dobbu都是服务框架
SpringCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大
dubbo的开发难度较大，原因是dubbo的jar包依赖不好管理；SpringCloud把很多流行的分布式技术集中到一起，进行统一的版本管理
四、微服务的场景
服务的提供者，服务的调用者，服务注册中心
服务的提供者个调用者都需要Eureka的客户端，因为两者之间的联系都是通过Eureka注册中心。
所有的服务都会将自己注册到注册中心中，在调用时可以直接在注册中心获取其他服务的信息
五、Eureka注册中心
管理服务，提供了服务的发现，注册和状态监控，各个服务都可以在注册中心中找到自己所需要调用服务的信息
-
Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
-
提供者服务：启动后向Eureka注册自己信息（地址，提供什么服务）
-
消费者服务：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
-
心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态
六、Ribbon负载均衡
（1）两种默认负载的算法，分别时轮询和随机算法，可以通过配置进行选择，当然可以自定义负载均衡算法
（2）需要在调用者服务配置，因为调用者向被调用者服务器发起请求，请求到对方的哪台服务器，当然请求的方式（负载均衡就是对请求方式进行优化，按实际情况分配将多个请求分别分配到不用的服务器，使多个服务器共同分担系统的压力）是由调用者决定
七、Hystrix延迟容错库
（1）在多个服务的情况下，一个请求可能需要多个服务来处理，如果此时其中一个服务器出现问题，就会阻塞，当大量的请求仍然访问这个服务的时，由于服务器支持的线程数和并发数有限制，当这些服务器资源耗尽，导致所有其它服务都不可用，形成雪崩效应。就像汽车生产线生产汽车，但是组装汽车的某一个零件没法使用，就会导致整个生产线因为这个零件无法成功组装汽车。
（2）解决雪崩的问题有两种方案
①线程隔离
Hystrix会为每个服务分配一个小的线程池，当用户发起请求时，如果线程池已满就会拒绝调用；
请求超时就会进行降级处理，返回一个友好的信息，至少会看到执行的结果，而不会直接阻塞，这样最多会影响线程池的资源，对其他的服务没有影响。
【注】降级处理就是保证核心服务，非核心服务不可用或者不可用
【注】阻塞，当请求一直被阻塞，可能会导致雪崩问题
②服务熔断
- 服务调用方可以自己判断，那些服务反应慢，或者存在大量的超时情况就会主动熔断，防止整个系统被拖垮
- 服务熔断有三种状态
- Closed 关闭状态：所有的请求都可以访问
- Open 打开状态：所有的请求都会被降级 【注】当一定时间的请求失败百分比超过50%，且请求次数不低于20次
- Half Open 半开状态：Open状态不是永久的，有一个5s的休眠期，随后进入半开状态，释放一部分请求，如果者部分请求是健康的，则会完全的关闭断路器，否则继续打开进入休眠计时。
（3）需要在调用者服务配置，因为什么时候进行请求，什么时候终止请求就是应该有请求方（服务的调用者去控制）
八、Feign
（1）Feign可以帮助我们更便捷的使用HTTP API，ResTemplate需要写被调用服务的IP等信息，而Feign只需要知道被调用服务的ID即可
（2）Feign继承了Ribbon负载均衡和Hystrix延迟容错库
（3）配置在服务的调用方
九、Zuul网关
（1）所有的请求首先经过网关，Zuul主要功能对请求进行过滤和路由，可以对外暴露聚合AP，保持整个系统的稳定性。
（2）Zuul里面还内置了Ribbon的负载均衡功能。
来源：CSDN
作者：SuperLBY
链接：https://blog.csdn.net/qq_39175358/article/details/104176575