パブリケーションとそのチェックの自動化の実践
5628 ワード
ここにはDubbo登録センターのリリース中の自動化の改善点を記録します.実践は通用して、あなたにいくつか参考と啓発を与えることができることを望みます.
Dubbo登録センターはウェブサイト全体のサービス情報を記録し、サービス消費者(Consumer)は登録センターを通じてサービスプロバイダ(Provider)リストを取得してこそ、サービス呼び出しを完了することができる.登録センターは、Webサービスの重要なコンポーネントです.#現在、1つのサイトの登録センターのサービスConsumerとProviderには35 K+があります.
登録センターのサービスがますます多くなるにつれて、登録センターの機能がますます多くなるにつれて、登録センターのオンライン発表と検証の過程はますます複雑になり、発表過程はしばしばいくつかの問題が発生し、発表過程は危険になる.
これらの複雑さに対処することは、パブリケーションとそのチェックを継続的に改善することです.
(1)データベース構成エラー
アリ系オンラインには、生産環境と事前公開環境の2つが公開されており、この2つの環境は隔離されており、異なる環境の登録センターでは異なるDBが使用されています.アプリケーションは、プリパブリケーション環境でパブリッシュされ、問題がないことを確認した後、本番環境でパブリッシュされます.
パブリケーションはSCMによって行われ、異なる構成ファイル(異なるDB構成を含む)を使用してパブリケーションをパッケージ化します.
人が操作するとエラーが発生する可能性があります.あるSCMは、本番環境でプリパブリッシュ環境のDBを構成した.DBにプリパブリッシュ環境のProviderデータがあり、オンラインアプリケーションでエラーが発生しました.
解決策
レジストリ・センターの配置ディレクトリの下でデータベース・プロファイルの値が正常かどうかを監視します.
Dubbo登録センターのDB情報は
この構成でdatabase ip、ユーザー名の値が予想されるかどうかを監視します.
PS:モニタリングファイルの内容、URLの出力結果、URL応答時間、ハードディスク、メモリ、ネットワーク使用量などはモニタリングシステムの基本機能である.
原則
人の操作は間違いの可能性のある操作です.エラーが発生する可能性のある場所に監視カメラを付けると、エラーが発生すると警察に通報されます.このような監視項目はずっと開いているはずです.
(2)ConsumerとProviderのデータ照合
登録センターのパブリケーション後、ConsumerとProviderがパブリケーション前後に欠落しているかどうかを確認します.が欠けていなければ、安心してリリースを完了します. 欠落がある場合は、処理して、原因を見つけて、例えば、少ないProviderは本当にラインオフしましたか?登録センターの元の汚いデータ?自分で処理できない場合は、対応アプリケーションの担当者に連絡して処理を確認します.
解決策
1)登録センター提供URLはDumpでProvider、Consumerのデータを出すことができます:(実際には閲覧しやすいページもできます.)#URLを提供することは、スクリプトとの統合を容易にし、他の方法で使用することができます.
2)リリースされたクローズ・スクリプトと起動スクリプトに、論理を追加:データをファイルにDumpする
3)スクリプト、Diffデータの前後のProviderデータを追加します.例えば簡単な実現は
直接diffコマンド出力のフォーマットを使用すると、直接読むのが不便で、より良いことができます.
4)起動が完了し、登録センターが安定した後、上記のDiffスクリプトを実行し、差異を迅速に見つける.
原則
煩雑な検査操作では,プログラムに論理出力に必要なデータを追加することができる.配布スクリプトで確認するデータをDumpします.スクリプトを使用して、チェック操作を自動的に完了します.
(3)登録センタ状態報告加速するために、登録センターにはCacheデータがあります.例えば、登録されたProvider情報はメモリに保存され、DBに非同期で書き込まれます.このようなCacheが長時間データがあれば、問題があることを示します. タスクを実行するスレッドプールのステータス.スレッドプールActiveが高い場合は問題があります. ……
これらのビジネスステータスは、パブリケーションプロセスでもチェックする必要があります.
解決策
登録センターにアクセスできるURLがあり、これらのステータスをリストします.
最初の行は要約行です.#後でスクリプトを比較すると、これを無視できます.
これにより、このURLが
リリース時には、この場所をチェックするだけで必要な情報をすべて入手できます.いろいろなところを一つ一つ見る必要はありません.
原則
チェックが必要なデータは、論理的に簡単に表示できます.チェックが継続する必要がある場合は、モニタリングシステムに構成します.
(4)登録センターの再起動による大量の動的データ削除
ProviderとConsumerは動的データ、つまりProvider、Consumerが接続解除されるとデータは消去されます.
このような機能に問題はありません.オンライン上で問題があるのは、登録センターが発表されたときに、登録センターが再起動し、接続が切断され、登録センターが起動すると、Consumer、Providerが接続され、登録センターがConsumer、Providerのデータを削除し、書き込むことで、データが動揺します.大量のデータの削除と書き込みは、登録センターの圧力が大きい.オンライン登録センターは何度もこの問題でDBが大量に操作されてHangが住んでいて、登録センターが起動できなくて、かなりスリルがあります! Consumerが受信する可能性のあるProviderリストが欠落している(データが不完全)ため、アプリケーションの問題が発生します.たとえばConsumerが受け取ったProviderリストには1つのProviderしかありません.Consumerが1台のProviderに呼び出すと、Providerが潰され、サービス呼び出しに失敗します.
解決策
登録センターはwarm-upステータスを設定できます.パブリケーションが完了したら、登録センターが安定するまで待ってwarm-upステータスを閉じます.「登録センターが安定している」とは、Providerが再接続され、Providerデータが動揺しないことを意味します.
warm-upステータスの場合: ConsumerとProviderの動的データは削除されません(書き込み許可). 登録センターはConsumerに通知せず、Providerリストの変更はConsumerにプッシュしません.登録センターのパブリケーションでは、Providerの変化は少なく、古いデータに問題はありません.
この機能により、パブリケーションスクリプトと統合できない場合は、パブリケーションプロセスは複数の人肉操作で、パブリケーションスクリプトと統合されます.
登録センターがwarm-up状態をスイッチするURLを提供することも考慮できます.
これにより、パブリケーションが開始されると、パブリケーションスクリプトでwarm-upステータスが開きます.パブリケーションが完了したら、レジストリセンタークラスタが安定するのを待ってwarm-upステータスを閉じます.
warm-upは一時的な状態で、長時間warm-up状態になると故障します.モニタリング項目を追加します.登録センターがwarm-up状態の場合、アラームが発生します.この問題は故障を起こしたことがあります.当時warm-up状態の設定はまだ人肉で完了していましたが、発表が完了した後、変更を忘れてしまいました.この問題も別の側面の思考を引き出し、私の次のブログでは、安全で信頼できるパブリケーションプロセスを準備することを説明しています.
まとめエラーが発生しやすいステップであればあるほど、自動化が必要になります.多く実行するとエラーが発生しやすいステップを発見し、さらにエラーが発見された原因を見つけて改善し、安定した信頼性のある実行を行うことができるからです. の自動化が重要です.もちろん最初は安全のために手で実行していましたが、手動で何回か実行した後: ステップは に固定する.間違いがあるところは心の中で を数えている.
上の発見問題から自動化解決まで、全体の過程は以下の図である.
発見された問題が徐々に自動化されるにつれて、通常の状況では、スクリプトの実行が完了して正常に戻り、人肉の介入が不要になる自信があります.すなわち、理想的には、スクリプトの「one-line」を実行するだけで、パブリッシュ操作が非常に簡単になります.非正常な状況で、Providerが紛失した場合、人肉を参加させ、ユーザーと一緒に問題を解決することは避けられない.コマンドラインの「one-line」vs.GUIの「one-click」
個人ブログのブログアドレス:公開とその検査の自動化実践
Dubbo登録センターはウェブサイト全体のサービス情報を記録し、サービス消費者(Consumer)は登録センターを通じてサービスプロバイダ(Provider)リストを取得してこそ、サービス呼び出しを完了することができる.登録センターは、Webサービスの重要なコンポーネントです.#現在、1つのサイトの登録センターのサービスConsumerとProviderには35 K+があります.
登録センターのサービスがますます多くなるにつれて、登録センターの機能がますます多くなるにつれて、登録センターのオンライン発表と検証の過程はますます複雑になり、発表過程はしばしばいくつかの問題が発生し、発表過程は危険になる.
これらの複雑さに対処することは、パブリケーションとそのチェックを継続的に改善することです.
(1)データベース構成エラー
アリ系オンラインには、生産環境と事前公開環境の2つが公開されており、この2つの環境は隔離されており、異なる環境の登録センターでは異なるDBが使用されています.アプリケーションは、プリパブリケーション環境でパブリッシュされ、問題がないことを確認した後、本番環境でパブリッシュされます.
パブリケーションはSCMによって行われ、異なる構成ファイル(異なるDB構成を含む)を使用してパブリケーションをパッケージ化します.
人が操作するとエラーが発生する可能性があります.あるSCMは、本番環境でプリパブリッシュ環境のDBを構成した.DBにプリパブリッシュ環境のProviderデータがあり、オンラインアプリケーションでエラーが発生しました.
解決策
レジストリ・センターの配置ディレクトリの下でデータベース・プロファイルの値が正常かどうかを監視します.
Dubbo登録センターのDB情報は
jdbc.propertiesファイルに配置されている.database.url=jdbc:mysql://1.2.3.4/dubbo_registry
database.username=dubbo_registry
database.password=dubbo_registry
......この構成でdatabase ip、ユーザー名の値が予想されるかどうかを監視します.
PS:モニタリングファイルの内容、URLの出力結果、URL応答時間、ハードディスク、メモリ、ネットワーク使用量などはモニタリングシステムの基本機能である.
原則
人の操作は間違いの可能性のある操作です.エラーが発生する可能性のある場所に監視カメラを付けると、エラーが発生すると警察に通報されます.このような監視項目はずっと開いているはずです.
(2)ConsumerとProviderのデータ照合
登録センターのパブリケーション後、ConsumerとProviderがパブリケーション前後に欠落しているかどうかを確認します.
解決策
1)登録センター提供URLはDumpでProvider、Consumerのデータを出すことができます:(実際には閲覧しやすいページもできます.)#URLを提供することは、スクリプトとの統合を容易にし、他の方法で使用することができます.
13210 provider instance
dubbo://10.200.216.119:20882/com.aliyun.crm.panorama.webx.BucAclService com.aliyun.crm.panorama.webx.BucAclService:1.0.0
dubbo://10.246.130.110:20880/com.alibaba.havana.api.member.JoinService hz_idc/com.alibaba.havana.api.member.JoinService:1.0.0
dubbo://10.246.130.110:20880/com.alibaba.havana.api.member.MemberService com.alibaba.havana.api.member.MemberService:1.0.0
dubbo://10.246.130.110:20880/com.alibaba.havana.api.member.MemberService hz_idc/com.alibaba.havana.api.member.MemberService:1.0.0
dubbo://10.246.130.110:20880/com.alibaba.havana.api.member.OperatorService hz_idc/com.alibaba.havana.api.member.OperatorService:1.0.0
......2)リリースされたクローズ・スクリプトと起動スクリプトに、論理を追加:データをファイルにDumpする
wget http://127.0.0.1:${APP_PORT}/sysinfo/dump/providers \
--timeout=15 --output-document=$DUMP_DIR/providers.dump \
--output-file=$DUMP_DIR/providers.dump.log3)スクリプト、Diffデータの前後のProviderデータを追加します.例えば簡単な実現は
$ diff dir1/provider.dump dir2/provider.dump直接diffコマンド出力のフォーマットを使用すると、直接読むのが不便で、より良いことができます.
4)起動が完了し、登録センターが安定した後、上記のDiffスクリプトを実行し、差異を迅速に見つける.
原則
煩雑な検査操作では,プログラムに論理出力に必要なデータを追加することができる.配布スクリプトで確認するデータをDumpします.スクリプトを使用して、チェック操作を自動的に完了します.
(3)登録センタ状態報告
これらのビジネスステータスは、パブリケーションプロセスでもチェックする必要があります.
解決策
登録センターにアクセスできるURLがあり、これらのステータスをリストします.
OK
[Cache]
FailedRegitered=0
[ThreadPool]
Active=30
Max=200
Idle=200
......最初の行は要約行です.#後でスクリプトを比較すると、これを無視できます.
これにより、このURLが
OKであるかどうかを監視する監視項目を追加することができる.リリース時には、この場所をチェックするだけで必要な情報をすべて入手できます.いろいろなところを一つ一つ見る必要はありません.
原則
チェックが必要なデータは、論理的に簡単に表示できます.チェックが継続する必要がある場合は、モニタリングシステムに構成します.
(4)登録センターの再起動による大量の動的データ削除
ProviderとConsumerは動的データ、つまりProvider、Consumerが接続解除されるとデータは消去されます.
このような機能に問題はありません.オンライン上で問題があるのは、登録センターが発表されたときに、登録センターが再起動し、接続が切断され、登録センターが起動すると、Consumer、Providerが接続され、登録センターがConsumer、Providerのデータを削除し、書き込むことで、データが動揺します.
解決策
登録センターはwarm-upステータスを設定できます.パブリケーションが完了したら、登録センターが安定するまで待ってwarm-upステータスを閉じます.「登録センターが安定している」とは、Providerが再接続され、Providerデータが動揺しないことを意味します.
warm-upステータスの場合:
この機能により、パブリケーションスクリプトと統合できない場合は、パブリケーションプロセスは複数の人肉操作で、パブリケーションスクリプトと統合されます.
登録センターがwarm-up状態をスイッチするURLを提供することも考慮できます.
curl http://127.0.0.1:${APP_PORT}/sys/config?warmup=true
curl http://127.0.0.1:${APP_PORT}/sys/config?warmup=falseこれにより、パブリケーションが開始されると、パブリケーションスクリプトでwarm-upステータスが開きます.パブリケーションが完了したら、レジストリセンタークラスタが安定するのを待ってwarm-upステータスを閉じます.
warm-upは一時的な状態で、長時間warm-up状態になると故障します.モニタリング項目を追加します.登録センターがwarm-up状態の場合、アラームが発生します.この問題は故障を起こしたことがあります.当時warm-up状態の設定はまだ人肉で完了していましたが、発表が完了した後、変更を忘れてしまいました.この問題も別の側面の思考を引き出し、私の次のブログでは、安全で信頼できるパブリケーションプロセスを準備することを説明しています.
まとめ
上の発見問題から自動化解決まで、全体の過程は以下の図である.
発見された問題が徐々に自動化されるにつれて、通常の状況では、スクリプトの実行が完了して正常に戻り、人肉の介入が不要になる自信があります.すなわち、理想的には、スクリプトの「one-line」を実行するだけで、パブリッシュ操作が非常に簡単になります.非正常な状況で、Providerが紛失した場合、人肉を参加させ、ユーザーと一緒に問題を解決することは避けられない.コマンドラインの「one-line」vs.GUIの「one-click」
個人ブログのブログアドレス:公開とその検査の自動化実践