微服務API通過ip可訪問，域名不可訪問問題分析
摘要
經常會有同學遇到api通過ip可以訪問，但是通過域名卻不可以訪問。本篇文章總結了造成這種情況可能的原因。
因為與具體技術的選型、規則配置有關，所以沒有深入討論，只是列出可能性，僅供參考。
分析
問題
通過域名訪問不到的請求表現的現象有
- 介面返回404
- 一個錯誤頁面
- 提示method type不支援
- 提示介面缺乏必要的引數
這些都是介面訪問不到，2是配置了錯誤頁面;3,4則發出的POST/PUT 請求，但是請求了GET方法
概覽
通過域名訪問，在整個後端的訪問路徑如下圖，大致分四個部分，瀏覽器、負載均衡層、閘道器層、服務層。
域名解析這裡忽略不討論了。
出現ip可以訪問，但是域名不可訪問，4層都有可能導致這個問題。
微服務層
- 配置了介面訪問許可權
在微服務口中，單獨限制了這個介面的訪問許可權，導致該介面沒有註冊到註冊中心，這個可以通過檢視程式碼，或者檢視註冊中心註冊列表找出問題。
- 該介面的api prefix不符合該服務的規則
閘道器在根據api uri路由到某個具體服務時，為了提高檢索效率，有些定義了路由規則，不同服務以不同的prefix來區分。這樣服務裡面的某個api prefix不符合該服務定義的字首規則，則匹配不上
（當然一般的閘道器路由會做降級，字首不符，就降級為遍歷）
這個可以通過訪問閘道器的ip/uri來找出問題。
閘道器層
- 路由演算法有問題
- 沒有訂閱微服務
不是所有的微服務都需要對外暴露，對於中臺類/或者其他一些內部服務是不對外暴露的。這些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/1190000016828