JP2021099888A - サービス情報処理方法、装置、設備、コンピュータ記憶媒体、及びプログラム - Google Patents

Abstract

【課題】単一のコンテナにおける複数のプロセスの実行を実現し、コンテナのリソースを節約し、伝統的なＰａａＳコンテナ管理システムのコンテナ管理効率及び実行コストを最適化するサービス情報処理方法、装置、設備及びコンピュータ記憶媒体を提供する。【解決手段】サービス情報処理方法は、設定された時間間隔に従って、コンテナにおいて実行されているサービスのターゲットプロセスにポーリング情報を送信することと、ポーリング情報に応じてターゲットプロセスがレスポンスした応答情報を受信することと、応答情報に基づいて、ターゲットプロセスの生存状況を得ることと、を含む。ターゲットプロセスは、コンテナにおいて実行されている複数のプロセスのうちの１つである。【選択図】図１

Description

本開示は、コンピュータ技術分野に関し、特にクラウドコンピューティング技術分野に関する。

ネットワークにおいて実行されるソフトウェアモジュールは、サービスと呼ぶことができ、ユーザが異なる場所で異なる端末装置を介してネットワーク上のデータへのアクセスや、ＡＰＰ（Ａｐｐｌｉｃａｔｉｏｎ、アプリケーション）の使用を可能にする。ネットワーク技術の発展に伴い、コンテナ技術も急速に発展し、サービスをコンテナを介してデプロイできるようになった。インターネット企業内部には、通常、ヘテロジニアスサービスと物理リソースとが大量にある。より良好に、より効率的に大量なヘテロジニアスサービスと物理リソースとを管理するために、多くのインターネット企業は、単一のコンテナに基づく伝統的なＰａａＳ（Ｐｌａｔｆｏｒｍ Ａｓ Ｓｅｒｖｉｃｅ、サービスとしてのプラットフォーム）コンテナ管理システムにより、業務のデプロイ変更とリソース仮想化交付とを実現している。

サービスの種類の増加に伴い、単一のコンテナの伝統的なＰａａＳコンテナ管理システム（略称：ＰａａＳシステム）のコンテナ管理効率、実行コストを如何にして最適化するかは、コンテナ管理システムの改善すべき問題の１つである。

本開示は、サービス情報処理方法、装置、設備及びコンピュータ記憶媒体を提供する。

本開示の１つの態様は、サービス情報処理方法を提供し、当該方法は、設定された時間間隔に従って、コンテナにおいて実行されているサービスのターゲットプロセスにポーリング情報を送信することと、ポーリング情報に応じてターゲットプロセスがレスポンスした応答情報を受信することと、応答情報に基づいて、ターゲットプロセスの生存状況を得ることと、を含み、ターゲットプロセスは、コンテナにおいて実行されている複数のプロセスのうちの１つである。

本開示の他の態様は、サービス情報処理装置を提供し、当該装置は、設定された時間間隔に従って、コンテナにおいて実行されているサービスのターゲットプロセスにポーリング情報を送信するためのポーリングモジュールと、ポーリング情報に応じてターゲットプロセスがレスポンスした応答情報を受信するための応答受信モジュールと、応答情報に基づいて、ターゲットプロセスの生存状況を得るための死活監視モジュールと、を備え、ターゲットプロセスは、コンテナにおいて実行されている複数のプロセスのうちの１つである。

本開示の他の態様は、電子設備をさらに提供し、当該電子設備は、少なくとも１つのプロセッサと、少なくとも１つのプロセッサに通信接続されるメモリと、を備え、メモリには、少なくとも１つのプロセッサにより実行可能な命令が記憶されており、命令は、少なくとも１つのプロセッサにより実行される場合、本開示の態様の任意のサービス情報処理方法を実行させることを特徴とする。

本開示の他の態様は、コンピュータ命令を記憶した非一過性のコンピュータ可読記憶媒体をさらに提供し、当該コンピュータ命令を記憶した非一過性のコンピュータ可読記憶媒体は、本開示の態様の任意のサービス情報処理方法をコンピュータに実行させる。

本開示の態様によれば、ターゲットプロセスは、コンテナにおいて実行されている複数のプロセスのうちの１つであり、ターゲットプロセスの死活監視を行うために、ターゲットプロセスに対して単独にポーリングを行う。このように、コンテナにおけるプロセスごとに独立して死活監視を行うことができるため、単一のコンテナにおいて複数のプロセスの実行を実現し、コンテナのリソースを節約することができる。

ここに記載された内容は、本開示の態様のキーポイント又は重要な特徴を標識することを意図せず、また、本開示の範囲を制限することにも用いられないことを理解すべきである。本開示の他の特徴については、下記の明細書を通して説明を促す。

添付図面は、本方案をより良く理解するためのものであり、本開示を限定するものではない。
本開示の実施形態によるサービス情報処理方法の模式図である。 本開示の１つの例示的コンテナ一の内部アーキテクチャの模式図である。 本開示の他の実施形態によるサービス情報処理方法の模式図である。 本開示の他の実施形態によるサービス情報処理方法の模式図である。 本開示の他の例示的構成プラットフォームの模式図である。 本開示の他の例示的コンテナにおける操作フレームワークの模式図である。 本開示の１つの実施形態によるサービス情報処理装置の模式図である。 本開示の他の実施形態によるサービス情報処理装置の模式図である。 本開示の他の実施形態によるサービス情報処理装置の模式図である。 本開示の他の実施形態によるサービス情報処理装置の模式図である。 本開示の他の実施形態によるサービス情報処理装置の模式図である。 本開示の実施形態によるサービス情報処理方法を実現するための電子設備のブロック図である。

以下では、本開示の例示的な実施形態を、理解を容易にするために本開示の実施形態の様々な詳細を含む添付の図面に関連して説明するが、これらは単に例示的なものであると考えるべきである。

したがって、当業者は、本開示の範囲及び精神を逸脱することなく、本明細書に記載された実施形態に様々な変更及び修正を加えることができることを認識すべきである。同様に、以下の説明では、周知の機能及び構成については、明確化及び簡明化のために説明を省略する。

