フロントエンド分離アーキテクチャでは、フロントエンドは次の2つの方法でバックエンドを呼び出します。
Ip +ポート
リクエストはすべてブラウザから送信され、ブラウザから送信されたリクエストにはすべてアクセスできる必要があるため、バックエンドサービスはip + portメソッドを介して公開する必要があります。
ip + portモードを使用するデメリット:
- IPを変更した後にサービスが使用できなくなるのを防ぐために、バックエンドサービスのIPをdnsに追加する必要があります
- ドメイン名を割り当てない場合は、IPを公開する必要があります。これは、セキュリティリスクが高くなります。
- 悪意のあるアクセスによりサービスがクラッシュする可能性があります。もちろん、内部ネットワークサービスの場合、通常は複数のファイアウォールレイヤーで区切られています。これは少し根拠がなく、ネットワークセキュリティは考慮されていません。これはあまり良くありません。
リバースプロキシ
- クラウドプラットフォームのマイクロサービスの機能:
- クラウドプラットフォームのマイクロサービスとして、バックエンドはマイクロサービスをユーザーに公開する必要はなく、クラスター内で公開する必要があるだけです。したがって、バックエンドマイクロサービスはクラスター内でのみ到達可能である必要があります。
- マイクロサービスのIPはいつでも変更される可能性があり、運用および保守担当者は知りません。k8sを例にとると、マイクロサービスはポッドにデプロイされます。一方のポッドがハングすると、もう一方のポッドがすぐに再起動します。このとき、IPが変更される可能性があります。フロントエンドがバックエンドの呼び出し時にip + portを使用する場合、404になります。
以上のことから、リバースプロキシの方が良い方法ですが、その実装方法を詳しく説明しますが、実際は主にポートを把握することです。ポートが表示されたら対応に注意してください。
- フロントエンドリクエストは相対パスのみを書き込みます。これは、最終的にnginxによってバックエンドサーバーに転送されるためです。ページ表示と呼び出しバックエンドを分離するために、バックエンドの統合呼び出しはapisで始まり、nginxは/ apisで始まるリクエストをバックに転送します。終わり。
export function asyncGetAllDeps() {
return function(dispatch){
//dispatch
// API
return fetch('/apis/getAllDeps',{
method: 'get',
headers: {
'Access-Control-Allow-Origin': 'assessment.frontend'
}
}).then(function(res){
return res.json();
}).then(function(data){
if(data !== undefined || data !== []){
data.forEach((item)=> {
item.key = item.DEPID;
});
dispatch(setallDepList(data));
}
}).catch((error) => {
console.log(error);
});
};
}
- 上記のフロントエンドコードをnginxにデプロイし、nginxイメージをプルする必要があります。dockerfileは次のとおり
です。コンテナが開く必要のあるポートは80であることに注意してください。
FROM nginx:1.17.10
COPY build/ /usr/share/nginx/html/
EXPOSE 80
- フロントエンドyamlファイルをデプロイします。ここで、コンテナーのポートを80として指定する必要があります。これは、上記のdockerfileに記述されているポート番号と一致している必要があります。
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
- nginxのリバースプロキシを構成するリバースプロキシ
を実装するための構成コードは次のとおりです。
location ^~/apis { # 自定义nginx接口前缀
rewrite ^/apis/(.*)$ /$1 break; # 监听所有/apis前缀,是则转发后台api接口地址
include uwsgi_params;
proxy_pass http://backend:8080; # 后台api接口地址 这个修改
}
location命令は、/ apisで始まる要求と一致します。一致が成功すると、rewrite命令を使用してパスが書き換えられ、プレフィックス/ apisが削除されるため、バックエンドでインターフェイスアドレスを変更する必要はありません。フロントエンドは、リクエスト時にプレフィックス/ apisを追加します。nginxがバックエンドに転送する必要のあるリクエストと一致すると、プレフィックス/ apisが削除されます。完璧です。
proxy_passを使用してリバースプロキシを実装し、リクエストをhttp:// backend:8080に転送します。ここに!!!注意!!!backendはバックエンドのサービス名です(k8sはサービス名でアクセスされます:port、その他は明確ではありません)、8080はバックエンドサービスによって公開されるポートです。
ここに!!!展開中、イメージをプルするときに外界に公開されるポートはすべて80であるため、httpサーバーによって監視されるポートは80である必要があります。!
server {
listen 80;
}
nginxのフルバージョンは次のように構成されています。LeiFengと呼んでください。
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 1024;
}
http {
server_tokens off;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
server {
listen 80;# default_server;
server_name assessment.frontend.com;
root /usr/share/nginx/html;
location ^~/apis { # 自定义nginx接口前缀
rewrite ^/apis/(.*)$ /$1 break; # 监听所有/apis前缀,是则转发后台api接口地址
include uwsgi_params;
proxy_pass http://backend:8080; # 后台api接口地址 这个修改
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
}
- バックエンドマイクロサービスの展開
ここでは、8080にアクセスするようにnginxで構成したため、ポート8080を外部に公開する必要があります。!
spec:
containers:
- image: 后端微服务的镜像地址
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
tcpSocket:
port: 8080
timeoutSeconds: 1
name: backend
ports:
- containerPort: 8080
protocol: TCP
この時点で、クラウドプラットフォームのマイクロサービスのフロントエンドとバックエンドの呼び出しは完了しています。とても良いですか?ファンになってください。