特表2024-536709 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ 中興通訊股▲ふん▼有限公司の特許一覧

特表2024-536709サービス間依存関係を決定する方法及び装置、電子機器、並びにコンピュータ可読な記憶媒体

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-10-08

(54)【発明の名称】サービス間依存関係を決定する方法及び装置、電子機器、並びにコンピュータ可読な記憶媒体

(51)【国際特許分類】

G06F 9/445 20180101AFI20241001BHJP

【ＦＩ】

G06F9/445 120

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024513463

(86)(22)【出願日】2022-08-05

(85)【翻訳文提出日】2024-02-28

(86)【国際出願番号】 CN2022110599

(87)【国際公開番号】W WO2023029882

(87)【国際公開日】2023-03-09

(31)【優先権主張番号】202111005086.3

(32)【優先日】2021-08-30

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡ

(71)【出願人】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥＰｌａｚａ，ＫｅｊｉＲｏａｄＳｏｕｔｈ，Ｈｉ－ＴｅｃｈＩｎｄｕｓｔｒｉａｌＰａｒｋ，ＮａｎｓｈａｎＳｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ５１８０５７Ｃｈｉｎａ

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】倪進權

(72)【発明者】

【氏名】李星

(72)【発明者】

【氏名】蒲艦舸

(72)【発明者】

【氏名】徐代剛

(72)【発明者】

【氏名】李小進

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AE44

5B376AE52

(57)【要約】

本願は、マイクロサービスコードファイルに対しセマンティック認識を行い、サービス間呼び出し要求を特徴付けるコードステートメントで構成されるオブジェクトコードセグメントを決定するステップと、サービス間呼び出し要求を特徴付けるターゲットパラメータをコードステートメントから抽出するステップと、サービス間依存関係をターゲットパラメータに基づいて決定するステップとを、含む、サービス間依存関係を決定する方法を開示する。本願は、サービス間依存関係を決定する装置、電子機器、並びにコンピュータ可読な記憶媒体を更に開示する。

【特許請求の範囲】

【請求項1】

マイクロサービスコードファイルに対しセマンティック認識を行い、サービス間呼び出し要求を特徴付けるコードステートメントで構成されるオブジェクトコードセグメントを決定するステップと、
前記サービス間呼び出し要求を特徴付けるターゲットパラメータを前記コードステートメントから抽出するステップと、
サービス間依存関係を前記ターゲットパラメータに基づいて決定するステップとを、含む、サービス間依存関係を決定する方法。

【請求項2】

マイクロサービスコードファイルに対しセマンティック認識を行い、オブジェクトコードセグメントを決定する前記ステップは、
前記マイクロサービスコードファイルのうち前記サービス間呼び出し要求を発信するためのネットワーク呼び出しステートメントを、セマンティックモデルを採用して認識するステップと、
前記サービス間呼び出し要求を特徴付ける前記コードステートメントを、前記ネットワーク呼び出しステートメントに基づいて取得し、前記コードステートメントで前記オブジェクトコードセグメントが構成されるステップと、を含む請求項1に記載の方法。

【請求項3】

前記マイクロサービスコードファイルのうち、前記サービス間呼び出し要求の呼び出しタイプを特徴付ける第一パラメータと、前記コードステートメントを取得するために着目すべき第二パラメータとを、セマンティックモデルを採用して認識するステップを更に含み、
前記サービス間呼び出し要求を特徴付ける前記コードステートメントを、前記ネットワーク呼び出しステートメントに基づいて取得する前記ステップは、
前記サービス間呼び出し要求を特徴付ける前記コードステートメントを、前記ネットワーク呼び出しステートメントと前記第二パラメータとに基づいて取得することを更に含む請求項2に記載の方法。

【請求項4】

前記サービス間呼び出し要求を特徴付ける前記コードステートメントを、前記ネットワーク呼び出しステートメントと前記第二パラメータとに基づいて取得する前記ステップは、
前記ネットワーク呼び出しステートメントを起点として、前記ネットワーク呼び出しステートメントに含まれた前記第二パラメータをテイントとするステップと、
前記第二パラメータに基づいて制御フローに従ってテイント伝播を行い、前記第二パラメータに関連する第三パラメータを認識し、また、前記第三パラメータをテイントとし、プリセット条件に達するまでテイント伝播過程を前記第三パラメータに基づいて実行し続けるステップと、
テイント伝播過程において汚染されたパラメータのコード式を、前記サービス間呼び出し要求を特徴付けるコードステートメントとして抽出するステップと、を含む請求項3に記載の方法。

【請求項5】

前記テイント伝播過程は、
前記マイクロサービスコードファイルにおける代入文に基づき、前記代入文の左辺式における汚染されたパラメータから右辺式におけるパラメータにテイントを渡すステップを含む請求項4に記載の方法。

【請求項6】