本開示の実施形態は、サービス情報処理方法を提供し、図１に示すように、サービス情報処理方法は、以下を含む。

ステップＳ１１において、設定された時間間隔に従って、コンテナにおいて実行されているサービスのターゲットプロセスにポーリング情報を送信し、ターゲットプロセスは、コンテナにおいて実行されている複数のプロセスのうちの１つである。

ステップＳ１２において、ポーリング情報に応じてターゲットプロセスがレスポンスした応答情報を受信する。

ステップＳ１３において、応答情報に基づいて、ターゲットプロセスの生存状況を得る。

本実施形態において、コンテナにおいて実行されているサービスのターゲットプロセスにポーリング情報を送信することは、ポートを介してターゲットプロセスにポーリング情報を送信してもよく、プローブの方法を用いてターゲットプロセスにポーリング情報を送信し、ターゲットプロセスの状態をポーリングしてもよい。

本実施形態において、コンテナにおいて複数のプロセスが実行されており、これらの複数のプロセスは、同じサービスのプロセスであってもよく、同じサービスに属さなくてもよい。例えば、コンテナにおいて、クリティカルサービスＡを含む複数のプロセス、及びクリティカルサービスＡの付随サービスＢの少なくとも１つのプロセスを実行する場合、ターゲットプロセスは、クリティカルサービスＡ又は付随サービスＢのプロセスであってもよい。さらにまた、コンテナにおいて付随サービスＢを実行せず、クリティカルサービスＡを含む複数のプロセスを実行する場合、ターゲットプロセスはクリティカルサービスＡのプロセスとなる。

上述のコンテナにおいて実行される複数のプロセスは、クリティカルサービスのクリティカルプロセスを含んでもよく、さらに、クリティカルサービスの付随サービスＢの非クリティカルプロセスを含んでもよく、ここで、クリティカルサービスの付随サービスＢは非クリティカルサービスである。クリティカルサービスとクリティカルサービスの付随サービスＢとのいずれもコンテナにおいてプロセスと異なるアドオンを実行できる。１つの具体的な実施形態において、アドオンはポーリング情報を受信する対象に属さない。

上述のコンテナにおいて実行される複数のプロセスは、クリティカルサービスのクリティカルプロセスのみを含んでもよい。この場合、コンテナ内には、非クリティカルサービスのプロセスが存在せず、クリティカルサービスのプロセスのみがある。

同じコンテナにおいて、複数のプロセス間は、ディレクトリを用いて隔離してもよく、隔離カードを用いてもよく、隔離しなくてもよい。

具体的には、コンテナにおける複数のプロセスは、サービスＡのＮｇｉｎｘ（Ｘエンジン）プロセス、Ｍａｉｎ（メイン）プロセスを含んでもよく、サービスＡは公共の構成ライブラリ（アドオン）を持つ。さらにサービスＡに属さないＳｉｄｅｃａｒ（サイドカー）プロセスを実行することもでき、Ｓｉｄｅｃａｒプロセスは、サービスＡの付随サービスＢのプロセスであり、サービスＡに機能を追加するために用いられる。

コンテナにおいて実行されている複数のプロセスに対して、ポートを介して、又はプローブの方法を用いて、コンテナにおいて実行されている複数のプロセスに対して状態のポーリングを行うことができる。ポーリングを行うことにより、各プロセスの実行に異常が発生していないかを知り、複数のプロセスに対して死活監視を行うことができる。

ターゲットプロセスはポーリング情報を受信した後、ポーリング情報に対する応答情報を返答する。応答情報を受信しなかった、又は応答情報の異常を受信した場合、ターゲットプロセスに異常が発生したと判定できる。

本実施形態において、応答情報に基づいて、ターゲットプロセスの生存状況を得ることは、応答情報を受信したか否かに基づいて、又は受信した応答情報の内容に基づいて、ターゲットプロセスの生存状況を判断してもよい。

本実施形態において、ターゲットプロセスの生存状況情報を得た後、生存状況の異常があれば、ターゲットプロセスの生存状況を記録する。ターゲットプロセスがクリティカルサービスのプロセスである場合、例えば、ターゲットプロセスがクリティカルサービスＡのコンテナにおけるメインプロセスである場合、コンテナにおけるクリティカルサービスＡのインスタンス状態異常を記録する。ターゲットプロセスが非クリティカルサービスのプロセスである場合、たとえば、ターゲットプロセスが付随サービスＢの付随プロセスである場合、該ターゲットプロセスの状態異常のみを記録する。

インスタンス状態異常を記録する、又はターゲットプロセス異常を記録する作用には、サービスＡ又はターゲットプロセスに対してキープアライブのカウントダウンを行うことを含んでもよい。たとえば、クリティカルサービスＡのインスタンス状態異常が記録されてから設定された第１時間に達したとき、クリティカルサービスＡの再デプロイを行う。さらにたとえば、ターゲットプロセスが非クリティカルサービスのプロセスである場合、ターゲットプロセス異常が記録されてから設定された第２時間に達したとき、又は該ターゲットプロセス異常を複数回記録したとき、ターゲットプロセスを再起動する。

具体的な実現において、コンテナにおいて１つの基礎（Ｂａｓｅ）サービスをデプロイすることができ、この基礎サービスは１つのプログラムスクリプトであってもよく、ＰａａＳシステムは該プログラムスクリプトの呼び出しを介して図１に示されるステップＳ１１〜Ｓ１３を行う。

コンテナにおいてデプロイされる基礎サービスのスクリプトは、他のサービスの死活監視を管理するのに用いられ、これに加え、ＰａａＳシステムは、さらに基礎サービスのスクリプトを呼び出して他のサービスに対して停止、データロードなどを行うことができ、１つの共通サービスコントロール（Ｃｏｎｔｒｏｌ）スクリプトとして機能する。この共通サービスコントロールスクリプトは、業務のサービスをコントロールしてもよく、コンテナに独立してアクセス、変更、キープアライブ、死活監視（Ｓｔａｔｕｓ）してもよく、プロセス起動時にロードした構成のデータ（Ｒｅｌｏａｄ）、プロセスの起動（Ｓｔａｒｔ）、プロセスの停止（Ｓｔｏｐ）などを通知する。

