マイクロサービス開発の5つの段階

マイクロサービスについて多くのことを聞いたことがあるが、1つだけを行うことに決めていないすべての人々に捧げます。

作成の理由とすべての長所と短所の説明のために、何百もの記事がすでに書かれています-ここで作成と使用の実際的な側面についてお話します。







そのため、多くの熟考の後、この奇跡を行うことにしました。おそらく、マイクロサービスアプローチに適したプロジェクトのタスクを持っているか、あなたの周りの誰もが少数を書いたが、そうではないからです。



この記事では、マイクロサービスの作成方法に焦点を当てておらず、それぞれに独自のメソッドがあります。ここでは、サービスの開発とプロダクションおよびテストへの配信の段階の概要を説明します。

作成プロセスを段階に分けました。 そして、これが最初のものです。

1.挑戦

最初に、マイクロサービスが解決するタスクを決定します。 通常、これはサーバー自体の一部のリソース（データベース、キュー、またはファイルシステム）へのアクセスであり、サービス自体に少しロジックがあります。

遅いストレージから地図上に表示するためのデータリターンを実装する必要があるとします。 レンダリング自体は当然、マイクロサービスクライアントによって行われます。 データは、マップ上のポイントの座標を何らかの見出しで表します。

2.テクノロジー

問題がありますが、現在、そのソリューションのテクノロジを決定しています。 データウェアハウスは低速であり、大量のリクエストを処理できません。 このような場合、 elasticsearchを使用できます-重い負荷に対処し、そのままで破片を作成して複製できます。 その後の検索のために、データを別のスクリプトに入れます。



当社のWheels Roof Marketでは、Goでマイクロサービスを書くのが慣習であり、Goで書いた経験があるので、Goで書くことにしました。 あなたの場合、Nodejs、Java、PHP、または他の、できればコンパイル済みの言語であれば何でも構いません。 テクノロジースタックはサービスのアーキテクチャにも依存するため、この段階でそれについて考え、作業のロジックを検討する必要があります。 マイクロサービスを使用するすべての顧客、特にモバイル開発チーム（ある場合）から情報を収集する価値があります。

3.コーディング

結局のところ、テクノロジとアーキテクチャのスタック、サービスのロジックを犠牲にして、コーディングに直接進みます。 コードベースを一から作成するか（推奨しません）、または何らかの既製のフレームワークを使用するかどうか。





メインのサービスメソッドに加えて、http経由でサービス情報を返す特別な統計メソッドを説明します。マイクロサービスバージョン、処理されたリクエストの数とコード、および起動日は、サービス目的、特にヘルスチェックに使用されます。 さまざまな環境（開発、テスト、実稼働）でマイクロサービスを実行できるようにするには、各環境の構成を作成する必要があります。

4.ドキュメント

コードの主要部分を記述した後、サービスのドキュメントに進みます。これは最も重要な部分であるためです 。 ドキュメントはなく、サービスはありません 。 マイクロサービスのすべての機能について説明します。 これらの目的のためには、プロジェクトのルートで同期更新用のReadmeファイルを作成するのが最適です。 または、誰かがきれいに愛している場合は、 sw歩を適用することができます。



原則として、この段階で、コードの記述、ドキュメントの記述、および（正直に）テストを行ったため、マイクロサービスの開発が完了したと言えます。 しかし、実際にはそうではありません。 最も重要なので、私の謙虚な意見では、本番環境へのサービス提供の問題は解決されていません。 そして今、私たちは最後の段階-配達に来ました。

5.配送

これらの目的のために、CIマネージャーとDocker Swarmテクノロジーを使用します。

Bambooの観点からアセンブリについて説明します（自宅で使用しているため）。



アセンブリサイクルには、2つの関連するビルドプランが含まれます。 1つ目は、リポジトリから取得したマイクロサービスソースコードからバイナリファイルをコンパイルすることです。 コンパイルは、必要なGoのバージョンを持つ特別なコンテナで行われます。 最前線では、実行可能なバイナリを含むアーティファクトがあります。 最初の計画が正常に完了した直後に、従属（2番目の）計画が開始されます。 バックグラウンドで-サービス自体、その構成、および別のリポジトリからの展開パラメーターを使用して、Dockerイメージが準備されています。



便宜上、マスターブランチで変更が発生したときにアセンブリが自動的に開始されるように、最初のビルドプランを構成します。



次に、マイクロサービスを展開するための展開プロジェクトを作成および構成する必要があります。 このプロジェクトでは、テストと本番の2つの環境について説明します。

展開は、松葉杖のpython-deploiterを介して実行されます

展開パラメーターは、環境に応じて、展開するクラスター（現時点では4つあります）、レプリカの数、プロセッサーの制限、メモリーの制限などを示します。



各レプリカが正常にデプロイされた直後に、レプリカの起動が試行され、失敗した場合、残りの実行中のレプリカを配置しないようにデプロイメントが停止します。



マスターブランチが正常にアセンブルされると、テストの展開が自動的に実行されるように、テスト環境のトリガーを構成します。



マスターブランチを変更すると、バイナリアセンブリが開始され、イメージが構築されます。その後、テスト環境が自動的に展開され、実稼働環境では特別な[ 展開]ボタンがアクティブになります。



個人的な経験から言えば、マイクロサービスの主な問題と複雑さは本番サーバーへの配信であると言いますが、ドッカーと友達である人がいれば、問題は何倍も少なくなります。 以前は、展開にdebパッケージを使用していたため、サービスが更新されるたびに「手動作業」を行う必要があり、新しいパッケージのインストール後にサービスを再起動する必要があるため、サービスが低下しました。



マイクロサービスの開発の5つの主要な段階を特定することができました。これがあなたに利益をもたらし、私たちの開発者が従事しているあなたの人生に新しい命を吹き込むことを願っています。