前記テイント伝播過程は、
前記マイクロサービスコードファイルにおける呼び出しステートメントに基づいて、前記メソッドパラメータに対応するメソッドを呼び出す呼び出しステートメントにおけるパラメータに、汚染されたメソッドパラメータからテイントを渡すステップを含む請求項4に記載の方法。

【請求項7】

前記テイント伝播過程は、
前記マイクロサービスコードファイルにおける返却値に基づき、前記返却値が汚染された場合、前記返却値の対応メソッドのreturnステートメントから開始して、前記対応メソッドの方法体内でテイント伝播を行うステップを含む請求項4に記載の方法。

【請求項8】

マイクロサービスアプリケーション内部のサービス間通信方式に基づいてサービス間呼び出しライブラリを取得するステップと、
サービス間呼び出しライブラリに基づいてセマンティックモデルを作成するステップとを、更に含む請求項1～7の何れか1項に記載の方法。

【請求項9】

マイクロサービスコードファイルに対しセマンティック認識を行い、サービス間呼び出し要求を特徴付けるコードステートメントで構成されるオブジェクトコードセグメントを決定するように配置されたコードセグメント決定モジュールと、
前記サービス間呼び出し要求を特徴付けるターゲットパラメータを前記コードステートメントから抽出するように配置されたパラメータ抽出モジュールと、
サービス間依存関係を前記ターゲットパラメータに基づいて決定するように配置された依存関係決定モジュールと、を備える、サービス間依存関係を決定する装置。

【請求項10】

少なくとも1つのプロセッサと、
少なくとも1つのコンピュータプログラムが記憶された記憶装置であって、前記少なくとも1つのコンピュータプログラムが前記少なくとも1つのプロセッサによって実行された場合、前記少なくとも1つのプロセッサに請求項1～8のうちの何れか1項に記載のサービス間依存関係を決定する方法を実現させる記憶装置と、
前記プロセッサと前記メモリの情報対話を実現するように配置された、前記プロセッサと前記メモリとの間で接続された少なくとも1つのI/Oインタフェースと、を備える電子機器。

【請求項11】

コンピュータ可読な記憶媒体であって、コンピュータプログラムが記憶され、前記コンピュータプログラムがプロセッサによって実行された場合、請求項1～8のうちの何れか1項に記載のサービス間依存関係を決定する方法を実現するコンピュータ可読な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願の相互参照］
本願は2021年8月30日に提出された中国特許出願第202111005086.3号の優先権を主張し、当該中国特許出願の全ての内容を援用によって引用することとする。

【0002】

［技術分野］
本願は通信技術に関するものであり、特に、サービス間依存関係を決定する方法及び装置、電子機器、並びにコンピュータ可読な記憶媒体に関するものである。

【背景技術】

【0003】

モノリシックアプリケーションのペインポイントを解決するため、マイクロサービスはすでに、クラウドネイティブシステムの重要な定義となっており、かつ、その規模も爆発的に拡大している。マイクロサービスアーキテクチャとそのアプリケーション規模の拡大とに伴い、セキュリティ上問題も生じている。例えば、あるクラウドネイティブシステムにはA、B、Cの3つのサービスがあり、かつAはBとCにのみ業務を依存しており、BはCに業務を依存しているとすると、3つのサービスに対応するアクセス権はそれぞれ、Aはどのサービスからもアクセスできない、BはAからのみアクセスできる、CはAとBからアクセスできる、というように設定するべきである。

【0004】

関連技術では、マイクロサービス間の依存関係は、通常、複数のマイクロサービスのマイクロサービスコードファイルを取得し、マイクロサービスコードファイルから複数のマイクロサービスのうちのマイクロサービス毎の初期化情報を認識し、初期化情報からターゲットサービスの依存関係を抽出する、という方法で決定されている。初期化情報は、サービスによって実行される依存パッケージと、サービス初期化に関連するマイクロサービスとを含んで良い。しかしながら、最終的に得られるサービス間依存関係の完全性は高くはない。

【発明の概要】

【0005】

第1の態様によれば、本願の実施形態は、
マイクロサービスコードファイルに対しセマンティック認識を行い、サービス間呼び出し要求を特徴付けるコードステートメントで構成されるオブジェクトコードセグメントを決定するステップと、
前記サービス間呼び出し要求を特徴付けるターゲットパラメータを前記コードステートメントから抽出するステップと、
サービス間依存関係を前記ターゲットパラメータに基づいて決定するステップとを、含む、サービス間依存関係を決定する方法を提供する。

【0006】

第2の態様によれば、本願の実施形態は、
マイクロサービスコードファイルに対しセマンティック認識を行い、サービス間呼び出し要求を特徴付けるコードステートメントで構成されるオブジェクトコードセグメントを決定するように配置されたコードセグメント決定モジュールと、
前記サービス間呼び出し要求を特徴付けるターゲットパラメータを前記コードステートメントから抽出するように配置されたパラメータ抽出モジュールと、
サービス間依存関係を前記ターゲットパラメータに基づいて決定するように配置された依存関係決定モジュールと、を備える、サービス間依存関係を決定する装置を提供する。

