セキュリティ ゲートウェイ、2 つの UI サーバー、REST API サーバーの 4 つのサーバー タイプにまたがる Spring Cloud マイクロ サービス アプリケーションがあります。これらはそれぞれ、実稼働環境の独自の VM で実行されます。REST サーバーの 4 つのサーバー インスタンスと、他の各サーバーの 2 つのインスタンスです。
このシステムは、約 30,000 人のユーザーにサービスを提供する予定です。
サービス検出は Eureka によって提供されます。フェイルオーバー用に 2 つの Eureka サーバーがあります。
共有 HTTP セッションは、参加サーバーで @EnableRedisHttpSession アノテーションを使用して、Spring Session および Spring Data Redis によって提供されます。
Redis 用に 3 つの VM をセットアップすることにしました (「例 2: 3 つのボックスを使用した基本的なセットアップ」の URL: http://redis.io/topics/sentinel )。
各 VM は Redis サーバーと Redis Sentinel プロセスを実行します (Redis サーバーの 1 つがマスターになり、2 つのインスタンスがスレーブになります)。
これはすべて、開発マシンとシステム テスト マシンでうまく機能し、ほとんどの場合、すべてのプロセスが同じサーバーで実行されます。
私は現在、複数の VM を使用して、本番環境に似た環境でパフォーマンス テストを実行する方向に進んでいます。本番環境で同様の Spring Cloud セットアップを既に行っている開発者からのフィードバックと推奨事項をいくつかお願いします。
- どのようなエッジ ケースを探す必要がありますか?
- 推奨される構成設定はありますか? 私のセットアップを以下に示します。
- テスト環境では問題なく動作するが、本番環境では深刻な問題になる構成設定はありますか?
- 私の特定のシナリオでは、セッション情報を保存するためだけに存在するため、Redis から古いデータを消去するソリューションも必要です。何らかの理由でセッションの有効期限が切れたときにスプリングがセッション データをクリーンアップしない場合 (たとえば、サーバーが突然強制終了された場合)、本当に古いデータをクリーンアップしたいと思います。Redis の LRU/キャッシング メカニズムについて読みましたが、データ サイズが一定に達した場合にのみ、時間に関して何らかの保証がないようです。
これが私のマスター Redis サーバーの構成です。スレーブはほとんど同じですが、ポートが異なり、マスターのスレーブであることを示しています。
daemonize no
port 6379
dbfilename "dump6379.rdb"
dir "/Users/odedia/Work/Redis/6379"
pidfile "/Users/odedia/Work/Redis/redis6379.pid"
#logfile "/Users/odedia/Work/Redis/redis6379.log"
tcp-backlog 511
timeout 0
tcp-keepalive 60
loglevel notice
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
slave-serve-stale-data yes
slave-read-only no
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events "gxE"
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
Redis センチネルの構成は次のとおりです。
port 5000
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 5000
sentinel config-epoch mymaster 59
Eureka サーバーの application.yml は次のとおりです。
server:
port: 1111
eureka:
instance:
hostname: localhost
client:
serviceUrl:
defaultZone: https://${eureka.instance.hostname}:${server.port}/eureka/
registerWithEureka: false #Dont register yourself with yourself...
fetchRegistry: false
server:
waitTimeInMsWhenSyncEmpty: 0
spring:
application:
name: eureka
Zuul ベースのルーティングを担当するゲートウェイ サーバーの application.yml は次のとおりです。
# Spring properties
spring:
application:
name: gateway-server # Service registers under this name
redis:
sentinel:
master: mymaster
nodes: 127.0.0.1:5000,127.0.0.1:5001,127.0.0.1:5002
server:
port: 8080
security:
sessions: ALWAYS
zuul:
retryable: true #Always retry before failing
routes:
ui1-server: /ui1/**
ui2-server: /ui2/**
api-resource-server: /rest/**
# Discovery Server Access
eureka:
client:
serviceUrl:
defaultZone: https://localhost:1111/eureka/
instance:
hostname: localhost
metadataMap:
instanceId: ${spring.application.name}:${spring.application.instance_id:${random.value}}
hystrix:
command:
default:
execution:
isolation:
strategy: THREAD
thread:
timeoutInMilliseconds: 40000 #Timeout after this time in milliseconds
ribbon:
ConnectTimeout: 5000 #try to connect to the endpoint for 5 seconds.
ReadTimeout: 50000 #try to get a response after successfull connection for 5 seconds
# Max number of retries on the same server (excluding the first try)
maxAutoRetries: 1
# Max number of next servers to retry (excluding the first server)
MaxAutoRetriesNextServer: 2