以前はnginxからサービスへの負荷分散を実装していましたが、サービスが非常に多いため、作成するのが非常に面倒で、ゲートウェイによる統合処理がありません。
そのため、今回はnginxロードバランスがゲートウェイに実装され、ゲートウェイが各サービスにルーティングされます
1.関連する公式文書を参照してください
2つのステップがあることがわかります。1。アップストリームサーバーを構成します。2。プロキシを構成します。
2. nginxの全体的な構成ファイルで、アップストリームサーバーを構成します
ここでゲートウェイを構成します
[root@10 ~]# cd /
[root@10 /]# ls
bin boot dev -e etc home lib lib64 media mnt mydata opt proc root run sbin srv swapfile sys tmp usr -v vagrant var
[root@10 /]# cd mydata/nginx/conf/
[root@10 conf]# ls
conf.d fastcgi_params koi-utf koi-win mime.types modules nginx.conf scgi_params uwsgi_params win-utf
[root@10 conf]# vi nginx.conf
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
upstream gulimall{
server 192.168.56.1:88;
}
include /etc/nginx/conf.d/*.conf;
"nginx.conf" 35L, 694C written上記
の段落を追加しました
これはマシンのゲートウェイです。実際のプロジェクトには複数のゲートウェイがある場合があります。その時点で、複数のゲートウェイを構成すると、プロジェクトは終了します。
2.プロキシ構成
以前に構成したエージェントをコモディティサービスに追加します
上で構成されたアップストリームサーバーへのプロキシに変更します
[root@10 conf.d]# ls
default.conf gulimall.conf
[root@10 conf.d]# vi gulimall.conf
server {
listen 80;
server_name gulimall.com;
#charset koi8-r;
#access_log /var/log/nginx/log/host.access.log main;
location / {
proxy_pass http://gulimall;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
"gulimall.conf" 44L, 1061C written
[root@10 conf.d]# docker restart nginx
nginx
[root@10 conf.d]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
85e5c45a30da nginx:1.10 "nginx -g 'daemon of…" 4 weeks ago Up 5 seconds 0.0.0.0:80->80/tcp, 443/tcp nginx
6919debe7c73 elasticsearch:7.4.2 "/usr/local/bin/dock…" 4 weeks ago Up 2 hours 0.0.0.0:9200->9200/tcp, 0.0.0.0:9300->9300/tcp elasticsearch
fda06f05a0a0 kibana:7.4.2 "/usr/local/bin/dumb…" 4 weeks ago Up 2 hours 0.0.0.0:5601->5601/tcp kibana
69e789223ef0 redis "docker-entrypoint.s…" 4 weeks ago Up 2 hours 0.0.0.0:6379->6379/tcp redis
7c3556ac5cf1 mysql:5.7 "docker-entrypoint.s…" 4 weeks ago Up 2 hours 0.0.0.0:3306->3306/tcp, 33060/tcp mysql3.ホストルーティングを構成します
上記の構成後、引き続き404を報告します。理由は、ゲートウェイがルーティングルールを構成していないためです。
以前のアドレスルーティングとは異なり、ここではホストルーティングを構成する必要がありますhttps://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.1.3.RELEASE/single/spring-cloud-gateway .html
見られます
そのため、ゲートモジュールの構成に次のルートを追加します。この構成を下部に配置することを忘れないでください。具体的な理由については説明しません。再起動
- id: gulimall_host_route
uri: lb://gulimall-product
predicates:
- Host=**.gulimall.com4.ホスト名の損失の問題を解決します
再起動後、アクセス後も404のままです
特定のコントローラーでのリクエスト全体から、次のアクセス手順を通じて、nginxがゲートウェイに読み込まれ、ゲートウェイがルーティングを実装します
では、なぜgulimall.comまたは404にアクセスするのですか？その理由は、nginxがゲートウェイにプロキシすると、要求されたホスト情報が失われるためです。これは次のようなものです。
次に、前にgulimall.confで追加した構成に構成を追加する必要があります。最後に、引用符を忘れないでください。
proxy_set_header Host $host;
構成後にnginxを再起動します
もう一度アクセスすると、製品のホームページが表示されます
5.まとめ
まず、Windowsでマッピングを構成し、gulimall.comを仮想マシンにマッピングし、この時点で仮想マシンのデフォルトポート80にアクセスして監視します。この時点で、nginxはそれに応じてゲートウェイにプロキシします。構成に追加されますが、ゲートウェイにプロキシすると失われます。ホスト名ヘッダーなので、構成を追加する必要があります。ゲートウェイは、ホストがgulimall.comのように見えます。ルーティングに構成があるため、直接製品ページのホームページにルーティングします。
これまでに以下を達成しました