【0007】

第3の態様によれば、本願の実施形態は、
1つ又は複数のプロセッサと、
1つ又は複数のコンピュータプログラムが記憶された記憶装置であって、前記1つ又は複数のコンピュータプログラムが前記1つ又は複数のプロセッサによって実行された場合、前記1つ又は複数のプロセッサに第1の態様に記載のサービス間依存関係を決定する方法を実現させる記憶装置と、
前記プロセッサと前記メモリの情報対話を実現するように配置された、前記プロセッサと前記メモリとの間で接続された1つ又は複数のI/Oインタフェースと、を備える電子機器を提供する。

【0008】

第4の態様によれば、本願の実施形態は、コンピュータ可読な記憶媒体であって、コンピュータプログラムが記憶され、前記コンピュータプログラムがプロセッサによって実行された場合、第1の態様に記載のサービス間依存関係を決定する方法を実現するコンピュータ可読な記憶媒体を提供する。

【図面の簡単な説明】

【0009】

【図1】図1は、本願実施形態によって提供されるサービス間依存関係を決定する方法のフローチャートを示す図である。

【図2】図2は、本願実施形態によって提供されるサービス間依存関係を決定する方法のフローチャートを示す図である。

【図3】図3は、本願実施形態によって提供されるサービス間依存関係を決定する方法のフローチャートを示す図である。

【図4】図4は、本願実施形態によって提供されるサービス間依存関係を決定する装置の構成を示す図である。

【図5】図5は、本願実施形態によって提供される電子機器の構成を示す図である。

【発明を実施するための形態】

【0010】

本願の技術案を当業者がより良く理解するために、本願によって提供されるサーバを、図面を組み合わせて以下に詳細に説明する。

【0011】

以下、図面を参照して例示的な実施形態について詳細に説明するが、前記例示的な実施形態は異なる形態で具現化されてもよく、本明細書に記載された実施形態に本開示が限定されると解釈すべきではない。これら実施形態の提供はむしろ、本願を徹底して完全なものにし、当業者に本願の範囲を十分に理解させることを目的とする。

【0012】

本明細書で使用される用語「及び/又は」には、1つ又は複数の関連する列挙項目の任意又はすべての組み合わせが含まれる。

【0013】

本明細書にて使用される用語は特定の実施形態について説明するためのものにすぎず、本願を制限する意図はない。本明細書にて使用される「一つの」と「当該」という単数形も、前後から明らかでない限り複数形を含むことも意図される。また、本明細書にて「含む」及び／又は「…からなる」という用語が使用したときは、特定の特徴、全体、ステップ、オペレーション、素子及び/又はコンポーネントの存在を指定するが、1つ又は複数の他の特徴、全体、ステップ、オペレーション、素子、コンポーネント、及び／又はそれらのグループの存在するか又は追加できることを除外しないことが、更に理解されるであろう。

【0014】

本明細書で説明する実施形態は、本願の理想的な模式図の助けを借りて、平面図及び／又は断面図を参照して説明することができる。従って、例示は、製造技術及び／又は公差に基づいて変更され得る。従って、実施形態は、図面に例示されたものに限定されず、製造工程に基づいて形成された構成の修正を含む。従って、図面に例示されたゾーンは、例示的な属性を有し、図に示されたゾーンの形状は、要素のゾーンの具体的な形状を例示するが、限定するものではない。

【0015】

本明細書で使用されるすべての用語（技術用語及び科学用語を含む）は、特に限定されない限り、当業者が一般的に理解するのと同じ意味を有するものとする。また、常用辞典にて限定されるそれら用語は、関連技術案及び本願の背景での意味と一致する意味を有し、本明細書にて明確に定義しない限り、理想的又は過度に形式的な意味を有するとして解釈されないであろうことが更に理解されるであろう。

【0016】

図1は、本願実施形態によって提供されるサービス間依存関係を決定する方法のフローチャートを示す図であり、当該方法の実行本体は、本願実施形態によって提供されるサービス間依存関係を決定する装置であり、この装置は、端末装置（例えば、モバイル端末、タブレット、又はデスクトップコンピュータ）又はサーバに統合され得る。図1に示すように、このサービス間依存関係を決定する方法は次のステップS101～S103を含む。

【0017】

ステップS101：マイクロサービスコードファイルに対しセマンティック認識を行い、サービス間呼び出し要求を特徴付けるコードステートメントで構成されるオブジェクトコードセグメントを決定する。

【0018】

