マイクロサービスと共有ライブラリ


9

独立したマイクロサービス(RabbitMqバスで接続)に基づくシステムを設計しています。コードは(少なくとも最初のコンポーネントでは)python(python2とpython3の両方)で記述されます。マイクロサービスとしてリファクタリングして拡張したいビジネスロジックの一部を実装したモノリスアプリケーションがすでにあります。私が心配する1つの質問は次のとおりです。

異なるマイクロサービス間でコードを共有する最良の方法は何ですか。いくつかのマイクロサービスで使用する必要がある共通のヘルパー関数(データ処理、ロギング、構成解析など)があります。

マイクロサービス自体は、個別のプロジェクト(gitリポジトリ)として開発されます。共通ライブラリは、自己完結型プロジェクトとしても開発できます。これらのライブラリをマイクロサービス間で共有するにはどうすればよいですか?

私はいくつかのアプローチを見ます:

  • 各マイクロサービスに必要なライブラリのバージョンをコピーし、必要に応じて更新します
  • 共通ライブラリを内部PyPiにリリースし、それらのライブラリをマイクロサービスの要件の依存関係としてリストします
  • ライブラリリポジトリをgitサブモジュールとして含める

先に進む方法を決定する前に、提案されたアプローチ、ベストプラクティス、過去の経験についてもう少しお読みしたいと思います。提案やリンクはありますか?


私自身もマイクロサービスに精通していません(私の会社は最近、同様のことを始めています)が、答えはわかりませんが、ここに、あなたが説明していることが赤信号であり、「分散モノリス」につながる可能性がある理由に関するプレゼンテーションへのリンクがあります。 。マイクロサービスには、必要な共有ライブラリを含めないでください。実際には、Swagger(現在はOpen APIと呼ばれています)のような明確に定義されたAPIの間でのみ通信する必要があります
キャプテンマン

@CaptainMan:もちろんですが、この単純な関数があるとしますfib(n)(フィボナッチシリーズの実装)。各マイクロサービスでその実装を繰り返す必要はありません。それはutilsライブラリに属します(機能とバグ修正のためにバージョン管理されています)。これは分散モノリスではなく、単なる共通機能のレイヤーです。私の質問は、このレベルを実装レベルでどのように処理するかです。
dangonfast

私たちのマイクロサービスは、ライブラリを共有して、システム内の他のすべてのマイクロサービスと同じ方法で通信できるようにします。非共有ライブラリでそれを行うことがどのように可能になるのかはわかりません。最低限、誰でもいくつかのXML / JSON / etc操作ライブラリが必要になります。私はまだそのプレゼンテーションを見ていませんが、私が考えているものよりも「共有ライブラリ」のより具体的な意味を考えていましたか?
Ixrec

1
@ jeckyll2hide C ++を使用していますが、このインフラストラクチャは2番目の箇条書きとほぼ同じです。個別のリポジトリ、依存関係の宣言、ビルド時に依存関係を見つける方法を知っている標準ビルドシステムなど
Ixrec

1
私はダミーのように感じます、あなたの質問は、具体的にはライブラリを共有するマイクロサービスについてではなく、チームのライブラリをチームと共有する方法について本当に尋ねています。回答を投稿するのに十分な知識があります。
キャプテンマン

回答:


5

あなたの2番目のオプションは間違いなく行く方法です。一般的なライブラリを分割して、ローカルのPyPiサーバーにインストールします。

オプション1は恐ろしいものです。ライブラリの改善は、それを使用できる他の人に広めるのが難しいためです。

オプション3はオプション1と同様です。

一般的なパターンは、Jenkinsをセットアップして、ライブラリリポジトリのマスターにプッシュすると、Pythonビルドを実行してPyPiリポジトリに自動的にアップロードするようにすることです。このビルドスクリプトを作成したら、ライブラリをパッケージ化してPyPiに手動でアップロードすることを心配する必要はありません。また、このオプションを使用すると、すべてのライブラリの更新がすぐに利用可能になり、他のマイクロサービスにアップグレードできる可能性があります。

独自のPyPiサーバーの設定はとても簡単です。このガイドが好き


1
私はオプション2が最良であることを同意するが、サブモジュールとオプション3は、オプション1よりもオプション2をはるかに一般的であり
8bittree

@ 8bittree:はい、オプション3はオプション2に似ていますが、gitサーバー(「中央」リモート)をパッケージ配布メカニズムにすることができます。一方では、(依存管理)に関係のない何かのためにgitを使用していますが、他方では、コンポーネントの数を減らしています(プライベートPyPiは不要)
dangonfast

2

Pythonの人ではありませんが、PyPiサーバーが最良のオプションのようです。すばやくグーグルすると、チームのJava jarにNexusリポジトリを作成するのに似ているように見えます。

選択した依存関係管理ツールが動作する(読み取りと展開)ことができる何らかの中央リポジトリ(オフィス/チーム)に展開されている限り、これは適切なオプションです。

オプション1は本当に最悪です。依存関係を手動で処理する必要はありません。それは苦痛です。大学でMavenについて知る前に、Gitが複雑すぎると思ったとき、すべてのコードのマージからクラスパスの設定、依存関係の取得まで、すべてを手動で行いました。それは苦痛でした。特に、効率が重要である作業環境では、誰もそのトラブルのほんの一部でも経験してほしくありません。

オプション3はおそらく正常に動作しますが、ローカルのPyPiに比べて実際の利点はありません(セットアップが簡単な場合があるかもしれませんが、実際の依存関係管理システムの利点ははるかに優れています)。


1

まず第一に、モノリスをマイクロサービスに分割することは常に困難です。理由については、分散データ管理-データベースをマイクロサービスにカプセル化するをご覧ください。

とは言っても、比較的健全なやり方を行うにはいくつかのレシピがあります。それらの1つはhttp://12factor.net/です。つまり、各ライブラリとアプリケーションを個別に維持し、依存関係を明示的に管理する必要があるということです。そのルートを使用する場合は、すべての依存関係を最新のものに更新する単純なコマンドを用意し、各マイクロサービスに対して定期的に実行することを強くお勧めします。本番環境でライブラリのバージョンをロックダウンする適切なリリースプロセスを用意することが重要です。しかし、あなたは本当に、本当に本当に、依存関係が古くなり、そこに何があるのか​​分からない状態になりたくありません。

また、バッキングライブラリをできる限りタイトで集中したものにすることに焦点を当てます。簡単に共有できるようにコアライブラリにコンテンツを追加し始めるのは自然な流れです。そうすれば、既存のスパゲッティのボール全体を共有ライブラリーにすばやく引き寄せて、現在持っている混乱に効果的に戻ることができます。したがって、他の方法で過剰修正することをお勧めします。


0

Pythonパッケージの依存関係ファイルから、ライブラリを含むプライベートGitHubリポジトリを直接指すことで、サーバーレスに移行できるはずです。PipenvとPoetはどちらもこれをサポートしていると思います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.