業務のサービスは、プロセスの起動を必要とする場合、死活監視の対象とすることができ、たとえば図２に示すような、サービスＡ（ＳｅｒｖｉｃｅＡ）２１、サービスＢ（Ｓｅｒｖｉｃｅ Ｂ）２２である。サービスＡとサービスＢとは、コンテナにおいてそれぞれ少なくとも１つのプロセスを起動する。アドオン（Ａｄｄｏｎ）は、サービスのプロセスに属さず、他のサービスに構成又は基礎環境機能を提供することのみに用いられてもよい。図２に示すように、サービスＢのアドオンはＣ２３であり、すなわち（Ｓｅｒｖｉｃｅ Ｂ Ａｄｄｏｎ Ｃ）である。又は、サービスＡのアドオンＤ、（Ｓｅｒｖｉｃｅ Ａ Ａｄｄｏｎ Ｄ）である。依然として図２を参照し、ＰａａＳにより基礎サービス２４を呼び出して、サービスＡ２１、サービスＢ２２、サービスＢのアドオンＣ２３の起動、停止、データのリロード、及び死活監視操作を行う。

本実施形態において、ターゲットプロセスは、コンテナにおいて実行されている複数のプロセスのうちの１つであり、ターゲットプロセスに対して単独にポーリングを行い、ターゲットプロセスに対する死活監視を行う。これにより、コンテナにおける他のプロセスに対していずれも独立して死活監視を行うことができ、従来のＰａａＳ単一のコンテナに基づいて、単一のコンテナにおいて複数のプロセスの実行を実現し、コンテナのリソースを節約する。

１つの実施形態において、サービスは、非クリティカルサービスを含む。図３に示すように、サービス情報処理方法は、さらに以下を含む。

ステップＳ３１において、ターゲットプロセスが非生存状態であり、かつ、ターゲットプロセスが非クリティカルサービスのプロセスである場合、コンテナにおける非クリティカルサービスに対応するアドオンに基づいて、ターゲットプロセスの構成情報を取得する。

ステップＳ３２において、前記構成情報に基づいて、前記ターゲットプロセスを再起動する。

本実施形態において、プロセスに対してクリティカル性フラグフィールドを設定することにより、プロセスをクリティカルサービスのプロセスであるか、又は非クリティカルサービスのプロセスであるかを区別することができる。

さらに、サービスに対してクリティカル性フラグフィールドを設定することにより、サービスをクリティカルサービス又は非クリティカルサービスに区別することもできる。一般的に、非クリティカルサービスは、クリティカルサービスの付随サービスＢであってもよい。ターゲットプロセスがクリティカルサービスのプロセスである場合、クリティカルプロセスであり、ターゲットプロセスが非クリティカルサービスのプロセスである場合、非クリティカルプロセスである。

本実施形態において、ターゲットプロセスが非生存状態であり、かつ、ターゲットプロセスが非クリティカルサービスのプロセスである場合、ターゲットプロセスを再起動することは、ポーリングによりターゲットプロセスが非生存状態であることが検出された後、設定された第１時間後にターゲットプロセスを再起動してもよい。

本実施形態において、非クリティカルサービスのプロセスについて、該プロセスが非生存状態である場合、非クリティカルサービスのプロセスと他のプロセスとに依存関係が存在せず、コンテナにおける他のプロセスの実行に影響を及ぼさず、単独に該プロセスに対して再起動を行うことができ、コンテナにおけるプロセスの単独のキープアライブを実現し、コンテナの再構築を必要とせず、キープアライブのコストを低減し、インスタンスレベルのキープアライブを実現する。

１つの実施形態において、サービスは、クリティカルサービスを含む。図４に示すように、サービス情報処理方法は、以下をさらに含む。

ステップＳ４１において、ターゲットプロセスが非生存状態であり、かつ、ターゲットプロセスがクリティカルサービスのプロセスである場合、ターゲットプロセスを停止する。

ステップＳ４２において、サービスを再デプロイする。

本実施形態において、コンテナにおいて実行されているプロセスの内、２つ以上のプロセスがクリティカルサービスのプロセスである場合、これらの２つ以上のプロセスは通常、プロセス間の依存関係が存在するか、又は非クリティカルサービスのプロセスに依存されている可能性があり、クリティカルサービスのプロセスが非生存状態であるとき、該クリティカルサービスを再デプロイする必要があると同時に、コンテナにおいてプロセスを実行している他のサービスも再デプロイする必要がある。具体的に、クリティカルサービスのプロセスが非生存状態にあることを検出した第１時間後に、又はクリティカルサービスが非生存状態であると複数回検出した後に、クリティカルサービスのパケットを抽出し、クリティカルサービスの記述情報を取得し、クリティカルサービスのデプロイを行ってもよい。

ターゲットプロセスを停止するとき、コンテナにおいて２つ以上のサービスを有するプロセスが実行されている場合、サービス間に依存関係は存在する可能性があり、例えば、付随サービスＢはよくクリティカルサービスに依存している。そのため、ターゲットプロセスを停止するとき、コンテナにおけるクリティカルなサービスと非クリティカルサービスとの他のプロセスも停止すべきである。プロセスを停止するとき、サービス間の依存関係に従って、第１順序で停止する。クリティカルサービスを再デプロイするとき、２つ以上のサービスのプロセスに対して第１順序とは相反の順序で起動を行う必要がある。

