微服务的发展
微服务的发展:
传统单体应用架构所面临的许多问题,因而逐渐取代单体应用成为主流架构模式。
-
单体应用时代:最初,大多数应用采用单体架构,将整个应用打包在一个巨大的单元中all in one。这种架构简单易操作,但存在可扩展性差、部署依赖性大、技术栈难以演进等问题。
-
SOA时代:SOA架构通过服务化拆分应用,提供一定的松耦合和复用能力。但是服务化粒度还不够细,难以应对高度动态和自治的场景。
-
微服务全面应用:Docker、Kubernetes等容器与编排技术的流行使微服务最终实现全面应用。它解决了技术和运维问题,使微服务架构得以高效落地。
微服务特点
单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责
自治:团队独立、技术独立、数据独立,独立部署和交付
面向服务:服务提供统一标准的接口,与语言和技术无关
隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题
微服务:一种良好的分布式架构方案
①优点:拆分粒度更小、服务更独立、耦合度更低
②缺点:架构非常复杂,运维、监控、部署难度提高
微服务的注册中心,配置中心与网关:
目前主流的注册中心: nacos
目前存在的项目维护的注册中心:nacos eureka
nacos的配置中心:
- 实现配置的统一管理,配置的优先级:带环境的》不带环境的》默认配置。
- 在远端配置可以实现热部署,即更改远端配置会实时影响微服务的运行环境(状态?)。
nacos与eureka的区别
[
服务提供者会在nacos注册自己的服务信息表,当消费者要使用微服务的时候就会取nacos拉取服务列表,然后nacos会根据负载均衡策略给用户一个可以使用的服务器。
nacos与eureka的区别:
两者都有心跳检测机制,但是nacos分非临时实例检测与临时实例检测,临时实例检测会在服务器无法提供服务的时候直接剔除注册列表。剔除的机制即在定时时间后为给注册中心发送心跳信息。
但是nacos的非临时实例检测是自己主动去询问该服务信息是否不可使用,如果不可使用也不会剔除注册列表但是会一直等待该服务重新上线。该检测机制比较消耗性能。
另外nacos的注册列表有变化会及时跟新缓存列表(concurrentHashMap)并推送信息给消费者,告诉消费者服务已经更新。
]
nacos的内核原理
基于distro协议实现AP:
假设有一个client客户端(消费者)然后他要访问nacos搭建的微服务集群,假设访问的集群内服务器数目为3,在访问第一台服务器的时候该nacos服务器没有相关服务就会通过ip,port的算法路由到一个ConcurrentHashmap的nacos列表上(假设一份大的数据会均匀分布在3台nacos服务器上,如果此时某台nacos服务器挂了就会少了1/3的数据),该nacos若没有客户端请求需要的数据,就会有一个异步同步机制(cp或ap,如果选择cp同步则所有的nacos都需要在同一时间完成同步并返回效率较低所以选择异步同步即,nacos是可以支持短暂的数据不一致情况但是会用有数据的nacos服务器给用户返回信息),被推动同步的服务器会注册一个监听器去监听推送服务器是否把信息推送过来。当推送过来时会完成该nacos服务器的信息同步然后返回一个通知给客户端。
nacos基于zookeeper的raft协议实现CP:
当用户访问该微服务时,nacos集群会通过一个投票选举的协议选出一台leader服务器,其余的为follwer服务器,写操作只能通过leader服务器,如果客户端和集群之间ip,port算法选中的是一个follower,则follower会将请求转发给leader,leader在同步数据之前leader会在该集群下发起广播请求,询问follower是否可以完成数据同步。follower会评估自己是否可以将数据写入到自己的服务器,如果可以会发送通知到leader,此时raft协议并非完全完成cp协议,如果follower反馈的通知数量超过集群数目一半就会执行commit,写入该数据然后返回,如果此时返回数据的服务器恰好是另外50%没有写入数据的服务器,raft协议还设计了一系列的补偿逻辑。
nacos雪崩:
假设一个nacos集群里面有3台nacos服务器,每台服务器可以承担1k的并发量,当在极限负载的情况下,三台服务器如果挂了一台,会带来什么后果?
另外两台也会挂,因为一台挂了,nacos会将挂了的那台剔除服务器列表,3k的并发量就会均摊给另外两台1k并发负载的服务器上,这两台好的就会直接被高并发打死。导致nacos服务雪崩,
所以解决方法就是给这个集群设置一个保护阈值,实现AP,假设这个保护阈值是0.8,即挂了1台就触发保护机制:nacos不会立即剔除该挂掉的服务器,会把他捞上来,继续提供访问,但是无法提供数据访问等服务,但是可以分担并发量。nacos会等该该服务的恢复或重启。
网关:gateway
-
网关是用于拦截微服务外的请求,如果直接访问微服务内的url请求会直接被网关拦截,判断该请求是否符合访问微服务,如果不符合就直接拦截,符合(如身份信=息,jwt这些)就会放行,但放行不是直接去放行,要通过路由route去nacos拉取服务列表,然后做负载均衡,根据负载均衡策略(ip 端口号 协议)选择一个合适的服务器,最后再放行。
-
关于跨域问题:
由于ajax默认不可跨域,但是在微服务项目中,服务器可能不在一个机房甚至不在同一个地区,遇到负载均衡策略选取服务器可能就会涉及到跨域问题,要解决跨域问题就可以使用gateway网关,在网关模块里面配置相关http重定向的信息设置,让其可以跨域访问到对应的服务器。
spring:
cloud:
gateway:
# 。。。
globalcors: # 全局的跨域处理
add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
corsConfigurations:
'[/**]':
allowedOrigins: # 允许哪些网站的跨域请求
- "http://localhost:8090"
allowedMethods: # 允许的跨域ajax的请求方式
- "GET"
- "POST"
- "DELETE"
- "PUT"
- "OPTIONS"
allowedHeaders: "*" # 允许在请求中携带的头信息
allowCredentials: true # 是否允许携带cookie
maxAge: 360000 # 这次跨域检测的有效期
熔断器:
Hystrix 熔断器有一个阈值,在多长时间内访问多少次,有多少次失败.如果达到了这个请求,熔断器会处于打开的状态,就可以使这次请求快速失败,过了一定的时间,熔断器会处于一个半开状态.在半开状态下如果请求通过,熔断器就关闭,如果还是没通过,熔断器就又处于打开状态.