文末
我将这三次阿里面试的题目全部分专题整理出来，并附带上详细的答案解析，生成了一份PDF文档
- 第一个要分享给大家的就是算法和数据结构
- 第二个就是数据库的高频知识点与性能优化
- 第三个则是并发编程（72个知识点学习）
- 最后一个是各大JAVA架构专题的面试点+解析+我的一些学习的书籍资料
还有更多的Redis、MySQL、JVM、Kafka、微服务、Spring全家桶等学习笔记这里就不一一列举出来
下图是客户端直连服务端模式。如果客户端想查看商品目录、订单、付款、库存这些服务，需要分别向这些服务的URL地址发送请求，然后客户端需要根据各服务端返回的响应完成聚合。
这种模式的缺点是明显的：
● 效率低下。客户端如果需要一个一键下单的功能，可能会涉及与多个微服务的接口交互，需要先查看商品库存、然后完成订单、最后付款。当客户端API接口粒度与后端API接口粒度不匹配时，浏览器需要来回多次访问请求，才能完成操作。
而浏览器与后端的微服务是通过WAN公网通信的，这样带来的一个问题就是带宽的浪费。
● 协议适配问题。在这个实例中我们发现，商品目录服务采用了gRPC通信协议，订单、付款服务采用了REST方式的HTTP。库存服务可能是一个遗留系统，采用了Dubbo框架，对外暴露的是Dubbo的RPC接口。在这种情况下，客户端如果想实现对不同接口的访问和对接，需要分别适配不同的技术栈，这本身也给前端工作带来了复杂性和非Web协议的不友好性。应用对外暴露的接口最好使用对Web友好、对防火墙友好的HTTP或者SOAP。应用内部之间的调用可以采用RPC这样的远程方法。
● 耦合性强。这种模式的另一个重大缺陷就是客户端与服务端存在接口层面的依赖，服务端的技术栈和接口变化都会对调用方产生极大的影响。随着时间的推移，这种依赖将束缚服务的调用方与提供方的迭代和演进，这给微服务架构下的服务划分及重构都带来了难度。
● 可替代性下降。例如，当前端调用方需要从浏览器迁移到移动端时，在浏览器上使用的对接技术（JavaScript对接gRPC、JavaScript对接Dubbo）将无法迁移到移动端。
正因为客户端直连服务端模式存在如此多的问题，所以在微服务架构中我们很少直接通过客户端与服务端通信。我们知道，在软件开发领域有一句名言：任何软件工程遇到的复杂问题都可以通过增加一个中间层来解决。下面我们看看微服务网关是如何解决这个问题的。
API网关模式
API网关模式通过在客户端和服务端之间增加一个中间层，使得客户端可以在一次请求中向多个服务获取数据，请求数的减少也会直接改善用户体验。如下图所示是API网关的使用图示。
首先，在使用API网关模式后，API网关对外屏蔽了服务的内部细节 ， 通 过 一 个 粗 粒 度 的 URL 可 以 实 现 一 键 下 单 服 务 ，如/product/order：xxx。客户端对于网关的请求没有来回多轮请求，你只需要对网关下发一个请求，网关对外屏蔽调用多个内部微服务请求的操作细节。当完成所有服务请求后，网关将各个响应进行聚合再返回给客户端，减少了外网请求和响应的交互次数，提高了交互的效率。由于能够对返回数据进行灵活处理，API网关减少了请求往返次数，从而简化了客户端的调用，也提高了访问服务的性能。
其次，假设每个系统使用的协议不同，那么系统之间的调用或者数据传输就存在协议转换，API网关可以通过内置的协议转换引擎实现多种协议的适配和转换，将对外的请求统一在HTTP-REST的协议规范下。常用的处理机制通过泛化调用的方式实现协议之间的转化。实际上就是将不同的协议转换成通用协议，然后将通用协议转化成本地系统能够识别的协议。这一转化工作通常由API网关完成。
第三，API网关实现客户端和服务端调用关系和部署环境的解耦，它向客户端隐藏了应用划分的微服务的部署版本。尽管微服务架构支持客户端直接与微服务交互，但当需要交互的微服务数量较多时，解耦就成为单体迈向微服务的必要工作。对于演进式架构，一个服务可能同时存在多个版本，对于A/B测试的场景，通过在URL中增加版本号（例如/path/version1/xxxx），或者在HTTP-Head中增加版本参数的方式，网关可以根据负载策略进行请求流量调节。客户端可以灵活地选择在不同场景使用不同版本的后端服务。
在微服务架构的网络拓扑中，微服务网关是一个处于应用程序和服务（提供REST API接口服务）之间的中间件系统，它可以用来完成管理授权、访问控制和流量限制等。REST API接口服务对调用者透明，隐藏在API网关后面的业务系统可以专注于创建和构建业务逻辑，服务调用者和服务提供者通过网关实现了解耦。
当然，API网关作为一个高可用组件，也增加了系统的复杂性和瓶颈点。我们很容易将微服务架构的API网关与SOA分布式架构的ESB系统联系起来。ESB作为服务总线也可以实现协议转换、解耦服务提供方和服务调用方，ESB还有重量级的服务编排等和业务逻辑关联比较强的特性，所以我们有必要说明一下API网关和ESB的区别。API网关和ESB的比较ESB 是 在 应 用 服 务 化 的 早 期 、 伴 随 着 EAI （ EnterpriseApplication Integration，企业应用集成）和SOA的理念而产生的。
它产生之初，是一个解决服务集成问题的服务中间件。同时，ESB所处理的服务是企业级的服务，服务粒度比较粗，它践行的是“共享”的架构模式。它的主要功能包括服务的调解和路由、消息增强、消息转换和协议转换，这是它必须具备的也是具有强大优势的地方，消息队列的处理、大数据的传输更是它的强项。总之，ESB是一种集中式的服务总线方式，可以以最小的代价把竖井式架构的应用改造成面向服务的架构。但由于通过ESB暴露出来的服务以紧耦合的方式固化在竖井应用中，其服务的柔性比较差，服务更改的代价比较大，导致ESB暴露的服务可能无法快速适应需求的变化。
API网关是伴随着微服务的广泛使用而产生和发展的，API网关是为了协调单体应用拆分后的众多微服务而产生的。
API网关主要完成微服务集成、服务路由、灰度发布、流量控制等非业务属性公共功能，对于业务属性比较强的服务调配编排、消息增强转换、业务规则管理等功能就不是微服务网关要考虑的事情，而是由微服务自行处理。而微服务应用下各个微服务之间的异步数据传输依旧需要单独的消息处理软件用发布订阅机制来进行处理，比如使用Kafka、RabbitMQ等消息中间件。
微服务的最初目的不是功能的重用，而是适合小团队自主开发，达到敏捷开发、敏捷发布的目的，以缩短软件上市周期，所以它强调独立。而API网关作为单一入口，通过请求适配整合后台微服务体系，面向各种客户端提供统一服务请求。
API网关的一个问题就是中心化的架构问题，我们需要考虑不同的前端、不同的业务团队，可能对网关存在隔离性的需求，在发布、部署、可用性方面，如何设计一个去中心化的网关系统也是实施微服务架构需要考虑的。
BFF网关模式
读者福利
分享一份自己整理好的Java面试手册，还有一些面试题pdf
不要停下自己学习的脚步
4f45ff00ff254613a03fab5e56a57acb)收录**
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