幾つかの実施形態では、マイクロサービスコードファイルは、プロジェクトでソースコードと初期化ファイルが出力されるときに、侵入破壊せず、メッセージを傍受しない方法で取得することができ、このマイクロサービスのコードファイルによってサービス間依存関係を完全に取得することができる。マイクロサービスアプリケーションのコードファイルは、さまざまな形式がある可能性があり、ソースコード、バイトコード、バイナリコードなどであってもよい。本実施形態におけるマイクロサービスのコードファイルの形式は、マイクロサービスアプリケーションで採用されるプログラミング言語の実行過程に関連する。異なるプログラミング言語は、形式の一致しないコードファイルを有し、それに応じて、異なるプログラミング言語は、セマンティック認識分析に最も適したコードファイルの形式も異なる。

【0019】

例えば、下表1に、異なるプログラミング言語での、意味認識分析に最も適したコードファイルの形式を示す。

【0020】

【表1】

【0021】

例えば、Java言語については、現在、バイトコードレベルで動作する成熟した静的解析ツールが多くあり、解析を容易にするために、バイトコードファイルを本実施形態におけるコードファイルとして使用することができる。例えば、go言語は、ソースコードとバイナリコードを本実施形態におけるコードファイルとして使用することができる。ソースコードの他に、サービス間呼出し要求に関連する重要な情報を含む外部ファイル（例えば、.protoファイルとサービス展開ファイル）もあるため、コードファイルとして解析・処理することも可能である。

【0022】

マイクロサービスアプリケーションに対応するコード量は膨大であるため、対応するコード量をすべてスキャン・解析すると、多くの時間とリソースがかかる。したがって、本実施形態では、検索範囲を減らして解析を最適化するために、サービス間依存関係を決定するのに有用なコードステートメントをマイクロサービスコードファイルから認識することができ、すなわち、これらコードステートメントは、サービス間呼び出し要求を特徴付けることができ、かつ、1つのマイクロサービスアプリケーションのうちサービス間の呼び出しは有限であり、すなわち、少量であるため、サービス間呼び出し要求を特徴付けるコードステートメントも有限であり、更に、これら少量のコードステートメントによってサービス間依存関係を迅速かつ正確に決定することができる。

【0023】

ステップS102：サービス間呼び出し要求を特徴付けるターゲットパラメータをコードステートメントから抽出する。

【0024】

コードステートメントはサービス間呼び出し要求を特徴付けるコード式であり、当該コード式には、サービス間呼び出し関係を特徴付けるターゲットパラメータが含まれている。サービス間呼び出し要求のタイプによって、対応するターゲットパラメータも異なる。例えば、下表2に、異なるサービス間呼び出し要求に対応するターゲットパラメータを示す。

【0025】

【表2】

【0026】

ステップS103：サービス間依存関係をターゲットパラメータに基づいて決定する。
ターゲットパラメータには、サービス間の呼び出し関係が含まれる。例えば、HTTP呼び出しとgRPC呼び出しのターゲットパラメータPathは、サービス間の呼び出し関係を特徴付ける呼び出しパスであるため、サービス間依存関係をターゲットパラメータPathに基づいて決定することができる。例えば、TCP呼び出しのターゲットパラメータPortは、サービス間の呼び出し関係を特徴付ける呼び出しポートであるため、サービス間依存関係をターゲットパラメータPortに基づいて決定することができる。

【0027】

下記オブジェクトコードセグメントを例とする。
1 reviews = {
2 "name" : "http://reviews:9080",
3 "endpoint" : "reviews"
4 }
5 @app.route('/api/v1/products/<product_id>/reviews')
6 url = reviews['name'] + "/" + reviews['endpoint'] + "/" + str(product_id)
7 res = requests.get(url, headers=headers, timeout=3.0)。

【0028】

下記ターゲットパラメータを上記オブジェクトコードセグメントに基づいて抽出することができる。

【0029】

{
"type": "HTTP",
"url": "http://reviews:9080/reviews/*",
"path": "/reviews/*",
"method": "GET"
}。

【0030】

当該ターゲットパラメータに基づいて、呼呼び出しのサービスのパスを、http://reviews:9080/reviews/*に決定することができ、更に、呼び出しのサービスを上記サービスのパスに基づいて決定する。

【0031】

決定すべきサービス間依存関係が多い場合、決定された複数のオブジェクトコードセグメントに基づいて統一的な抽出を実行し、サービス間依存関係が記述されたマニフェストファイル（例えばJSONマニフェストファイル）が生成されてよい。処理効率を向上させるために、各オブジェクトコードセグメントをテイント伝播によってスキャンし、更にスキャン結果に基づいてターゲットパラメータを決定してよい。

【0032】

本実施形態では、サービス間依存関係を決定する際に、一方では、マイクロサービスコードファイルが使用され、すべてのサービス間の呼び出し関係がマイクロサービスコードファイルに含まれているため、当該マイクロサービスコードファイルに基づいてサービス間依存関係の完全性を確保することができる。他方では、サービス間呼び出し要求を特徴付けるオブジェクトコードセグメントを、マイクロサービスコードファイルに対しセマンティック認識を行うことで決定することにより、有効なコードセグメントを正確に特定することができ、検索空間が低減され解析が最適化されて、処理効率がさらに向上している。

