微服務API經過ip可訪問，域名不可訪問問題分析

摘要

常常會有同窗遇到api經過ip能夠訪問，可是經過域名卻不能夠訪問。本篇文章總結了形成這種狀況可能的緣由。 由於與具體技術的選型、規則配置有關，因此沒有深刻討論，只是列出可能性，僅供參考。

分析

問題

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

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

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

概覽

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

出現ip能夠訪問，可是域名不可訪問，4層都有可能致使這個問題。

微服務層

1. 配置了接口訪問權限

在微服務口中，單獨限制了這個接口的訪問權限，致使該接口沒有註冊到註冊中心，這個能夠經過查看代碼，或者查看註冊中心註冊列表找出問題。

2. 該接口的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的訪問在服務器端作30一、302或307重定向，使之跳轉到HTTPS網站。當使用了301，302後，瀏覽器會使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。

關注公衆號【方丈的寺院】，第一時間收到文章的更新，與方丈一塊兒開始技術修行之路

參考

zhuanlan.zhihu.com/p/27480845

www.w3.org/Protocols/r…

segmentfault.com/a/119000001…