微服務API通過ip可訪問,域名不可訪問問題分析

摘要

經常會有同學遇到api通過ip可以訪問,但是通過域名卻不可以訪問。本篇文章總結了造成這種情況可能的原因。
因爲與具體技術的選型、規則配置有關,所以沒有深入討論,只是列出可能性,僅供參考。

分析

問題

通過域名訪問不到的請求表現的現象有

  1. 接口返回404
  2. 一個錯誤頁面
  3. 提示method type不支持
  4. 提示接口缺乏必要的參數

這些都是接口訪問不到,2是配置了錯誤頁面;3,4則發出的POST/PUT 請求,但是請求了GET方法

概覽

通過域名訪問,在整個後端的訪問路徑如下圖,大致分四個部分,瀏覽器、負載均衡層、網關層、服務層。
域名解析這裏忽略不討論了。

在這裏插入圖片描述

出現ip可以訪問,但是域名不可訪問,4層都有可能導致這個問題。

微服務層

  1. 配置了接口訪問權限

在微服務口中,單獨限制了這個接口的訪問權限,導致該接口沒有註冊到註冊中心,這個可以通過查看代碼,或者查看註冊中心註冊列表找出問題。

  1. 該接口的api prefix不符合該服務的規則

網關在根據api uri路由到某個具體服務時,爲了提高檢索效率,有些定義了路由規則,不同服務以不同的prefix來區分。這樣服務裏面的某個api prefix不符合該服務定義的前綴規則,則匹配不上
(當然一般的網關路由會做降級,前綴不符,就降級爲遍歷)

這個可以通過訪問網關的ip/uri來找出問題。

網關層

  1. 路由算法有問題
  2. 沒有訂閱微服務
    不是所有的微服務都需要對外暴露,對於中臺類/或者其他一些內部服務是不對外暴露的。這些api是不可以直接通過域名訪問的。

這些都可以通過訪問網關的依賴,或者網關ip/uri來找出問題。

Nginx

Nginx裏可以配置各種redirect規則,過濾規則。當通過網關ip可以訪問api時,那多半是nginx的問題。可以檢查nginx的配置問題,來定位問題。

瀏覽器重定向,將POST/PUT請求改寫成了GET請求

比如網站從http升級到https,某個uri redirect了。當我們在瀏覽器中鍵入以www爲開頭的網址時,網頁並不會自動跳轉爲HTTPS網站,因爲瀏覽器默認打開HTTP網站,基於此,我們就需要對HTTP的訪問在服務器端做301、302或307重定向,使之跳轉到HTTPS網站。當使用了301,302後,瀏覽器會使用GET方式訪問在Location中規定的URI,而無視原先請求的方法。

關注公衆號【方丈的寺院】,第一時間收到文章的更新,與方丈一起開始技術修行之路
在這裏插入圖片描述

參考

https://zhuanlan.zhihu.com/p/27480845

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

https://segmentfault.com/a/1190000016828036

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章