【0033】

幾つかの実施形態では、図2に示すように、ステップS101はステップAとステップBを含む。

【0034】

ステップA：マイクロサービスコードファイルのうちサービス間呼び出し要求を発信するためのネットワーク呼び出しステートメントを、セマンティックモデルを採用して認識する。

【0035】

サービスがサービス間呼び出し要求を発信する場合、一般的には、対応するコードステートメントがマイクロサービスコードファイルにあり、当該コードステートメントはネットワーク呼び出しステートメントである。本実施形態では、サービス間呼び出し要求を発信するネットワーク呼び出しステートメントを決定するために、予め作成されたセマンティックモデルを採用してマイクロサービスコードファイルに対しセマンティック認識を行う。当該セマンティックモデルは、具体的には以下の実施形態で作成プロセスを詳述するように、マイクロサービスアプリケーション内部のサービス間通信方式に基づいて作成することができる。

【0036】

以下は、ネットワーク呼び出しステートメントを決定するプロセスを、例を挙げて説明する。以下は、import requests及びres=requests.get(url, headers=headers, timeout=3.0)というコードステートメントが含まれたソースコードの一部である。セマンティックモデルを採用することで、上記コードステートメントがサービス間呼び出し要求を発信するために使用されることを認識することができ、更に、res=requests.get(url,headers=headers,timeout=3.0)としてネットワーク呼び出しステートメントを決定する。

【0037】