１つの例において、クリティカルサービスのプロセスと非クリティカルサービスのプロセス、及び相応のアドオンは、いずれも独立して変更することができる。また、クリティカルサービスのプロセスと非クリティカルサービスのプロセスとは、さらに独立して死活監視、キープアライブをできるが、アドオンは死活監視、キープアライブを行う必要がない。サービスは、１つのフィールド、「ｉｓ＿ｃｒｉｔｉｃａｌ」を用いて、このサービスがクリティカルサービスであるか否かを定義してもよく、クリティカルサービスである場合、「ｉｓ＿ｃｒｉｔｉｃａｌ」のフィールドの値は「ｔｒｕｅ」である。コンテナにおいてクリティカルサービスのプロセスを含み、さらに非クリティカルサービスのプロセスをも含んでいる場合、非クリティカルサービスはクリティカルサービスに依存し、クリティカルサービスが異常になるとコンテナ全体のキープアライブが行われる。付随サービスＢ（すなわち、非クリティカルサービス）である場合、「ｉｓ＿ｃｒｉｔｉｃａｌ」のフィールドの値は「ｆａｌｓｅ」であり、このような非クリティカルサービスが他のサービスに依存されず、異常が現在のコンテナ全体に反映されていないので、該サービスのみに対して再キープアライブすれば、他のサービスの正常な動作に影響を与えない。キープアライブは語彙がより豊富で、キープアライブのコストをより柔軟に制御できる。

本実施形態において、クリティカルサービスのプロセスに対して、非クリティカルサービスのプロセスとは異なるキープアライブ方法を採用することにより、単一のコンテナに基づいて複数のプロセスを実行すると同時に、複数のプロセスに対して柔軟なキープアライブを行うことができ、クリティカルサービスの単独のデプロイが必要な場合とき、クリティカルサービスに対する単独のデプロイを行い、キープアライブのコストを低減し、サービスレベルのキープアライブを支える。

１つの実施形態において、コンテナにおける複数のプロセスの対応するサービスを再デプロイすることは、以下を含む。

構成プラットフォームから、サービスのリソース記述とパッケージ記述とを含む、サービスの記述情報を取得する。リソース記述は、サービスのコンテナ実行のリソースを記録するのに用いられ、パッケージ記述は、サービスのプロセスの構成情報に用いられる。

リソース記述に基づいて、サービスの属するコンテナを起動するのに用いられるリソースを取得する。

リソースに基づいて、コンテナを起動する。

パッケージ記述に基づいて、コンテナにおいてサービスのプロセスディレクトリと前記サービスのアドオンとを作成する。アドオンはサービスの複数のプロセスの構成情報を記憶するのに用いられる。

プロセスディレクトリとアドオンとに基づいて、コンテナにおいてサービスのプロセスを起動する。

本実施形態において、クリティカルサービスを再デプロイするとき、行う操作とクリティカルサービスを初めにデプロイする操作はほぼ同じである。構成プラットフォームからクリティカルサービスの記述情報を取得するため、記述情報を人為的に再入力する必要がない。記述情報がサービスのリソース記述とパッケージ記述とを含み、リソース記述がサービスのコンテナ実行のリソースを記録するのに用いられ、パッケージ記述がサービスのプロセスの構成情報に用いられるため、ＰａａＳコンテナ管理システムの従来の構成情報を変更することなく、サービスの再デプロイの操作を減少することができる。

１つの実施形態において、サービス情報処理方法は、以下をさらに含む。

クリティカルサービスの付随サービスＢを再デプロイする。

付随サービスＢとクリティカルサービスとを、設定された順序に従ってデプロイする。

また、サービス間はさらに依存関係、サービス間の起動、停止順序を定義する必要がある。コンテナにおいてクリティカルサービスと非クリティカルサービスとを含む複数のサービスが含まれている場合、サービス間の依存関係が存在し、一般的に、非クリティカルサービスはクリティカルサービスに依存している。例えば、ソートサービスがクリティカルサービスであり、コンテナにおいてソートプロセスを起動することに対応し、付随サービスＢがコンテナにおいてログ記録プロセスを起動し、該ログ記録プロセスはソートプロセスのログ記録を担当するため、該ログ記録プロセスはソートプロセスに依存している。

本実施形態において、クリティカルサービスの１つを再デプロイするとき、インスタンス全体に対して、事前に定義された起動と停止の順序に従って、相応の起動と停止を行う必要がある。サービス停止の語彙は非常に豊富で、カスタマイズが可能である。

１つの実施形態において、サービス情報処理方法は、以下をさらに含む。

構成プラットフォームからサービスの記述情報を取得し、サービスはクリティカルサービス又は非クリティカルサービスである。

記述情報は、サービスのメタデータ情報に基づいて生成され、サービスのメタデータ情報は、構成プラットフォームに送信されるサービスのアクセス要求に含まれ、記述情報は、業務のリソース記述とパッケージ記述とを含み、リソース記述は、サービスのコンテナ実行のリソースを記録するのに用いられ、パッケージ記述はサービスのプロセスの構成情報に用いられる。

ユーザが、ＰａａＳにおいてサービスをデプロイしたい場合、サービスのアクセス要求を構成プラットフォームに送信し、アクセス要求にはサービスのメタデータ情報が含まれ、構成プラットフォームにおいてサービスの記述情報を生成し、記述情報は該サービスをデプロイするのに用いられる。

本実施形態において、サービスへのアクセス要求に含まれるメタデータ情報に基づいて記述情報を生成するため、ユーザは少量のメタデータ情報を提供するだけでサービスのデプロイを実現でき、サービスのアクセスコストの削減に有利である。

１つのワンストップアクセスの構成プラットフォームを介して、図５に示すように、自動的にサービスの入力とリソース要件、権限アカウントなどのすべての段階を通すため、ユーザ５１は、たとえば、ミラーアドレス（Ａｄｄｒｅｓｓ）、ミラーバージョン（Ｖｅｒｓｉｏｎ）、関連リソース番号などのようなとても少量のメタデータ情報のみを必要とする。ワンストップの構成プラットフォーム５２は、メタデータに基づいて、リソースプラットフォーム５３から記述情報を抽出し、デフォルトルールに従って構成ファイルを自動的に生成することができる。その後、該構成プロファイルを、ａｐｉ（インタフェース）を介して、サービスをデプロイするためにバックエンドのＰａａＳシステム５４に送信し、コンテナにおいてサービスのプロセスを起動する。サービスがアクセスされた後、コンテナにおける起動、停止、死活監視、データロードなどを、１つの適した開発されたスクリプト（Ｂａｓｅ）を介して実行する。

