3、微服务的请求地址不同,很容易引起跨域问题。
4、客户端请求微服务需要保证安全认证,但每个服务都要进行认证。
5、将来的项目重构,微服务的变化,如:把多个服务合并一个服务,或一个服务拆分多个服务;这样会导致客户端请求需要重构。
6、限流、降级、监控等需求,会导致实现复杂,每个服务都要实现,重复代码。
遇到这些问题,**我们怎么去解决呢?**我们只要增加一个API网关。
什么是API网关?
API网关是一个服务器,是系统的唯一入口。从面向对象设计的角度看,它与外观模式类似。API网关封装了系统内部架构,为每个客户端提供一个API入口。
API拥有一些职责,如身份验证、监控、负载均衡、缓存、流控。API网关方式的核心要点是,所有客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。
简洁图:
生产图:
网关优点
通过上图中API网关做为系统统一入口,实现了对各个微服务间的整合,同时又做到了对客户端友好,屏蔽系统的复杂性和差异性。对比之前无API网关模式,API网关具有几个比较重要的优点:
1、网关可以和微服务注册中心连接,动态增加微服务应用,进行服务扩容
2、网关对于无法访问的服务,做到自动熔断
3、网关可以方便实现蓝绿部署、金丝雀发布
4、网关可处理微服务公共需求,简化微服务职责
5、网关可帮助客户端实现负载均衡
下面老顾就用图解的方式进行说明
接口优化
我们发现各个微服务的接口返回体是不一样的,在之前没有网关的时候,客户端获取商品id为1的商品信息时,需要分别请求商品信息服务、价格服务、库存服务等,才能获得完整的商品信息。客户端自行进行数据组装处理。有了网关这个多次接口请求就完全的交给网关进行处理,客户端只要请求/good/1一个接口就行了,网关会请求多个微服务,把多个微服务返回的值进行合并,一次性返回完整的信息。简化了客户端请求接口的复杂性。
注意:有些业务数据,不一定要同步返回给客户端,也许异步会更好,根据用户体验,业务需求而定。如:促销价格的话,也许就需要客户端单独去请求了,而不是跟商品基础信息一起同步返回。具体要看业务哦!
中心化
1、在实际业务中,很多提供的微服务接口,是需要身份认证的;
2、还有就是对外部的流量控制,防止流量过大,把整体系统搞崩溃;需要预估系统能够支撑的流量。
3、访问日志,监控分析
以上的需求,每个微服务都需要,且跟具体业务无关;这种类似的需求,交给网关处理,再适合不过了。由网关统一处理,因为网关是入口,统一处理更加可控,简洁。让微服务接口做业务相关的事情上面。这就是中心化的思想,集中处理。
负载均衡
在实际的部署应用中,当应用系统面临大量访问,负载过高时,通常我们会增加服务数量来进行横向扩展,使用集群来提高系统的处理能力。此时多个服务通过某种负载算法分摊了系统的压力,我们将这种多节点分摊压力的行为称为负载均衡。
网关为入口,由网关与微服务进行交互,所以网关必须要实现负载均衡的功能;网关会获取微服务注册中心里面的服务连接地址,再配合一些算法选择其中一个服务地址,进行处理业务。这个属于客户端侧的负载均衡,由调用方去实现负载均衡逻辑。
主流注册中心Eureka、Zookeeper等;
负载均衡的算法一般有随机,轮询,权重,负载等。
服务熔断
在现实生产环境中,会经常遇到某个服务突然停止了工作,然后返回了大量的错误。这个时间API网关可以实现断路器(circuit breakers)的能力,也就是说超过了指定的阈值,API网关就会停止发送请求到那些失败的服务。
这样就给了我们时间来分析日志,实现修复以及发包更新。通常当你发现一个模块下的某个实例失败后,这时候这个模块依然还会接收流量,然后这个有问题的模块还调用了其他的模块,这样就会发生级联故障,或者叫雪崩。
断路器通过简单的断开流量的方式,这样就不会有新的请求到达那些有问题的实例,这时候我们就有相对充分的时间来修复和解决问题。
最后
面试是跳槽涨薪最直接有效的方式,马上金九银十来了,各位做好面试造飞机,工作拧螺丝的准备了吗?
掌握了这些知识点,面试时在候选人中又可以夺目不少,暴击9999点。机会都是留给有准备的人,只有充足的准备,才可能让自己可以在候选人中脱颖而出。
如果你需要这份完整版的面试笔记,只需你多多支持我这篇文章。
——对文章进行点赞+评论,关注我,然后再点击这里免费领取
取](https://gitee.com/vip204888/java-p7)**
[外链图片转存中…(img-0oMoRFMI-1628064425176)]