柚子快報邀請碼778899分享：Java面試——中間件

http://yzkb.51969.com/

OpenFeign

1、openFeign是一個HTTP客戶端，它融合了springmvc的注解，使之可以用REST風格的映射來請求轉發(fā)。 2、可以把openFegin理解為是controller層或是service層?？梢匀〈鷖pringmvc控制層作為請求映射，亦或是作為service層處理邏輯，只不過這里，openFeign只是做一個請求轉發(fā)的邏輯操作。 3、openFeign整合了hystrix做熔斷處理，同時，可以和ribbon客戶端負載均衡、Eureka注冊中心配合使用，實現負載均衡的客戶端。 4、openFeign有一個很重要的功能：fallback，其實它是hystrix的特性

Feign

Feign集成了Ribbon、RestTemplate實現了負載均衡的執(zhí)行Http調用，只不過對原有的方式（Ribbon+RestTemplate）進行了封裝，開發(fā)者不必手動使用RestTemplate調服務，而是定義一個接口，在這個接口中標注一個注解即可完成服務調用，這樣更加符合面向接口編程的宗旨，簡化了開發(fā)。

OpenFeign的工作原理

OpenFeign是springcloud在Feign的基礎上支持了SpringMVC的注解，如@RequestMapping等等。OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通過動態(tài)代理的方式產生實現類，實現類中做負載均衡并調用其他服務。

OpenFeign遠程調用的底層原理 OpenFeign是一個聲明式的Web服務客戶端，它使得編寫Web服務客戶端變得更加容易。它的底層原理主要基于幾個關鍵組件的協作：

「核心組件」

「Feign Client」 在OpenFeign中，你可以通過創(chuàng)建一個接口并使用@FeignClient注解來定義一個Feign客戶端。這個接口定義了服務的請求綁定，參數和回調處理。

「Contract」 Contract定義了如何將方法調用轉換為HTTP請求。默認情況下，Feign使用自己的注解，但是也可以配置為使用JAX-RS或Spring MVC注解。

「Encoder & Decoder」 「Encoder」: 負責將Java對象編碼成HTTP請求體。 「Decoder」: 負責將HTTP響應體解碼成Java對象。

「Client」 Client是一個用于發(fā)送請求的組件。Feign有多個Client實現，如默認的Java HttpURLConnection、Apache HttpClient和OkHttp。

「Logger」 Feign提供了日志機制來記錄HTTP請求和響應的詳細信息。

OpenFeign 工作流程

「接口定義」: 開發(fā)者定義一個接口，并使用@FeignClient注解來標記它需要調用的遠程服務?！竸討B(tài)代理」: 當應用啟動時，Spring Cloud Feign會為這個接口生成一個動態(tài)代理?！笜嬙煺埱蟆? 當調用接口的方法時，Feign通過Contract組件將方法調用轉換為HTTP請求?！妇幋a請求」: Encoder組件將方法參數等信息編碼成請求體。「發(fā)送請求」: Client組件負責發(fā)送實際的HTTP請求到服務端。「處理響應」: 服務端處理請求并返回響應，Decoder組件將響應體解碼成Java對象?！府惓Ｌ幚怼? 如果在調用過程中發(fā)生錯誤，Feign會使用ErrorDecoder組件來處理異常?！附Y果返回」: 最終，調用結果會返回給方法的調用者?！肛撦d均衡」OpenFeign與Spring Cloud LoadBalancer或Netflix Ribbon集成，可以實現客戶端負載均衡。當有多個實例提供相同服務時，Feign會根據負載均衡策略選擇一個實例來發(fā)送請求。

「總結」 OpenFeign的底層原理是通過動態(tài)代理技術，將接口的方法調用轉換為HTTP請求，并通過Client組件發(fā)送到遠程服務。它通過Encoder和Decoder處理請求和響應的編碼和解碼，并且可以與負載均衡器集成以實現服務的高可用性。

OpenFeign如何使用

首先，調用以及被調用的微服務雙方都應該被注冊到注冊中心。Spring Boot啟動APP上標注 @EnableFeignClients注解。編寫遠程調用接口并標注@FeignClient注解。（括號內添加所要調用的微服務名稱）接口中的方法為實際想要調用的服務的方法簽名，并使用@PostMapping注解映射為一個post類型的HTTP請求。