図６に示すサービス情報処理フレームワーク（Ｉｎｆｒａ）のように、プラットフォームは共通のコントロールスクリプトを提供し、構成ファイルを介して、プロセスの死活監視、停止、起動、データの再ロード、ドメイン名サービスを含む該スクリプトの動作を定義する。ここで、死活監視は、ポート死活監視とポインタ死活監視の２つの方法を含み、具体例として、いずれかの任意の１つの方式でプロセスの死活監視を行うことができる。

ポインタ死活監視は、具体的にコマンドラインポインタ死活監視とＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、ハイパーテキスト・トランスファー・プロトコル）ポインタ死活監視の２つの方法を含む。

依然として図６を参照すると、プロセス停止の方法は、業務停止コマンド停止、規制付きサブプロセス再帰停止、及び正常終了時間の長さのカスタマイズという３つを含み、具体例として、いずれか１つの方法を用いてプロセスを停止できる。

依然として図６を参照すると、プロセスの起動方法は、監視付き起動と業務起動コマンド起動の２つの方法を含み、具体例として、いずれか１つの方法を用いて起動を行うことができる。

プロセスのドメイン名サービス（例えば、Ｂａｉｄｕ Ｎａｍｅ Ｓｅｒｖｉｃｅ、ＢＮＳ）はサービスの発見に用いられる。依然として図６を参照すると、プロセスのドメイン名サービスは、変更からインスタンスドメインネームサービスを削除する方法と、ロングテールドメイン名サービスの待ち時間の長さをカスタマイズする方法との２つの方法を含み、具体例として、任意の方法を用いてプロセスのドメイン名サービスを実現することができる。開発スクリプトから構成パラメータへの移行を可能にし、業務のアクセスコストを大幅に削減する。

１つの例において、コンテナにおける複数のサービス間は平行関係であり、オンラインが変更されるたびに、１つのサービス又は複数のサービスの任意の組み合わせを任意に選択することができる。記述情報におけるパッケージ記述に対して更新を行い、更新を検出した後、更新されたデータを抽出し、元のパッケージ記述のデータと比較して両者の差異を決定した後、新たなアドオンを生成し、元の付加項と置き換えることにより、１つのコンテナのサービスオンラインプロセスにおける任意の組み合わせの柔軟な変更を実現することができる。コンテナにおいて変更を必要としないサービスの継続を保証し、コンテナにおいて変更を必要とするサービスは、依存関係にある複数のサービスを任意に選択して、一括に変更することができる。

また、本願の実施形態は、サービス情報処理装置も提供する。図７に示されたサービス情報処理装置は、設定された時間間隔に従って、コンテナにおいて実行されているサービスのターゲットプロセスにポーリング情報を送信するためのポーリングモジュール７１と、ポーリング情報に応じてターゲットプロセスがレスポンスした応答情報を受信するための応答受信モジュール７２と、応答情報に基づいて、ターゲットプロセスの生存状況を得るための死活監視モジュール７３と、を備え、ターゲットプロセスは、コンテナにおいて実行されている複数のプロセスのうちの１つである。

１つの実施形態において、サービスは非クリティカルサービスを含み、図８に示されたサービス情報処理装置は、ターゲットプロセスが非生存状態であり、かつ、ターゲットプロセスが非クリティカルサービスのプロセスである場合、コンテナにおける非クリティカルサービスのアドオンに基づいて、ターゲットプロセスの構成情報を取得するための第１キープアライブモジュール８１と、構成情報に基づいて、ターゲットプロセスを再起動するための第２キープアライブモジュール８２と、を備える。

１つの実施形態において、サービスはクリティカルサービスを含み、図９に示されたサービス情報処理装置は、ターゲットプロセスが非生存状態であり、かつ、ターゲットプロセスがクリティカルサービスのプロセスである場合、ターゲットプロセスを停止するための第３キープアライブモジュール９１と、コンテナにおける複数のプロセスに対応するサービスを再デプロイするための第４キープアライブモジュール９２と、を備える。

１つの実施態様において、図１０に示されたように、第４キープアライブモジュール９２は、構成プラットフォームから、サービスのリソース記述とパッケージ記述とを含む、サービスの記述情報を取得するための記述情報ユニット１０１と、リソース記述に基づいて、サービスの属するコンテナを起動するのに用いられるリソースを取得するためのリソース記述ユニット１０２と、リソースに基づいて、コンテナを起動するためのコンテナ起動ユニット１０３と、パッケージ記述に基づいて、コンテナにおいてサービスのプロセスディレクトリとサービスのアドオンとを作成するためのパッケージ記述ユニット１０４と、プロセスディレクトリとアドオンとに基づいて、コンテナにおいてサービスのプロセスを起動するためのプロセス起動ユニット１０５と、を備え、リソース記述は、サービスのコンテナ実行のリソースを記録するのに用いられ、パッケージ記述はサービスのプロセスの構成情報に用いられ、アドオンはサービスの複数のプロセスの構成情報を記憶するのに用いられる。

１つの実施形態において、図９に示されたサービス情報処理装置は、構成プラットフォームからサービスの記述情報を取得するための記述情報取得モジュール１１１、をさらに備え、記述情報は、サービスのメタデータ情報に基づいて生成され、サービスのメタデータ情報は、構成プラットフォームに送信されるサービスのアクセス要求に含まれ、記述情報は、業務のリソース記述とパッケージ記述とを含み、リソース記述は、サービスのコンテナ実行のリソースを記録するのに用いられ、パッケージ記述はサービスのプロセスの構成情報に用いられる。

本開示の実施形態の装置におけるモジュール／ユニットの機能は、上述した方法の対応する説明を参照することができ、ここではこれ以上説明しない。

本開示の実施形態によれば、本開示は、電子設備及び可読記憶媒体をさらに提供する。

図１２に示すように、本開示の実施形態によるサービス情報処理方法を実現する電子設備のブロック図である。電子設備は、ラップトップコンピュータ、デスクトップコンピュータ、ワークステーション、パーソナルデジタルアシスタント、サーバ、ブレードサーバ、大型コンピュータ、及び他の適切なコンピュータのような様々な形態のデジタルコンピュータを表すことができる。また、電子設備はパーソナルデジタル処理、携帯電話、スマートフォン、装着可能デバイス、及びその他の類似のコンピューティングデバイスなどの様々な形態のモバイルデバイスを表すことができる。ここで示した構成要素、それらの接続と関係、及びそれらの機能は例示的なものに過ぎず、本開示で説明されたもの及び／又は要求される本開示の実施を制限することは意図されない。

