概要概要
SpringCloudAlibabaシリーズの記事を更新してから久しぶりです。本日は最新の卒業バージョンにアップグレードします。そして、元のコンテナ化されたデプロイコンポーネントのseata、nacos、sentinelを引き出し、それらを個別にデプロイして、将来のk8sデプロイメントの準備をします。
公式の推奨バージョンは次のとおりです。
この記事では、主にアップグレードプロセス中に発生するいくつかの問題について説明し、それらを解決するためのプロセスと方法について説明します。詳細な使用法を知りたい場合は、前の記事をお読みください。
メジャーバージョンのアップグレード
<properties>
...
<spring-boot.version>2.2.5.RELEASE</spring-boot.version>
<alibaba-cloud.version>2.2.1.RELEASE</alibaba-cloud.version>
<springcloud.version>Hoxton.SR3</springcloud.version>
...
</properties>
親モジュールのメインpomファイルに対応するコンポーネントバージョンを変更し、変更が完了したらjarパッケージを再度ダウンロードします。
nacos 1.2
nacosのアップグレードは比較的簡単で、次の手順に従って2つの手順で完了することができます。
- nacosデータベースを初期化します
nacos-mysql.sql
- nacos構成ファイルを変更し
application.properties
、データベース関連の構成ノートをリリースして、独自のデータベース構成に変更します
シート1.2
Seataの初期化プロセスについては前のチュートリアルで詳しく説明しましたが、新バージョンと旧バージョンの違いはかなり大きいので、ここで言及しましょう。以下の手順で完了できます。
-
ビジネスシステムにデータテーブルundo_logを作成し、次のアドレスからSQLファイルを取得します。
https://github.com/seata/seata/blob/develop/script/client/at/db/mysql.sql
-
mysqlデータベースにseataという名前のライブラリを作成し、初期化します。SQLファイルは次のアドレスから取得されます。
https://github.com/seata/seata/blob/develop/script/server/db/mysql.sql
-
新しいバージョンのseataはartifactIdを変更したため、seataの依存関係を変更する必要があります
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-seata</artifactId>
</dependency>
SpringCloud Alibaba 2.2.1 RELEASE
SEATA 1.1のバージョンが使用されます。SEATA1.2の機能を体験したい場合は、これに基づいてseataの依存関係を削除し、バージョン1.2を手動で追加できます。
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-seata</artifactId>
<exclusions>
<exclusion>
<artifactId>seata-spring-boot-starter</artifactId>
<groupId>io.seata</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-spring-boot-starter</artifactId>
<version>1.2.0</version>
</dependency>
- Seataは、クライアント
がregistry.conf
Seata構成ファイルとして使用するクライアントの構成を変更します。次に、移動したapplication.ymlまたは配布センターを構成する必要があります。公式Webサイトを参照できる特定の構成ファイルですhttps://github.com/seata/seata/blob/develop/script/client/spring/application.yml
。私の構成は次のとおりです。
seata:
enabled: true
application-id: ${
spring.application.name}
tx-service-group: account_service_group
enable-auto-data-source-proxy: true
config:
type: nacos
nacos:
namespace:
serverAddr: 10.0.23.48:8848
group: SEATA_GROUP
userName: "nacos"
password: "nacos"
registry:
type: nacos
nacos:
application: seata-server
server-addr: 10.0.23.48:8848
namespace:
userName: "nacos"
password: "nacos"
他のモジュールは自分で変更できます。
- Seataの構成をnacosにプッシュします。これがdbモードです。操作手順については、公式の手順を参照してください:https://github.com/seata/seata/tree/develop/script/config-center
service.vgroupMapping.account_service_group=default
service.vgroupMapping.product_service_group=default
service.vgroupMapping.order_service_group=default
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://10.0.23.48:3306/seata?useUnicode=true
store.db.user=root
store.db.password=xxxxxx
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000
変更が完了したら、gitでshellコマンドをsh nacos-config.sh -h 10.0.23.48 -p 8848 -g SEATA_GROUP -u nacos -w nacos
実行し、実行が完了したら、構成ファイルをnacosにプッシュします。
- Seataサーバーの構成
registry.conf
を変更し、完了後にSeataサーバーを起動します
registry {
type = "nacos"
nacos {
application = "seata-server"
serverAddr = "10.0.23.48:8848"
namespace = ""
cluster = "default"
username = "nacos"
password = "nacos"
}
}
config {
type = "nacos"
nacos {
serverAddr = "10.0.23.48:8848"
namespace = ""
group = "SEATA_GROUP"
username = ""
password = ""
}
}
- 上記のseataの設定手順が完了すると、アップグレードが完了します。ご自身でテストしてください。
歩哨1.7
センチネルを使用すると、多くの学生がセンチネルコンソールにAPI管理メニューが表示されず、nacosの電流制限設定を読み取れない状況に遭遇します。ゲートウェイモジュールの起動時に起動パラメータを追加し-Dcsp.sentinel.app.type=1
、センチネルコンソールを再起動できます。表示。
前回の記事で、時間の流れと統合された古いバージョンのSentinelゲートウェイについて説明しましたが、その理由は、センチネルがアカウントサービス構成ではなくゲートウェイIDに到達するためですが、CompositeDiscoveryClient_
プレフィックスを追加します、元の説明は次のとおりです。
この問題は新しいバージョンでは発生しなくなったため、ゲートウェイの現在の制限設定ファイルのプレフィックスを削除できます。削除された構成は次のとおりです。
auth-service
postmanを使用してauth-serviceからaccess_tokenを取得するときに、次のエラーが発生した場合org.springframework.security.core.authority.SimpleGrantedAuthority; local class incompatible: stream classdesc serialVersionUID = 510, local class serialVersionUID = 520
この問題の理由は、元のデータベースにアカウントに対応するaccess_tokenが既に格納されているが、Spring Securityはバージョン間のシリアル化をサポートしておらず、解決策は非常に簡単であるためです。ユーザーに対応するaccess_tokenを削除して再生成するだけです。
SpringCloudゲートウェイ
統合テストにPostManを使用すると、インターフェイス呼び出しで常に404 NotFoundエラーが表示されることがわかりました。
ソースコードファイルorg.springframework.cloud.gateway.filter.NettyRoutingFilter
のデバッグを通じて、新しいバージョンのSpring Cloud Gatewayは、転送時に構成したプレフィックスを保持していることがわかりました。
上の図に示すように、転送後にプレフィックスが追加され、対応するリクエストパスが見つからないため、404例外が発生します。
この問題を解決するには、転送する前にこのプレフィックスを削除する必要があります。SprtingCloudGatewayには、StripPrefix GatewayFilter
この問題を解決するために使用できるフィルターが用意されています。
StripPrefix GatewayFilterファクトリは、1つのパラメータpartsを取ります。パーツパラメータは、リクエストをダウンストリームに送信する前にリクエストから削除するパス内のパーツの数を示します。
詳細については、https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.2.RELEASE/reference/html/#the-stripprefix-gatewayfilter-factoryを参照してください。
異常の原因が判明し、解決策が見つかったので、非常に簡単です。ゲートウェイモジュールでマッピングを設定するときに、デフォルトのフィルタを追加するだけで済みます。
spring:
cloud:
gateway:
discovery:
locator:
enabled: true
routes:
- id: account-service
uri: lb://account-service
predicates:
- Path=/account-service/**
...
# 解决前缀转发问题
default-filters:
- StripPrefix=1
上記の手順を実行すると、SpringCloud alibabaのアップグレードが完了し、アップグレードプロセス中にさまざまな問題が発生します。問題が発生した場合は、焦らないでください。コードデバッグを使用して問題を特定します。問題を特定したら、検索エンジンを上手に活用してください。解決できます。