Feign是如何實現自動處理多個不同服務器上的服務的？

如果Feign調用服務沖突怎么辦？

超時如何處理

如果openFeign沒有設置對應得超時時間，那么將會采用Ribbon的默認超時時間，Ribbon的默認超時連接時間、讀超時時間都是是1秒。 設置openFeign的超時時間

default設置的是全局超時時間，對所有的openFeign接口服務都生效

feign:

client:

config:

## default 設置的全局超時時間，指定服務名稱可以設置單個服務的超時時間

default:

connectTimeout: 5000

readTimeout: 5000

給serviceC這個服務單獨配置一個超時時間，配置如下：

feign:

client:

config:

## default 設置的全局超時時間，指定服務名稱可以設置單個服務的超時時間

default:

connectTimeout: 5000

readTimeout: 5000

## 為serviceC這個服務單獨配置超時時間

serviceC:

connectTimeout: 30000

readTimeout: 30000

Feign和OpenFeign有什么區(qū)別？

FeignopenFiegnFeign是SpringCloud組件中一個輕量級RESTful的HTTP服務客戶端，Feign內置了Ribbon，用來做客戶端負載均衡，去調用服務注冊中心的服務。Feign的使用方式是：使用Feign的注解定義接口，調用這個接口，就可以調用服務注冊中心的服務。OpenFeign 是SpringCloud在Feign的基礎上支持了SpringMVC的注解，如@RequestMapping等。OpenFeign 的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通過動態(tài)代理的方式產生實現類，實現類中做負載均衡并調用其他服務。

OpenFeign 奪命連環(huán) 9問

Http和RPC有什么區(qū)別？

Http是一種基于文本傳輸的應用層協議，定義的是遠程通訊的規(guī)范；RPC是一種遠程過程調用協議，它允許一個網絡節(jié)點的程序調用另一個網絡節(jié)點的程序的函數或者方法就像調用本地函數。Http主要用于跨越互聯網傳輸數據，適用于面向網絡的通訊。 而RPC是用于實現跨機器或者進程之間的通訊，適合用于面向應用程序的通訊。

Dubbo和OpenFeign的區(qū)別

應用場景。Dubbo是一個基于RPC的分布式服務框架，它提供了服務注冊發(fā)現和遠程通訊。適用于高性能、高可靠性和復雜服務治理的場景。提供了負載均衡、超時處理和熔斷降級等功能。 OpenFeign是一個聲明式的客戶端，它簡化了基于Http的遠程通訊過程，適用于簡單的微服務場景，特別是當你的微服務使用Http通訊并且希望通過接口來定義客戶端調用的時候。它可以把Http請求轉化為Java接口方法的調用。

Dubbo

Dubbo的服務請求失敗怎么處理？

默認失敗重試機制，2次額外重試?？焖偈　伋霎惓Ｊ“踩呗?。吞掉異常。失敗恢復策略。記錄失敗，定時任務失敗轉發(fā)。

消息隊列

為什么使用消息隊列/應用場景

消息隊列的場景使用場景很多，主要是三個：解耦、異步、和削峰。

解耦

一個系統或者一個模塊，調用了多個系統，互相之間的調用很復雜，維護起來很麻煩。但是其實這個調用是不需要同步調用接口的，如果用MQ給他異步化解耦，也是可以的，這個時候可以考慮在自己的項目中，是不是可以運用這個MQ來進行系統的解耦。

通過一個MQ，發(fā)布和訂閱模型，Pub/Sub模型，系統A就和其它系統徹底解耦。

異步

系統A只需要發(fā)送消息到MQ中就直接返回了，然后其它系統各自在MQ中進行消費。用戶在執(zhí)行系統A的時候，就會感覺非常快就得到響應了。

削峰

削峰就是大量的請求過來，然后MQ將其消化掉了，然后通過其它系統從MQ中取消息，在逐步進行消費，保證系統的有序運行。一般高峰期不會持續(xù)太長，在一段時間后，就會被下游系統消化掉。

RocketMQ

如何保證消息的可靠性傳輸，要是消息丟失了怎么辦？

生產者、broker、消費者在哪些階段會發(fā)生消息丟失？ 生產階段：網絡故障 Broker存儲階段：異步刷盤失敗 消費者：消費消息失敗