図１２に示すように、当該電子設備は、１つ又は複数のプロセッサ１２０１と、メモリ１２０２と、高速インターフェースと低速インターフェースとを含む各構成要素を接続するためのインターフェースとを含む。各構成要素は、異なるバスを利用して互いに接続し、共通のマザーボードに取り付けられてもよいし、必要に応じて他の方法で取り付けられてもよい。プロセッサは、電子設備内で実行される命令を処理してもよく、また、外部入出力デバイス（例えば、インターフェースに接続された表示デバイス）にグラフィックユーザインターフェース（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ，ＧＵＩ）を表示するための、メモリ又はメモリ上に記憶されたグラフィカル情報の命令を含む。他の実施形態では、必要に応じて、複数のプロセッサ及び／又は複数のバスを複数のメモリ及び複数のメモリとともに使用することができる。同様に、複数の電子設備を接続してもよく、各デバイスは、部分的に必要な動作、例えば、サーバアレイ、ブレードサーバの集合、又はマルチプロセッサシステムとして、提供する。図１２においてプロセッサ１２０１を例とする。

メモリ１２０２は、本開示にて提供された非一過性のコンピュータ可読記憶媒体である。メモリは、本開示で提供されるサービス情報処理方法を少なくとも１つのプロセッサに実行させるように、少なくとも１つのプロセッサによって実行されることができる命令を記憶する。本開示における非一過性のコンピュータ可読記憶媒体は、本開示で提供されたサービス情報処理方法をコンピュータに実行させるためのコンピュータ命令を記憶する。

メモリ１２０２は、非一過性のコンピュータ可読記憶媒体として、非一過性のソフトウェアプログラム、非一過性のコンピュータ実行可能なプログラム及びモジュールを記憶するために使用されてもよく、本開示の実施形態におけるサービス情報処理方法に対応するプログラム命令／モジュール、（例えば、図７に示される、ポーリングモジュール７１と応答受信モジュール７２と死活監視モジュール７３のようなもの）である。プロセッサ１２０１は、メモリ１２０２に記憶されている非一過性のソフトウェアプログラム、命令及びモジュールを実行することにより、サーバの様々な機能アプリケーション及びデータ処理、即ち上述した方法に関する実施形態に係るサービス情報処理方法を実行する。

メモリ１２０２は、オペレーティングシステムや少なくとも１つの機能に必要なアプリケーションを記憶することができるプログラムの記憶領域と、サービス情報処理方法に係る電子設備の使用によって生成されたデータなどを記憶することができるデータの記憶領域と、を含むことができる。さらに、メモリ１２０２は、高速ランダムアクセスメモリを含んでもよく、非一過性の固体記憶装置を含んでもよい。例えば、少なくとも１つの磁気ディスク記憶装置、フラッシュメモリ装置、又は他の非一過性の固体記憶装置を含むことができる。いくつかの実施形態では、メモリ１２０２はオプションとして、プロセッサ１２０１に対して遠隔的に設定されたメモリを含み、これらの遠隔メモリは、ネットワークを介してサービス情報処理方法に係る電子設備に接続されてもよい。上記のネットワークの例は、インターネット、企業内ネットワーク、ローカルネットワーク、モバイル通信ネットワーク及びその組み合わせを含むが、これらに限定されない。

本開示の実施形態のサービス情報処理方法に対応する電子設備は、入力装置１２０３と出力装置１２０４とをさらに含むことができる。プロセッサ１２０１、メモリ１２０２、入力装置１２０３、及び出力装置１２０４は、バス又は他の方法で接続されてもよく、図１２ではバスを介して接続されている。

入力装置１２０３は、入力された数字又は文字を受信し、サービス情報処理方法に係る電子設備のユーザ設定及び機能制御に関するキー信号入力を生成することができ、例えば、タッチパネル、キーパッド、マウス、トラックボード、タッチパッド、指示棒、１つ又は複数のマウスボタン、トラックボール、ジョイスティックなどを含むことができる。出力装置１２０４は、表示装置、補助照明装置（例えばＬＥＤ）、及び触覚フィードバック装置（例えば、振動モータ）などを含むことができる。この表示装置は、液晶ディスプレイ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ、ＬＣＤ）、発光ダイオード（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ、ＬＥＤ）ディスプレイ及びプラズマディスプレイを含むことができるがこれらに限定されない。いくつかの実施形態では、表示装置はタッチパネルであってもよい。

本開示におけるシステム及び技術に係る様々な実施形態は、デジタル電子回路システム、集積回路システム、専用集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ、ＡＳＩＣ）、コンピュータハードウェア、ファームウェア、ソフトウェア、及び／又はこれらの組み合わせによって実現されることができる。これらの様々な実施形態は、１つ又は複数のコンピュータプログラムにおいて実装されてもよく、この１つ又は複数のコンピュータプログラムは、少なくとも１つのプログラマブルプロセッサを含むプログラム可能なシステム上で実行されてもよく、及び／又は解釈されてもよく、このプログラマブルプロセッサは、専用又は汎用のプログラマブルプロセッサであってもよく、記憶システム、少なくとも１つの入力装置、及び少なくとも１つの出力装置より、データと命令を受信し、記憶システム、少なくとも１つの入力装置、及び少なくとも１つの出力装置に、データと命令を送信する。

これらの計算プログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、又はコードともいう）は、プログラマブルプロセッサのマシン命令を含み、過程指向及び／又はオブジェクト指向プログラミング言語、及び／又はアセンブリ／マシン言語を用いてこれらの計算プログラムを実施することができる。本開示で使用されるように、「機械可読媒体」及び「コンピュータ可読媒体」という用語は、マシン命令及び／又はデータをプログラマブルプロセッサに提供するための任意のコンピュータプログラム製品、デバイス、及び／又は装置（例えば、磁気ディスク、光ディスク、メモリ、編集可能論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＰＬＤ）を意味し、機械読み取り可能な信号としてのマシン命令を受信する機械可読媒体を含む。「機械読み取り可能な信号」という用語は、マシン命令及び／又はデータをプログラマブルプロセッサに提供するための任意の信号を意味する。

