如何解決微服務中用戶token處理到的問題

這篇文章將為大家詳細講解有關如何解決微服務中用戶token處理到的問題，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

關于用戶token處理到的坑

當采用前后臺完全分離，以微服務架構的搭建時。在搭建微服務過程中，由于每個服務都是獨立的應用，這樣就會造成一個統一用戶的問題。

當用戶從這個用戶管理系統中登錄后，在其他系統的如何判斷用戶是否已經登錄的問題。

目前常用的有以下幾種方案：

• 1、session 、redis共享處理

• 2、Header存儲token機制

• 3、用戶每個接口加入token參數

其中3方案最簡單，但是要求每個調用接口都需要傳入token參數。我的前期采用的是這種方案。整體測試及使用結果還不錯。

方案2 是要求在進行請求時將token參數加入header中，由于涉及了自定義header參數，因此如果進行跨域訪問時，會過不了Html預檢功能。如果要處理這種預檢，需要先進行options請求的處理。因此我在前臺進行options請求,先將options請求返回200這樣才能保證請求的繼續執行。如果采用同一個域名的情況下，可以避免這種情況。

方案3 在要求我們加入一個spring-session-data-redis的依賴。然后啟動redishttpsession功能。但是我在使用過程中遇到不少問題。但是當多個項目啟動這個功能時，會出現session沖突問題，造成每次請求的sessionid發生變化。

微服務服務間調用傳遞token

微服務間的調用通常我們使用FeignClient來實現。那么如何在調用的時候傳遞token來保證服務間調用的安全校驗呢？

沒錯，我們可以配置一個攔截器。該攔截器的功能就是在請求發出去前在header中添加token。

代碼如下

@Component
public class FeignHeaderInterceptor implements RequestInterceptor {
    @Override
    public void apply(RequestTemplate template) {
        template.header(HttpHeaders.AUTHORIZATION, "token");
    }
}

RequestInterceptor是feign提供的接口

該接口只有一個方法：

public interface RequestInterceptor {
  void apply(RequestTemplate template);
}

這樣被調用的服務就可以在header中拿到token來做校驗了。

關于“如何解決微服務中用戶token處理到的問題”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。