目录
一、系统架构演变
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刷新自己的状态
（1）服务下线
当服务进行正常关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心：“我要下线了”。服务中心接受到请求之后，将该服务置为下线状态。
（2）失效剔除
有些时候，我们的服务提供方并不一定会正常下线，可能因为内存溢出、网络故障等原因导致服务无法正常工作。Eureka Server需要将这样的服务剔除出服务列表。因此它会开启一个定时任务，每隔60秒对所有失效的服务（超过90秒未响应）进行剔除。 可以通过eureka.server.eviction-interval-timer-in-ms参数对其进行修改，单位是毫秒，生产环境不要修改。这个会对我们开发带来极大的不变，你对服务重启，隔了60秒Eureka才反应过来。开发阶段可以适当调整，比如：10秒
（3）自我保护机制
我们关停一个服务，就会在Eureka面板看到一条警告：这是触发了Eureka的自我保护机制。当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服务实例的比例是否超过了85%。在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来，不予剔除。生产环境下这很有效，保证了大多数服务依然可用。
自我保护就是15分钟内心，某个服务，跳检测失败的的比例超过85%，才会进行提出服务；没有超过85就保护起来，不进行提出；这样做的原因是-----在生产环境中，某些服务可能因为网络延迟的原因没有相应，实际上这个服务并没有宕机，对于这中情况不予剔除服务显然是最好的选择。
但是这给我们的开发带来了麻烦， 因此开发阶段我们都会关闭自我保护模式：（itcast-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的负载均衡功能。
【*】本地负载均衡和服务端负载均衡的区别
- Ribbon是本地负载均衡，也就是客户端负载均衡，到底访问集群的哪台服务器是由本地客户端决定的
- Nginx是服务器负载均衡，当客户端请求发送给Nginx代理服务器之后，具体访问哪台服务器是由Nginx决定的
- Ribbon负载均衡解析
Ribbon是springCloud（本地）客户端负载均衡器，当服务做成集群的时候，在注册中心体现的是一个集合，当客户端调用接口的时候，会在Eureka注册中心获取服务注册信息的列表，然后缓存在本地jvm中，然后在本地实现RPC远程技术进行调用
- Ribbon负载均衡算法解析
客户端负载均衡实现的算法就是总请求数，对服务集群数取模，例如总请求数为3，被访问的集群数为2，那么3 % 2为一，那么第三个请求访问的真实服务器就是第一个服务器
- 本地负载均衡技术和服务器端负载均衡技术应用场景
-
本地负载均衡技术适合微服务的RPC远程调用
-
服务器负载均衡针对的是服务器，例如Tomcat等
-
【*】SpringCloud支持的两种客户端调用工具
- RestTemplate：使用的比较少
- Feifgn客户端工具：使用的最多
Feifn是一个声明式的Http客户端待用工具，采用接口+注解的方式实现，易读性强
【*】服务雪崩效应
默认情况下Tomcat只有一个线程池去处理客户端发送的所有请求，在高并发的情况下，如果客户端的所有请求堆积到了同一个服务接口上，tomcat的所有线程都会处理该接口的请求，导致其他接口服务无法访问。
1315
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