ユーザとのイントラクションを提供するために、本開示で説明されているシステムや技術は、コンピュータ上で実施されてもよく、また、ユーザに情報を表示するための表示装置（例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ、ブラウン管）又はＬＣＤ（液晶ディスプレイ）モニタ）と、入力をコンピュータに提供するためのキーボード及びポインティングデバイス（例えば、マウス又はトラックボール）とを備えてもよい。他の種類の装置も、ユーザとのイントラクションを提供するために使用され得る。例えば、ユーザに提供されたフィードバックは、任意の形態のセンシングフィードバック（例えば、視覚フィードバック、聴覚フィードバック、又は触覚フィードバック）であってもよく、ユーザからの入力は、いかなる形式（音響入力、音声入力、又は触覚入力を含む）で受信されてもよい。

本開示で説明されているシステム及び技術は、バックグラウンド構成要素を含む計算システム（例えば、データサーバとして）、又は中間部構成要素を含む計算システム（例えば、アプリケーションサーバ）、又は、フロントエンド構成要素を含む計算システム（例えば、グラフィカルユーザインタフェース又はネットワークブラウザを備えたユーザコンピュータであって、ユーザがこのグラフィカルユーザインタフェース又はネットワークブラウザを介して本開示で説明されたシステム及び技術に係る実施形態とインタラクションを行うことができるユーザコンピュータ）に実行されてもよく、又は、このようなバックグラウンド構成要素、中間部構成要素、又はフロントエンド構成要素の任意の組合せを含む計算システムにおいて実行されてもよい。システムの構成要素は、任意の形態又は媒体のデジタルデータ通信（例えば、通信ネットワーク）によって相互に接続されてもよい。通信ネットワークの例えとして、ローカルネットワーク（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ，ＬＡＮ）、広域ネットワーク（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ，ＷＡＮ）及びインターネットを含む。

コンピュータシステムは、クライアント及びサーバを含むことができる。クライアントとサーバは一般的に相互に離れており、通信ネットワークを介してインタラクションを行う。クライアントとサーバとの関係を持つコンピュータプログラムがそれぞれのコンピュータ上で実行されることによって、クライアントとサーバとの関係は構築される。サーバはクラウドサーバであってもよく、クラウドコンピューティングサーバ又はクラウドホストとも呼ばれ、クラウドコンピューティングサービスシステムの中の１つのホスト製品であり、従来の物理ホストと仮想専用サーバ（ＶＰＳ）サービスの中に存在する管理困難度が高く、業務拡張性が弱いという欠点を解決する。サーバは分散システムのサーバであってもよく、ブロックチェーンを組み込んだサーバであってもよい。

本開示の技術方案に基づくと、ターゲットプロセスはコンテナにおいて実行されている複数のプロセスのうちの１つであり、ターゲットプロセスに対して、本実施形態例は単独にポーリング情報を行うことで、ターゲットプロセスの死活監視を行う。これにより、コンテナにおける他のプロセスに対して、いずれも単独に死活監視を行うことができ、従来のＰａａＳ単一のコンテナに基づいて、単一のコンテナにおける複数のプロセスの実行を実現し、コンテナのリソースを節約する。

本開示の実施形態は、単一のコンテナの複数のサービスの柔軟なデプロイをサポートし、サービスの増減を柔軟に行うことができ、独立して変更又は任意の組み合せでサービスを変更することができる。

サービスレベルの再起動、インスタンスレベルの再構築の２種類のキープアライブ方法をサポートし、それぞれのクリティカルサービスのプロセスのキープアライブと非クリティカルサービスのプロセスのキープアライブとに対応し、キープアライブが柔軟にとなり、コストの支出がより小さくなる。

業務アクセスコンテナは、ユーザが簡単なメタデータを提供するだけで、プラットフォームのワンストップアクセス、構成ファイルと共用コントロールスクリプトのプラットフォーム化を実現し、コントロール及び起動のためのコントロールスクリプトは簡単にデプロイされる。本開示の実施形態のサービス情報処理方法及び装置により、新たな業務アクセス探索ドメインＰａａＳシステムの時間コストは平均８日間から１日間に短縮される。

上記の様々な態様のフローを使用して、ステップを新たに順序付け、追加、又は削除することが可能であることを理解すべきである。例えば、本開示で記載された各ステップは、並列に実行しても良いし、順次に実行しても良いし、異なる順序で実行しても良い。本開示で開示された技術案が所望する結果を実現することができる限り、本開示ではこれに限定されない。

上記具体的な実施形態は、本開示の保護範囲に対する限定を構成するものではない。当業者は、設計事項やその他の要因によって、様々な修正、組み合わせ、サブ組み合わせ、及び代替が可能であることを理解するべきである。本開示の要旨及び原則内における変更、均等な置換及び改善等は、いずれも本開示の保護範囲に含まれるべきである。

Claims (13)

1. 設定された時間間隔に従って、コンテナにおいて実行されているサービスのターゲットプロセスにポーリング情報を送信することと、
   前記ポーリング情報に応じて、前記ターゲットプロセスがレスポンスした応答情報を受信することと、
   前記応答情報に基づいて、ターゲットプロセスの生存状況を得ることと、を含み、
   前記ターゲットプロセスは、前記コンテナにおいて実行されている複数のプロセスのうちの１つである、
   ことを特徴とするサービス情報処理方法。
2. 前記サービスは、非クリティカルサービスを含み、
   前記サービス情報処理方法は、
   前記ターゲットプロセスが非生存状態であり、かつ、前記ターゲットプロセスが非クリティカルサービスのプロセスである場合、前記コンテナにおける非クリティカルサービスのアドオンに基づいて、前記ターゲットプロセスの構成情報を取得することと、
   前記構成情報に基づいて、前記ターゲットプロセスを再起動することと、をさらに含む、
   ことを特徴とする請求項１に記載のサービス情報処理方法。