生產者： 同步/異步

confirm機制重試機制 broker：異步刷盤成功后再返回ack 消費者：消費成功后再ack

RocketMQ的消息持久化機制

RocketMQ的消息持久化機制是指將消息存儲在磁盤上，以確保消息能夠可靠地存儲和檢索。 三個角色：CommitLog、ConsumeQueue和IndexFile

CommitLog：所有的消息都存儲在CommitLog文件中。 RocketMQ默認會將消息數據線存儲在內存的一個緩沖區(qū)中，每當緩沖區(qū)中積累了一定量的消息或者一定時間過后，就會將緩沖區(qū)中的消息批量寫入到磁盤上的CommitLog文件中。消息在寫入CommitLog文件后就可以被消費者消費了。 CommitLog文件大小固定1G，寫滿之后生成新的文件，并且采用的是順序寫的方式。ConsumeQueue：消息消費邏輯隊列，類似數據庫的索引文件 RocketMQ中每個主題下的每個消息隊列都會對應一個ConsumeQueue。ConsumeQueue存儲了消息的offset和該offset對應的消息在CommitLog文件中的位置，便于消費者快速定位并消費消息。 每個ConsumeQueue文件固定由30萬個固定大小20byte的數據塊組成；數據塊內容包括：msgPhyOffset（8byte，消息在CommitLog文件中的起始位置）+msgSize（4byte，消息在CommitLog文件中占用的長度）+msgTag（8byte，消息的tag的哈希值）。IndexFile：消息索引文件，主要存儲消息Key與offset的對應關系，提升消息檢索速度。 如果生產者在發(fā)送消息時設置了key，那么RocketMQ會將消息Key值和消息的物理偏移量（offset）存儲在IndexFile文件中，這樣消費者需要根據消息Key查詢消息時，就可以直接在IndexFile文件中查找對應的offset，然后通過ConsumeQueue文件快速定位并消費消息。 IndexFile文件大小固定400M，可以保存2000w個索引。

如何保證消息的順序性？

隊列有序

發(fā)送順序 消費順序 發(fā)送到同一個隊列中

內存隊列：同一個訂單的消息存儲到一個隊列中 再由消費線程消費

如何保證消息隊列的高可用？

高可用的，如果整個系統僅僅靠著一個 Broker 來維持的話，那么這個 Broker 的壓力會不會很大？ Nameserver提供Broker 管理 和 路由信息管理。使用多個 Broker 來保證 負載均衡 。

如何保證消息不被重復消費？如何保證消息消費時的冪等性？

業(yè)務端做冪等性 唯一ID

你說被重復消費的話能設立唯一ID，那么設立唯一ID是怎么做的？

消息積壓怎么解決

先修復Consumer的問題 將堆積的消息寫入到另外的主題中 用更多的機器部署Consumer，消費消息

XXL-JOB

路由策略

任務執(zhí)行失敗怎么解決？

如果有大數據量的任務同時都需要執(zhí)行，怎么解決？

場景題

手機掃碼登錄

web端發(fā)起生成二維碼請求，服務端返回二維碼id，web端根據二維碼id生成二維碼。web端定時輪詢服務端，查詢二維碼的掃描狀態(tài)，直到登錄成功。app端掃描二維碼獲取二維碼id，同時將app的token和二維碼發(fā)送到服務端。服務端將二維碼id和身份信息進行綁定并生成臨時token，之后將臨時token返回給app端。web端通過輪詢更新二維碼狀態(tài)為已掃描待確認狀態(tài)。app端攜帶臨時token發(fā)起確認登錄請求給服務端，服務端接收到請求后生成web端的token并將二維碼狀態(tài)更新為已確認。web端輪詢服務端二維碼狀態(tài)為已確認，服務端返回web端Token，web端將Token寫入登錄認證程序。

單點登錄

所謂單點登錄，就是只需登錄一次，便可訪問受信任的其他web應用。

B站崩了

weight為字符串"0"，lua腳本為若弱語言，會導致入參b為"0"，最終導致 a%b 為NaN，導致gcd(NaN, NaN)一直遞歸調用。

權限認證如何實現

上傳文件的安全性如何控制

項目中遇到了哪些棘手的問題

柚子快報邀請碼778899分享：Java面試——中間件

http://yzkb.51969.com/

參考鏈接