ソースコードの例を以下に示す。
1 import requests
2 from flask import request, session
…
3 reviews = {
4 "name" : "http://reviews:9080",
5 "endpoint" : "reviews"
6 }
…
7 @app.route('/api/v1/products/<product_id>/reviews')
8 def reviewsRoute(product_id):
9 headers = getForwardHeaders(request)
10 user = session.get('user', ")
11 status, reviews = getProductReviews(product_id, headers)
…
12 def getProductReviews(product_id, headers):
13 try:
14 url = reviews['name'] + "/" + reviews['endpoint'] + "/" + str(product_id)
15 res = requests.get(url, headers=headers, timeout=3.0)。

【0038】

ステップB：サービス間呼び出し要求を特徴付けるコードステートメントを、ネットワーク呼び出しステートメントに基づいて取得し、コードステートメントでオブジェクトコードセグメントが構成される。

【0039】

幾つかの実施形態では、ネットワーク呼び出しステートメントが決定された後、呼び出されたコードステートメントを当該ネットワーク呼び出しステートメントに基づいて決定することができ、呼び出されたコードステートメントに基づいてサービス間呼び出し要求を特徴付けるコードステートメントを取得する。上記ソースコードを例とし、ネットワーク呼び出しステートメントにおいて、res=requests.get(url，headers= headers，timeout=3.0)は、パラメータurlとheadersを含み、これに対応する呼び出しステートメントurl = reviews['name'] + "/" + reviews['endpoint'] + "/" + str(product_id)をパラメータurlに基づいて決定し、またこれに対応する呼び出しステートメントheaders = getForwardHeaders(request)をパラメータheadersに基づいて決定する。呼び出しステートメントheaders = getForwardHeaders(request)におけるパラメータは入力パラメータrequestであるため、呼び出しステートメントのルックアップ過程を終了する。url = reviews['name'] + "/" + reviews['endpoint'] + "/" + str(product_id)におけるパラメータreviewsはメソッドパラメータであるため、これに対応する呼び出しステートメントを以下に更に決定する。

【0040】

3 reviews = {
4 "name" : "http://reviews:9080",
5 "endpoint" : "reviews"
6 } 。

【0041】

メソッドパラメータreviewsにおけるパラメータnameとendpointはいずれも定数であるため、呼び出しステートメントのルックアップ過程を終了する。上記の例のうち、サービス間呼び出し要求を特徴付けるコードステートメントを上記ルックアップ過程に基づいて以下に決定することができる。

【0042】

1 reviews = {
2 "name" : "http://reviews:9080",
3 "endpoint" : "reviews"
4 }
5 @app.route('/api/v1/products/<product_id>/reviews')
6 url = reviews['name'] + "/" + reviews['endpoint'] + "/" + str(product_id)
7 res = requests.get(url, headers=headers, timeout=3.0)。

【0043】

幾つかの実施形態では、認識効率を更に向上させるために、前記ステップS101はステップS104を更に含む。

【0044】

ステップS104：マイクロサービスコードファイルのうち、サービス間呼び出し要求の呼び出しタイプを特徴付ける第一パラメータとコードステートメントを取得するために着目すべき第二パラメータとを、セマンティックモデルを採用して認識する。

【0045】

幾つかの実施形態では、セマンティックモデルが作成された後、セマンティック情報に基づいて当該セマンティックモデルが拡張され、当該セマンティック情報は、サービス間呼び出し要求のタイプを記述するとともに、後続においてコードステートメントのうち注目すべきキーパラメータ（すなわち、第二パラメータ）を取得することを指示する。例えば、当該セマンティックモデルは一つの方法クラスであってよく、上記ソースコードの例に基づいて、セマンティックモデルとして以下の方法クラスを設定することができ、当該方法クラスの例において、当該セマンティックモデルは、第一パラメータ（すなわち、サービス間呼び出し要求のタイプHTTP）、第二パラメータMethodとurlを備える。

【0046】

セマンティックモデル（すなわち、方法クラス）の例は以下のとおりである。
Library: requests
Method: get(url, params=None, **kwargs)
Semantics: HTTP-GET
Key parameters: url (Semantics: HTTP-URL)。

【0047】

これに応じて、ステップBは、サービス間呼び出し要求を特徴付けるコードステートメントを、ネットワーク呼び出しステートメントと第二パラメータとに基づいて取得することを具体的に含むことができる。

【0048】

上記例のソースコードとセマンティックモデルとに基づいて、ネットワーク呼び出しテートメントres=requests.get(url, headers=headers, timeout=3.0) におけるパラメータurlは第二パラメータであり、これに対応する呼び出しテートメントを、パラメータurlだけに基づいて更に決定することができることが考えられる。上記ステップBの実現過程に比べ、パラメータheadersの呼び出し過程を再度ルックアップする必要がなくなり、これにより不要のパラメータの呼び出し過程を減らし、処理効率が更に向上している。

【0049】

幾つかの実施形態では、オブジェクトコードセグメントの認識効率と速度を更に向上させるために、オブジェクトコードセグメントを構成するコードステートメントを、テイント伝播の方式を用いて決定することができ、図3に示すように、ステップBはステップB1～B3を含む。

【0050】

ステップB1：ネットワーク呼び出しステートメントを起点として、ネットワーク呼び出しステートメントに含まれた第二パラメータをテイントとする。

【0051】

上記例のソースコードとセマンティックモデルとに基づき、上記例におけるネットワーク呼び出しステートメントをres=requests.get(url，headers= headers，timeout=3.0)として、相応の第二パラメータをurlとして確定することができ、ネットワーク呼び出しステートメントres=requests.get(url，headers= headers，timeout=3.0)から開始して、第二パラメータurlをテイントとしてテイント伝播を行う。

【0052】

ステップB2：第二パラメータに基づいて制御フローに従ってテイント伝播を行い、第二パラメータに関連する第三パラメータを認識し、また、第三パラメータをテイントとし、第三パラメータに基づいて、プリセット条件に達するまでテイント伝播過程を実行し続ける。

【0053】

制御フローの逆方向それとも順方向に沿ってテイント伝播が行われるかは、当該ネットワーク呼び出しステートメントが呼び出すステートメントなのか、それとも呼び出されるステートメントなのかによって決定され、当該ネットワーク呼び出しステートメントが呼び出しステートメントである場合は、制御フローの逆方向に沿ってテイント伝播が行われ、当該ネットワーク呼び出しステートメントが呼び出されるステートメントである場合は、制御フローの順方向に沿ってテイント伝播が行われる。上記の例のソースコードに基づくと、制御フローの逆方向に沿ってテイント伝播が行われる。テイントは制御フローの逆方向に沿って、ネットワーク呼び出しステートメントにおけるパラメータurl（すなわち、第二パラメータ）から、url = reviews['name'] + "/" + reviews['endpoint'] + "/" + str(product_id)ステートメントにおけるメソッドパラメータreviews（すなわち、第三パラメータ）に渡され、更に、メソッドパラメータreviewsにおける関連パラメータnameとendpointに渡され、テイント伝播過程を終了する。テイント伝播を終了するプリセット条件は、パラメータが定数で割り振られるか、又は入力パラメータからのものである。

【0054】

幾つかの実施形態では、テイント伝播過程において、コードステートメントによってこれに対応するテイント伝播過程は異なり、主に以下の3つの場合がある。

【0055】

第1の場合、マイクロサービスコードファイルにおける代入文に基づいて、代入文の左辺式における汚染されたパラメータから右辺式におけるパラメータにテイントを渡すステップをテイント伝播過程が含む。

【0056】

第2の場合、マイクロサービスコードファイルにおける呼び出しステートメントに基づいて、メソッドパラメータに対応するメソッドを呼び出す呼び出しステートメントにおけるパラメータに、汚染されたメソッドパラメータからテイントを渡すステップをテイント伝播過程が含む。

【0057】

第3の場合、マイクロサービスコードファイルにおける返却値に基づいて、返却値が汚染された場合、返却値の対応メソッドのreturnステートメントから開始して、対応メソッドの方法体内でテイント伝播を行うステップをテイント伝播過程が含む。

【0058】

ステップB3：テイント伝播過程において汚染されたパラメータのコード式を、サービス間呼び出し要求を特徴付けるコードステートメントとして抽出する。

【0059】

上記の例のソースコードとセマンティックモデルとに基づいて、最終的なオブジェクトコードセグメントを以下のように決定することができる。

【0060】

【0061】

幾つかの実施形態では、サービス間依存関係を決定する前記方法は、セマンティックモデルの作成過程を更に備え、当該過程は、マイクロサービスアプリケーション内部のサービス間通信方式に基づいてサービス間呼び出しライブラリを取得することと、サービス間呼び出しライブラリに基づいてセマンティックモデルを作成することと、を備える。

【0062】

同一のマイクロサービスアプリケーション内部のサービス間通信方式は相対的に均一であるため、導入されるサービス間呼び出しライブラリの数も有限である。したがって、これらサービス間通話ライブラリに基づいて、的を絞ったセマンティックモデルのモデリングを行うことで、作業負荷を軽減することができる。例えば、gRPC要求で呼び出されるアプリケーションプログラムインタフェースは、対応する.protoファイルにおいて定義され、どのステートメントが実際にgRPC要求を発信するかを認識するのをサポートするために、当該ファイルの解析によって自動化のモデリングを行って相応のセマンティックモデルを得ることができる。

【0063】

図4は、本願実施形態によって提供されるサービス間依存関係を決定する装置の構成を示す図であり、当該装置は、ソフトウェア又はハードウェアで実装することができ、端末装置又はサーバに統合することができる。図4に示すように、このサービス間依存関係を決定する装置は、コードセグメント決定モジュール201、パラメータ抽出モジュール202と依存関係決定モジュール203を備える。

【0064】

コードセグメント決定モジュール201は、マイクロサービスコードファイルに対しセマンティック認識を行い、サービス間呼び出し要求を特徴付けるコードステートメントで構成されるオブジェクトコードセグメントを決定するように配置される。

【0065】

パラメータ抽出モジュール202は、サービス間呼び出し要求を特徴付けるターゲットパラメータをコードステートメントから抽出するように配置される。

【0066】

依存関係決定モジュール203は、サービス間依存関係をターゲットパラメータに基づいて決定するように配置される。

【0067】

幾つかの実施形態では、コードセグメント決定モジュール201は、ネットワーク呼び出しステートメント認識ユニット2011とコードセグメント決定ユニット2012を備える。

【0068】

ネットワーク呼び出しステートメント認識ユニット2011は、マイクロサービスコードファイルのうちサービス間呼び出し要求を発信するためのネットワーク呼び出しステートメントを、セマンティックモデルを採用して認識するように配置される。

【0069】

コードセグメント決定ユニット2012は、サービス間呼び出し要求を特徴付けるコードステートメントを、ネットワーク呼び出しステートメントに基づいて取得し、コードステートメントでオブジェクトコードセグメントが構成されるように配置される。

【0070】

幾つかの実施形態では、コードセグメント決定モジュール201は、パラメータ認識ユニット2013を更に備える。

【0071】

パラメータ認識ユニット2013は、マイクロサービスコードファイルのうち、サービス間呼び出し要求の呼び出しタイプを特徴付ける第一パラメータとコードステートメントを取得するために着目すべき第二パラメータとを、セマンティックモデルを採用して認識するように配置される。

【0072】

コードセグメント決定ユニット2012は、サービス間呼び出し要求を特徴付けるコードステートメントを、ネットワーク呼び出しステートメントと第二パラメータとに基づいて取得するように具体的に配置される。

【0073】

幾つかの実施形態では、コードセグメント決定ユニット2012は、ネットワーク呼び出しステートメントを起点として、ネットワーク呼び出しステートメントに含まれた第二パラメータをテイントとし、第二パラメータに基づいて制御フローに従ってテイント伝播を行い、第二パラメータに関連する第三パラメータを認識し、また、第三パラメータをテイントとし、プリセット条件に達するまでテイント伝播過程を第三パラメータに基づいて実行し続け、テイント伝播過程において汚染されたパラメータのコード式を、サービス間呼び出し要求を特徴付けるコードステートメントとして抽出するように配置される。

【0074】

幾つかの実施形態では、コードセグメント決定ユニット2012は、マイクロサービスコードファイルにおける代入文に基づいて、代入文の左辺式における汚染されたパラメータから右辺式におけるパラメータにテイントを渡すように具体的に配置される。

【0075】

幾つかの実施形態では、コードセグメント決定ユニット2012は、マイクロサービスコードファイルにおける呼び出しステートメントに基づいて、メソッドパラメータに対応するメソッドを呼び出す呼び出しステートメントにおけるパラメータに、汚染されたメソッドパラメータからテイントを渡すように具体的に配置される。

【0076】

幾つかの実施形態では、コードセグメント決定ユニット2012は、マイクロサービスコードファイルにおける返却値に基づいて、返却値が汚染された場合、返却値の対応メソッドのreturnステートメントから開始して、対応メソッドの方法体内でテイント伝播を行うように具体的に配置される。

【0077】

幾つかの実施形態では、前記サービス間依存関係を決定する装置は、セマンティックモデル作成モジュール204を更に備える。

【0078】

セマンティックモデル作成モジュール204は、マイクロサービスアプリケーション内部のサービス間通信方式に基づいてサービス間呼び出しライブラリを取得し、セマンティックモデルをサービス間呼び出しライブラリに基づいて作成するように配置される。

【0079】

上記の各モジュールの具体的な構成及び動作原理は、方法実施形態における対応説明を参照することができるので、ここでは繰り返さない。

【0080】

本願の実施形態は電子機器を提供し、図5を参照すれば、これは
1つ又は複数のプロセッサ301と、
1つ又は複数のコンピュータプログラムが記憶されたメモリ302であって、前記1つ又は複数のコンピュータプログラムが前記1つ又は複数のプロセッサ301によって実行された場合、前記1つ又は複数のプロセッサ301に、上記サービス間依存関係を決定する方法を実現させる前記記憶装置と、
プロセッサ301とメモリ302の情報対話を実現するように配置された、プロセッサ301とメモリ302との間で接続された1つ又は複数のI/Oインタフェース303と、を備える。

【0081】

ここで、プロセッサ301はデータ処理能力を有する機器であり、これには中央処理装置（CPU）などが含まれるが、これらに限定されない。メモリ302はデータ記憶能力を有する機器であり、ランダムアクセスメモリ（RAM。より具体的にはSDRAM、DDRなど）、リードオンリーメモリ（ROM）、電気的消去可能プログラマブルリードオンリーメモリ（EEPROM）、フラッシュメモリ（FLASH）を含むが、これらに限定されない。I/Oインタフェース（読み書きインタフェース）303は、プロセッサ301とメモリ302との間で接続され、プロセッサ301とメモリ302との間の情報対話を実現するものであり、データバス（Bus）などが含まれるが、これらに限定されない。

【0082】

幾つかの実施形態では、プロセッサ301、メモリ302とI/Oインタフェース303はバスを介して互いに接続され、更にコンピューティングデバイスの他のコンポーネントに接続されている。

【0083】

本願の実施形態は、コンピュータ可読な記憶媒体であって、コンピュータプログラムが記憶され、当該コンピュータプログラムがプロセッサによって実行された場合、サービス間依存関係を決定する上記方法を実現するコンピュータ可読な記憶媒体を提供する。

【0084】

当業者は、上文で出願された方法におけるステップ、システム、装置のうちの機能モジュール／ユニットの全て又はいくつかが、ソフトウェア、ファームウェア、ハードウェア、及びそれらの適切な組み合わせとして実行されてもよいことを理解するであろう。ハードウェア実施形態において、上記の説明で言及した機能モジュール／ユニット間の区分は、必ずしも物理コンポーネントの区分に対応しない。例えば、1つの物理コンポーネントは複数の機能を有してもよく、1つの機能又はステップは幾つかの物理コンポーネントの協働によって実行されてもよい。いくつかの物理コンポーネント又はすべての物理コンポーネントは中央処理装置、デジタル信号プロセッサ、もしくはマイクロプロセッサなどのプロセッサによって実行されるソフトウェアとして、又はハードウェアとして、更には特定用途向け集積回路などの集積回路として実行され得る。このようなソフトウェアは、コンピュータ記憶媒体(又は非一時的媒体)及び通信媒体(又は一時的媒体)を含み得るコンピュータ可読媒体上に分布され得る。当業者によく知られているように、コンピュータ記憶媒体という用語は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータなどの情報を記憶するための任意の方法又は技術で実行される揮発性及び不揮発性、取り外し可能及び取り外し不可能な媒体を含む。コンピュータ記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリ若しくは他のメモリ技術、CD-ROM、デジタル多用途ディスク( DVD )若しくは他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ若しくは他の磁気メモリ、又は所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を含むが、これらに限定されない。また、通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、又は搬送波もしくは他の搬送メカニズムなどの変調データ信号内の他のデータを含み、かつ、任意の情報配信媒体を含み得ることが当業者に知られている。

【0085】

本明細書においては実施形態の例がすでに公開されており、また具体的な用語が用いられているが、それらは一般的な説明的な意味としてのみ使用されており、そう解釈されるべきであり、限定を目的としたものではない。いくつかの実例では、特定の実施形態と組み合わせて説明される特徴、特性及び/又は要素は、別途明確に指摘しない限り、単独で、又は他の実施例にて説明される特徴、特性、及び/又は要素と組み合わせて使用され得ることが当業者に明らかであろう。したがって、添付の請求項によって明らかにされている本願の範囲から逸脱しない限り、様々な形態及び細部における変更が行われ得ることを当業者は理解するであろう。

【図1】