3. 前記サービスは、クリティカルサービスを含み、
   前記サービス情報処理方法は、
   前記ターゲットプロセスが非生存状態であり、かつ、前記ターゲットプロセスがクリティカルサービスのプロセスである場合、前記ターゲットプロセスを停止することと、
   前記サービスを再デプロイすることと、をさらに含む、
   ことを特徴とする請求項１に記載のサービス情報処理方法。
4. 前記のサービスを再デプロイすることは、
   構成プラットフォームから、前記サービスのリソース記述とパッケージ記述とを含む、前記サービスの記述情報を取得することと、
   前記リソース記述に基づいて、前記サービスの属するコンテナを起動することに用いられるリソースを取得することと、
   前記リソースに基づいて、前記コンテナを起動することと、
   前記パッケージ記述に基づいて、前記コンテナにおいて前記サービスのプロセスディレクトリと前記サービスのアドオンとを作成することと、
   前記プロセスディレクトリと前記アドオンとに基づいて、前記コンテナにおいて前記サービスのプロセスを起動することと、を含み、
   前記リソース記述は、前記サービスのコンテナ実行のリソースを記録することに用いられ、前記パッケージ記述は、前記サービスのプロセスの構成情報に用いられ、前記アドオンは、前記サービスの複数のプロセスの構成情報を記憶することに用いられる、
   ことを特徴とする請求項３に記載のサービス情報処理方法。
5. 構成プラットフォームから前記サービスの記述情報を取得すること、をさらに含み、
   前記記述情報は、前記サービスのメタデータ情報に基づいて生成され、前記サービスのメタデータ情報は、前記構成プラットフォームに送信されるサービスのアクセス要求に含まれ、前記記述情報は、前記業務のリソース記述とパッケージ記述とを含み、前記リソース記述は、前記サービスのコンテナ実行のリソースを記録することに用いられ、前記パッケージ記述は前記サービスのプロセスの構成情報に用いられる、
   ことを特徴とする請求項１に記載のサービス情報処理方法。
6. 設定された時間間隔に従って、コンテナにおいて実行されているサービスのターゲットプロセスにポーリング情報を送信するポーリングモジュールと、
   前記ポーリング情報に応じて前記ターゲットプロセスがレスポンスした応答情報を受信する応答受信モジュールと、
   前記応答情報に基づいて、ターゲットプロセスの生存状況を得る死活監視モジュールと、を備え、
   前記ターゲットプロセスは、前記コンテナにおいて実行されている複数のプロセスのうちの１つである、
   ことを特徴とするサービス情報処理装置。
7. 前記サービスは、非クリティカルサービスを含み、
   前記サービス情報処理装置は、
   前記ターゲットプロセスが非生存状態であり、かつ、前記ターゲットプロセスが非クリティカルサービスのプロセスである場合、前記コンテナにおける非クリティカルサービスのアドオンに基づいて、前記ターゲットプロセスの構成情報を取得する第１キープアライブモジュールと、
   前記構成情報に基づいて、前記ターゲットプロセスを再起動する第２キープアライブモジュールと、をさらに備える、
   ことを特徴とする請求項６に記載のサービス情報処理装置。
8. 前記サービスはクリティカルサービスを含み、
   前記サービス情報処理装置は、
   前記ターゲットプロセスが非生存状態であり、かつ、前記ターゲットプロセスがクリティカルサービスのプロセスである場合、前記ターゲットプロセスを停止する第３キープアライブモジュールと、
   前記のサービスを再デプロイする第４キープアライブモジュールと、をさらに備える、
   ことを特徴とする請求項６に記載のサービス情報処理装置。
9. 前記第４キープアライブモジュールは、
   構成プラットフォームから、前記サービスのリソース記述とパッケージ記述とを含む、前記サービスの記述情報を取得する記述情報ユニットと、
   前記リソース記述に基づいて、前記サービスの属するコンテナを起動することに用いられるリソースを取得するリソース記述ユニットと、
   前記リソースに基づいて、前記コンテナを起動するコンテナ起動ユニットと、
   前記パッケージ記述に基づいて、前記コンテナにおいて前記サービスのプロセスディレクトリと前記サービスのアドオンとを作成するパッケージ記述ユニットと、
   前記プロセスディレクトリと前記アドオンとに基づいて、前記コンテナにおいて前記サービスのプロセスを起動するプロセス起動ユニットと、を備え、
   前記リソース記述は、前記サービスのコンテナ実行のリソースを記録することに用いられ、前記パッケージ記述は前記サービスのプロセスの構成情報に用いられ、前記アドオンは前記サービスの複数のプロセスの構成情報を記憶することに用いられる、
   ことを特徴とする請求項８に記載のサービス情報処理装置。
10. 構成プラットフォームから前記複数のプロセスの対応する前記サービスの記述情報を取得する記述情報取得モジュール、をさらに備え、
    前記記述情報は、サービスのメタデータ情報に基づいて生成され、前記サービスのメタデータ情報は、前記構成プラットフォームに送信されるサービスのアクセス要求に含まれ、前記記述情報は、前記業務のリソース記述とパッケージ記述とを含み、前記リソース記述は、前記サービスのコンテナ実行のリソースを記録することに用いられ、前記パッケージ記述は前記サービスのプロセスの構成情報に用いられる、
    ことを特徴とする請求項６に記載のサービス情報処理装置。
11. 少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサに通信接続されるメモリと、を備え、
    前記メモリには、前記少なくとも１つのプロセッサにより実行可能な命令が記憶されており、
    前記命令は、前記少なくとも１つのプロセッサにより実行される場合、請求項１〜５のいずれか一項に記載のサービス情報処理方法を実行させることを特徴とする電子設備。
12. 請求項１〜５のいずれか一項に記載のサービス情報処理方法をコンピュータに実行させるためのコンピュータ命令を記憶した非一過性のコンピュータ可読記憶媒体。
13. コンピュータにおいて、プロセッサにより実行される場合、請求項１〜５のいずれか一項に記載のサービス情報処理方法を実現することを特徴とするプログラム。

Images