前後端分離架構下，前端呼叫後端的方式有以下兩種：
ip+埠
通過ip+埠的方式需要暴露後端服務，因為請求都是從瀏覽器發出的，需要讓任意乙個從瀏覽器發出的請求都可以訪問。
採用ip+埠方式的弊端：
需要將後端服務的ip加入dns，以免換了ip之後服務不可用
如果不分配網域名稱的話，需要向外暴露ip，安全風險較高
可能被惡意訪問造成服務崩潰，當然如果是內網的服務，一般隔了好幾層防火牆，這個有點杞人憂天，網路安全先不考慮了，這個不太擅長。
反向**
雲平台中微服務的特點：
後端作為雲平台的微服務，不需要面向使用者暴露微服務，只需要在集群內部暴露，因此後端微服務只要集群內可達即可。
微服務的ip隨時可能發生變化，而運維人員不知道。以k8s為例，微服務都部署在pod中，如果乙個pod掛了，就會立刻重啟另乙個，這時ip可能發生改變，如果前端在呼叫後端的時候採用ip+埠的方式，就會404
基於上述考慮，反向**是乙個比較好的方式，下面詳細描述如何實現，其實主要是要搞清楚埠，請各位看官看到埠的時候注意對應。
export
function
asyncgetalldeps()
}).then
(function
(res)).
then
(function
(data));
dispatch
(setalldeplist
(data));
}}).
catch
((error)
=>);
};}
from nginx:1.17.10
copy build/
/usr/share/nginx/html/
expose 80
spec
:containers:-
image
: 前端打包成的映象的位址
imagepullpolicy
: ifnotpresent
livenessprobe
:failurethreshold:3
initialdelayseconds:10
periodseconds:10
successthreshold:1
tcpsocket
:port:80
timeoutseconds:1
name
: frontend
ports:-
containerport:80
protocol
: tcp
location ^~/apis使用proxy_pass實現反向**，將請求**到http://backend:8080。這裡！！！注意了！！！backend是後端的服務名(k8s是用服務名:埠訪問的，其他不清楚)，8080是後端服務暴露的埠。
這裡！！！因為在部署的時候，拉取映象的時候對外暴露的埠都是80，因此http的server監聽的埠應該是80！！
server: 後端微服務的映象位址
imagepullpolicy
: ifnotpresent
livenessprobe
:failurethreshold:3
initialdelayseconds:10
periodseconds:10
successthreshold:1
tcpsocket
:port
:8080
timeoutseconds:1
name
: backend
ports:-
containerport
:8080
protocol
: tcp至此，雲平台中微服務的前後端呼叫已經完成了，是不是非常優秀，請各位看官做我的粉絲。
面向微服務前後端分離的跨域問題
我主要是通過cors解決的，它會在正式通訊之前，增加一次 http 查詢請求，稱為 預檢 請求,該請求是 option 方法的，通過該請求來知道服務端是否允許跨域請求。下面是我解決問題時檢視的資料 同源策略是一種約定，它是瀏覽器最核心也最基本的安全功能，如果缺少了同源策略，瀏覽器很容易受到 xss ...
微服務構建易擴充套件雲平台
1 為什麼要構建微服務 所有架構方案的提出都是根據應用場景進行優化的，想一下5年前，當時springmvc大行其道，使用ssm 構建應用基本上是當時開發界的標準。當時的資料量還沒有進行服務拆分，所有服務構建在乙個單體應 用中，所有服務間呼叫是通過http請求實現的。但是這種方式構建的應用有幾個最主要...
微服務 見 呼叫請求頭傳遞 微服務平台之灰度發布
灰度發布是指在應用的新 舊版本間平滑過渡的一種發布方式。根據特定的規則，挑選一部分使用者訪問灰度版本的服務，並逐步擴大範圍，最終把所有使用者訪問遷移到新的版本上來。灰度發布時，主要涉及設定流控規則和部署新版本這兩個動作，本次主要是介紹在eos8微服務平台裡灰度發布的流量控制。一 灰度發布介紹 二 灰...