HighLoad ++ 2016カンファレンスで、M-Tech開発マネージャーのVadim Madison氏は、100のマイクロサービスが膨大な数に思えたシステムから、数千のマイクロサービスが一般的な忙しいプロジェクトへの成長について語りました。



私のレポートのトピックは、かなり忙しいプロジェクトで本番環境でマイクロサービスを開始した方法です。 これは一種の集約された経験ですが、私はM-Techで働いているので、私たちが何者であるかについて少し話させてください。



要するに、私たちはビデオ出力に取り組んでいます-私たちはリアルタイムでビデオを提供します。 NTV-PlusおよびMatch TVのビデオプラットフォームです。 これらは、5分でリゾートに行く30万人のユーザーです。 これは1時間あたり300テラバイトのコンテンツです。 これはとても興味深い仕事です。 これすべてを提供する方法は？



この話は何ですか？ これは、私たちがどのように成長し、プロジェクトがどのように発展し、どのようにその部分のいくつかを再考したか、ある種の相互作用についてでした。 とにかく、これはプロジェクトをスケールアップすることです。なぜなら、それはすべて、より多くの負荷に耐え、顧客にさらに多くの機能を提供すると同時に、主要な機能を失うことなく落ちないからです。 一般的に、クライアントが満足するように。 さて、私たちが行った道について少し。 どこから始めましたか。







Dockerクラスターに2台のサーバーがある場合の開始点、ある種の開始点を次に示します。 次に、データベースは同じクラスターで起動されました。 私たちのインフラストラクチャにはそのようなハイライトはありませんでした。 インフラストラクチャは最小限でした。







インフラストラクチャの基本を見ると、これはコード、アセンブリなどを配信するシステムとしてのDockerとTeamCityです。



次のマイルストーン-私が道の真ん中と呼ぶもの-はかなり深刻なプロジェクトの成長でした。 すでに80台のサーバーがあったとき。 特別なマシン上のデータベース専用の専用クラスターを構築したとき。 CEPHベースの分散ストレージへの移行を開始したとき。 サービスの相互作用を再検討する時が来たのではないかと考え始めたとき、監視システムを変更する時が来たという考えに近づきました。



まあ、実際に私たちが今来たもの。 Dockerクラスターには既に数百のサーバーがあります-実行中のマイクロサービスの数百。 これで、システムをデータバスレベル、システムの論理的分離レベルで特定のサービスサブシステムに分割し始めています。 これらのマイクロサービスが多すぎると、サービスをよりよく理解するためにシステムを分割し始めました。







画面に図が表示されます。 これは、システムの一部です。 これは、ビデオをスライスできるようにするものです。 6か月前にRIT ++で同様のスキームを示しました。 その後、私の意見では、17のグリーンマイクロサービスがありました。 現在28個ありますが、概算で見ると、これはシステムの1/20です。 おおよそのスケールを想像できます。

詳細

興味深い点の1つは、サービス間の転送です。 古典的には、輸送は可能な限り効率的でなければならないという事実から始まります。 また、それについて考え、protobufがすべてであると判断しました。



次のようになりました。







Load Balancerを介したリクエストは、最前線のマイクロサービスに届きます。 これは、フロントエンド、またはAPIを直接提供するサービスであり、JSONを介して機能します。 また、内部サービスへのリクエストはprotobufを経由しました。



プロトブフ自体は非常に良いものです。 それは本当にメッセージングの特定のコンパクトさを提供します。 現在、最小限のオーバーヘッドでデータのシリアライズとデシリアライズを可能にする非常に高速な実装がすでにあります。 条件付きで型指定された要求と考えることができます。



しかし、マイクロサービスのコンテキストを見ると、サービス間で一種の独自プロトコルを取得していることがわかります。 1つ、2つ、または5つのサービスがある限り、各マイクロサービスに対してコンソールユーティリティを簡単に発行できます。これにより、特定のサービスにアクセスし、それが返されることを確認できます。 彼が何かを鈍らせた場合-それをヤンクして見ます。 これにより、これらのサービスのサポートがサポート面で複雑になります。



ある段階まで、これは重大な問題ではありませんでした-多くのサービスはありませんでした。 さらに、GoogleのメンバーはgRPCを発表しました。 原則として、当時の私たちの目的のために、彼は私たちが必要とするすべてのことをしていたことがわかりました。 ゆっくりと移行しました。 そしてバム-別のことがスタックに現れました。







実装のかなり興味深い詳細もここにあります。 これはHTTP / 2に基づいています。 これは、箱から出してすぐに動作するものです。 非常に動的な環境がない場合、インスタンスが変更されない場合、車の周りを十分に頻繁に移動しないでください。これは一般に良いことです。 さらに、現時点では、サーバーとクライアントの両方の言語をサポートしています。



さて、マイクロサービスのコンテキストでそれを見ると。 一方で、物事は良いことですが、他方では、それ自体が物事です。 ログを単一システムに集約するためにログの標準化を開始した場合、便利な形式でgRPCからログを直接取得できないという事実に直面しました。



その結果、独自のロギングシステムを作成し、gRPCに組み込むという結論に達しました。 彼女はgRPCを介して発行されたメッセージの解析を行い、それらを思いついたので、これを通常のロギングシステムに入れることができました。 さらに、サービスとこのサービスのタイプを最初に記述してからコンパイルする状況に加えて、サービス間の依存関係が増加します。 マイクロサービスの場合、これは問題であり、バージョニングの複雑さと同じです。



おそらく既に推測したように、最終的には、JSONについて考え始めたという結論に達しました。 そして、私たちは長い間、いくつかのコンパクトな条件付きバイナリプロトコルの後、同じことについて書いたDailyMotion連中からの記事に出くわすまで、突然JSONに戻るとは信じていませんでした。 JSON、誰もがそれを調理する方法を知っています、なぜ私たちは自分自身のために追加の困難を作成するのですか？」







その結果、特定の実装でgRPCからJSONに徐々に移行し始めました。 つまり、はい、HTTP / 2を残し、JSONで動作するのに十分な速さで実装しました。



私たちが持っているすべてのパンを手に入れました。 cURLを介してサービスにアクセスできます。 テスターはPostmanを使用しており、それらも正常に機能しています。 これらのサービスを使用するどの段階でも、すべてが簡単になりました。 これは、一方では物議を醸す決定であり、他方では、メンテナンスの面で非常に役立ちます。



概して、JSONを見ると、現時点でそれを示すことができる唯一のマイナス点は、この記述のコンパクトさの欠如です。 これらの30％は、統計によると、同じMessagePackまたは他の何かとの差であり、実際、測定値によると、差はそれほど大きくなく、サポートされているシステムについて話すときも、それほど重大ではありません。



さらに、JSONへの移行に伴い、追加のパンが追加されました。 たとえば、プロトコルのバージョン管理など。 ある時点で、プロトコルの新しいバージョンを説明しているのと同じprotobufを通じて状況が発展し始めました。 したがって、この特定のサービスの消費者である顧客もそれに移動する必要があります。 数百のサービスがある場合、それらの10％でさえ移動するはずです。 これはすでに大きなカスケード効果です。 1つのサービスで変更があり、別の10を再実行する必要があります。



その結果、このサービスの開発者が5番目、6番目、7番目のバージョンをリリースしたときに状況が発生し始めましたが、実際には、関連するサービスの開発者には期限と優先順位があるため、実稼働の負荷は依然として4番目になります。 単にサービスを継続的に再構築したり、新しいバージョンのプロトコルに移行したりすることはできません。 実際に新しいバージョンがリリースされたことが判明しましたが、需要はありません。 しかし、古いバージョンのバグは、いくつかのあいまいな方法で実装する必要があります。 これはサポートを複雑にしました。



その結果、プロトコルバージョンの作成を中止したという結論に達しました。 プロパティを追加できる基本バージョンを修正しましたが、非常に限られた制限内です。 そして、消費者サービスはJSONスキームを使用し始めました。



これは次のようになります。







1、2、3の代わりに、バージョン1とそれに適用されるスキームがあります。







以下は、当社のサービスからの典型的な回答です。 これはコンテンツマネージャーです。 彼は放送情報を提供しました。 これは、たとえば、消費者の1人の図です。







ここで最も興味深い行は一番下の行で、必要なブロックがあります。 見ると、このサービスは実際にこのすべてのデータの4つのフィールド（id、content、date、status）だけを必要としていることがわかります。 このスキームを実際に適用する場合、最終的に顧客サービスはこのデータのみを必要とします。







これらは、プロトコルの最初のバージョンのすべてのバリエーションのすべてのバージョンに実際にあります。 これにより、新しいバージョンへの移行が簡単になりました。 私たちは新しいリリースをリリースし始め、それらへの消費者の移行は大幅に簡素化されました。



マイクロサービス、および一般的にはシステムについて話すときに生じる次の重要な瞬間。 マイクロサービスでは、何よりも強くて速いと感じるだけです。 これらは、システムが不安定になる状況です。



1-2サービスのコールチェーンがある場合、特別な問題はありません。 モノリシックアプリケーションと分散アプリケーションの間にグローバルな違いはありません。 しかし、チェーンが5〜7に成長すると、ある時点で何かが落ちました。 なぜ落ちたのか、どうしたらいいのか、あなたは本当に知りません。 デバッグは非常に困難です。 デバッガをオンにしたモノリシックアプリケーションのレベルで、手順を実行してこのエラーが見つかった場合、ネットワークの不安定性、負荷がかかった状態での不安定なパフォーマンスなどがあります。 そして、そのようなもの-そうしたノードの束を備えた分散システムでは、非常に顕著になります。







それから、最初は古典的な方法で行った。 私たちは、すべてを監視し、何がどこで壊れるかを理解し、どうにかして迅速に対処しようとすることにしました。 マイクロサービスからメトリックを送信し、それらを単一のデータベースに収集し始めました。 Diamondを介してマシンのデータを収集し始めました。これは、Advisorを介して行われます。 Dockerコンテナーに関する情報の収集を開始し、これらすべてをInfluxDBにマージして、Grafanaでダッシュボードを構築しました。







また、インフラストラクチャにはさらに3つのブロックがあり、徐々に成長しています。



はい、私たちは私たちに何が起こっているかをより意識するようになりました。 何かがバラバラになったという事実に、私たちはより迅速に対応し始めました。 しかし、それはこれから離れることを止めませんでした。



奇妙なことに、マイクロサービスアーキテクチャの主な問題は、不安定なサービスがあることです。 動作しますが、動作しません。これには多くの理由があります。 サービスが過負荷になり、追加の負荷を送信するまで、しばらくの間サービスは停止します。 しばらくして、彼がすべてにサービスを提供していないという事実により、負荷が彼から落ち、彼は再びサービスを開始します。 このような跳躍は、そのようなシステムを維持するのが非常に難しく、何が悪いのかを理解するのが難しいという事実につながります。



その結果、次のようにジャンプするよりも、このサービスが落ちる方が良いという結論に徐々に達しました。 この理解により、サービスの実装方法に対するアプローチを変え始めたという事実に至りました。



重要なポイントの最初。 各サービスへの着信リクエストに制限を導入し始めました。 各サービスは、顧客にどれだけサービスを提供できるかを知り始めました。 彼はどのようにこれを知っているのか、少し後で説明します。 この制限を超えているか、その境界の近くにあるすべての要求は、彼が受け入れるのをやめます。 正直な503 Service Unavailableを発行します。 彼に対処する人は誰でも、別のノードを選択する必要があることを理解しています-このノードはサービスを提供できません。



したがって、システムに何か問題がある場合、リクエスト時間を短縮します。 一方、その安定性は向上します。



第二の瞬間。 レート制限が宛先サービスの側にある場合、どこでも導入し始めた2番目のパターンはサーキットブレーカーです。 これは、大まかに言えば、クライアントに実装するパターンです。



サービスAは、可能な限りアクセスポイント、たとえばサービスBの4つのインスタンスを持っています。そこで、彼はレジストリに行き、「これらのサービスのアドレスを教えてください」と言いました。 それらを4個手に入れました。 私は最初のものに行きました、彼はすべてが大丈夫だと彼に答えました。 サービスは「はい」とマークされているので、そこに行くことができます。 ラウンドロビンによると、彼は訴えをばらまきます。 第二に行った、彼は適切な時間に彼に答えなかった。 それだけです。しばらくの間彼を禁止し、次へ進みます。 これは、たとえば、理由に関係なく、不正なバージョンのプロトコルを返します。 彼も彼を禁止します。 4番目に進みます。



その結果、サービスの50％が得られ、彼らは本当に彼がクライアントにサービスを提供するのを助けることができます。 彼はこれら二つに行きます。 なんらかの理由で彼に合わなかった二人は、しばらく禁止します。



これにより、作業全体の安定性を大幅に向上させることができました。 サービスに何か問題があります。それを撮影し、サービスが撮影されたというアラートが発生し、さらに何が間違っているのかを見つけます。



Circuit Breakerパターンの導入に対応して、インフラストラクチャにもう1つあります-これはHystrixです。







Netflixのスタッフは、このパターンのサポートを実装しただけでなく、システムに問題があるかどうかを理解する方法を明確にしました。







ここで、この円のサイズは、他のユーザーと比較したトラフィック量を示しています。 色は、システムの程度を示します。 緑の円がある場合は、おそらく、すべてが順調です。 赤の場合-すべてがバラ色ではありません。



サービスを完全に撮影する必要があるときは、このように見えます。 スイッチが機能しました。







私たちは、システムが多少なりとも安定していることを達成しました。 各サービスのインスタンスが少なくとも2つあるため、どちらかを起動して切り替えることができます。 しかし、これは私たちのシステムで何が起こっているのかを理解するものではありませんでした。 リクエストの実行中に途中で何かが落ちた場合、どのようにこれを理解するのですか？



標準クエリは次のとおりです。







このような実行のチェーン。 ユーザーから最初のサービスに対する要求が来て、次に2番目のサービスから、3番目と4番目のブランチに分岐した2番目のサービスへの要求が来ました。







バム、ブランチの1つをドロップしました。 理由は本当に明確ではありません。 この状況に直面し、ここで何をすべきか、状況の可視性をどのように改善できるかを考え始めたとき、Appdashのようなものに出会いました。 これはトレースサービスです。







次のようになります。







私はすぐに言わなければならない、それはそうだったかどうかを理解するために、試してみることでした。 私たちのシステムに実装するのが最も簡単でした。その頃には、Goにしっかりと切り替えていたからです。 Appdashには、接続する準備が整ったライブラリがありました。 はい、このことは私たちを助けますが、実装自体は私たちにはあまり適していません。







その後、Appdashの代わりに、Zipkinを入手しました。 これは、Twitterの人たちがやったことです。 次のようになります。







私にはもう少しはっきりしているようです。 ここで、特定の数のサービスがあることがわかります。 リクエストがこのチェーンをどのように通過するか、このリクエストが各サービスでどれだけ食い尽くされるかを確認します。 一方では、いくつかの共通の時間とサービスによる区分があります。他方では、同じようにサービス内で何が起こっているかについての情報を追加することを誰も気にしません。



つまり、ある種のペイロード、データベースへのアクセス、ファイルシステムからの何かの減算、キャッシュへのアクセス-これらはすべて同じ方法で追加および表示でき、リクエストではこのリクエストに最も時間を追加できます。 この転送を可能にするのは、TraceIDを使用することです。 彼についてもう少し話しましょう。







これが、特定のリクエストで何が起こっているのか、特定のクライアントに突然落ちた理由を理解し始めた理由です。 すべてが順調で、突然誰かが間違っています。 特定の基本的なコンテキストを確認し、サービスで何が起こっているのかを理解し始めました。







少し前まで、トレースシステム用の標準が開発されました。 この実装を可能な限り簡単にするために、クライアントAPIとクライアントライブラリを実装する方法について、トレースシステムの主要なサプライヤ間で何らかの種類の合意があります。 現在、ほとんどすべての主要言語に対してOpentracingによる実装が既にあります。 安全に使用できます。



私たちは、どのサービスが突然クライアントにサービスを提供できなかったのかを理解することを学びました。 一部の部品が鈍くなっていることがわかりますが、その理由は必ずしも明確ではありません。 コンテキストが不十分です。



ロギングがあります。 はい、これはかなり標準的なものです。これはELKです。 たぶん私たちの小さなバリエーションで。







Logstashの形式でヒープを介して直接収集することはありません。 まず、これをSyslogに渡します。Syslogを使用して、収集マシンでこれを集約します。 そこから、順を追ってElasticSearchとKibanaに配置します。 比較的標準的なもの。 トリックは何ですか？







事実、可能な限り、これがこの特定のリクエストに本当に関連していることが本当にわかっているところで、画面にZipkinで表示したTraceIDをこれらのログに追加し始めました。



その結果、特定のユーザーの完全な実行コンテキストがログのKibanaのダッシュボードに表示されます。 明らかに、サービスがprodになった場合は、条件付きですでに機能しています。 必要に応じて、彼は自動テストに合格し、テスターはすでに彼を見ています。 動作するはずです。 彼が特定の状況で働いていない場合、明らかに、いくつかの前提条件がありました。 この詳細なログのこれらの前提条件は、特定の要求の特定のトレースでこのようなフィルタリングを行うことで確認でき、この状況で正確に何が間違っているかをより迅速に理解するのに役立ちます。 その結果、問題の原因に対する理解が非常に深刻になりました。



次の興味深い点。 動的デバッグmodを導入しました。 原則として、今ではそのような膨大な数のログはありません-約100〜150ギガバイト、正確な数は覚えていません。 ただし、これは基本的なロギングモードです。 一般的に超詳細に記述した場合、テラバイトになります。 それらの取り扱いはめちゃくちゃ高いでしょう。



したがって、何らかの問題があることがわかったら、特定のサービスに移動し、debug mod APIを介してそれらを有効にして、何が起こるかを監視します。 時々、最初に何が起こるかを見ます。 時々、サービスをオフにせずに問題を作成するサービスを撮影し、その上でデバッグmodをオンにすると、すでに何が問題なのかがわかります。



その結果、これはELKスタックの観点から非常に役立ちます。ELKスタックは非常に貪欲です。 一部の重要なサービスでは、さらにエラーを集約します。 つまり、サービス自体は、それが非常に重大な間違いであること、中程度の重大であることを理解し、すべてをSentryにダンプします。







彼女は、これらのエラーを集約し、特定のメトリックに従って要約し、基本的なもののフィルターを作成できるほど賢いです。 これを多くのサービスで使用しています。 そして、私たちはモノリシックなアプリケーションを持っていたときからそれを使い始めました。 現在、特にマイクロサービスアーキテクチャ上のいくつかのサービスを紹介しています。



最も興味深いこと。 このキッチン全体をどのようにスケーリングしますか？ ここで、いくつかの紹介をする必要があります。 プロジェクトに役立つマシンのそれぞれについて、一種のブラックボックスのように扱われます。







オーケストレーションシステムがあります。 ノマドから始めました。 そうではありませんが、実際にはスクリプトを使用してAnsibleから始めました。 ある時点で、これは十分ではありませんでした。 その時までに、すでにNomadのあるバージョンがありました。 私たちは見た、彼女は彼女のシンプルさで私たちを買収した。 これが、私たちが今に移ることができるものであると私たちは決めました。







途中で、Consulはサービス発見のレジストリとして彼女と共に現れました。 また、Vaultには、パスワード、キー、Gitに保存できないすべての秘密など、秘密データが保存されています。



したがって、すべてのマシンが条件付きで同じになることが判明しました。 マシンにはDockerがあり、その上にConsulエージェント、Nomadエージェントがあります。 これは、概して、完成したマシンであり、適切なタイミングで1つずつ取り出してコピーすることができます。 それらが不要になったら、廃止することができます。 さらに、クラウドがある場合は、ピーク時にマシンを事前に準備して、電源を入れることができます。 そして、負荷が落ちたら、電源を切ります。 これは非常に大きな節約です。







ある時点で、ノーマッドは成長しました。 私たちはKubernetesに移り、Consulはすべての結果を伴うサービスの中心的な構成システムの役割を果たし始めました。



自動的にスケーリングするために、ある種のスタックがあることに気付きました。これをどうやってやるの？



最初のステップ。メモリ、プロセッサ、ネットワークの3つの特性にいくつかの制限を導入しました。







これらの値ごとに3つのグラデーションを記録しました。レンガをいくつか切ります。例として：







R3-C2-N1。特定のサービスを制限し、ほんの少しのネットワーク、もう少しのプロセッサ、大量のメモリを提供しました。大食いサービスがあります。



ニーモニックを導入します。これは、システムに既に存在する広範囲の特定の値を動的にねじることができ、これを意思決定サービスと呼びます。現時点では、これらの値はほぼ次のとおりです







。実際、C4、R4はまだありますが、これらはこれらの標準を完全に超える値です。それらは個別に交渉されます。

次のようになります。







次の準備段階。このサービスが持つスケーラビリティのタイプを検討しています。



最も単純なのは、サービスが完全に独立している場合です。このサービスは直線的にリベットできます。 2倍のユーザーが来ました-2倍のインスタンスを起動しました。あなたは再び元気です。



2番目のタイプは、スケーラビリティが外部リソースに依存する場合です。大まかに言って、このサービスはデータベースに含まれています。ベースには、特定の数の顧客にサービスを提供する特定の機能があります。これを考慮しなければなりません。システムが低下し始めてインスタンスを追加することができなくなる時期を理解するか、単に現在どの程度実行できるかを単に理解する必要があります。



そして、3番目の最も興味深いオプションは、外部システムに制限されている場合です。例として、外部請求。彼は500を超えるリクエストを処理しないことを知っています。そして、たとえあなたが100のサービスを立ち上げたとしても、請求のためのすべての500リクエスト、そしてこんにちは！



これらの制限も考慮する必要があります。そのため、サービスがどのタイプのサービスに属しているかを理解し、適切なタグを付けて、パイプラインでどのように動作するかを確認しました。







デフォルトでは、CIサーバーで収集し、いくつかの単体テストを開始しました。テスト環境では、統合テストに合格し、テスターが何かをチェックしました。次に、運用前のストレステストに進みました。







最初のタイプのサービスがある場合、インスタンスを取得し、この隔離された環境で実行して、最大負荷を与えます。いくつかのラウンドを行い、取得した値の最小数を取得します。 InfluxDBに配置し、これが原則としてこのサービスで可能な制限であると言います。



2番目のタイプのサービスがある場合は、システムの劣化が始まるまで、これらのインスタンスを一定量ずつ増分して実行します。どれくらい速いか、遅いかを評価します。ここで結論を導き出します。システムの特定の負荷がわかっている場合、それで十分ですか？必要な在庫はありますか？存在しない場合は、この段階ですでに警告を出し、このサービスを実稼働でリリースしません。開発者に次のように伝えます。「みんな、何かを破る必要があるか、そうでなければこのサービスをより線形に拡張できるようなツールキットを導入する必要があります。」







3番目のタイプのサービスについて話している場合、その制限を知っているので、サービスのコピーを1つ起動し、同じ負荷を与えて、このサービスがどれだけサービスを提供できるかを確認します。たとえば、同じ請求の制限が1000リクエストであり、1つのインスタンスが200を処理することがわかっている場合、5つのインスタンスがこれを正しく処理できる最大値であることがわかります。



このすべての情報をInfluxDBに保存しました。意思決定サービスが表示されます。彼は2つの境界線を見て：上部と下部。上限を超えて移動すると、彼はインスタンスを追加する必要があることを理解し、場合によってはこれらのインスタンスにマシンを追加することもあります。逆もまた真です。夜間に負荷が低下した場合、それほど多くの車は必要ありません。一部のサービスのインスタンス数を減らし、車をオフにして、少しのお金を節約できます。



一般的なスキームは次のようになります。







各サービスは、メトリックを介して、現在の負荷を定期的に判断します。彼女は同じInfluxDBに行きます。デシジョンサービスは、この特定のインスタンスのこの特定のバージョンのしきい値に達していることを確認すると、NomadまたはKubernetesコマンドを既に与えて新しいインスタンスを追加します。おそらく彼はこれがクラウドで新しいサービスを開始する前に、おそらく彼はいくつかの他の準備作業を行います。しかし、一番下の行は、彼が新しいインスタンスを上げる必要性を開始するということです。



一部の制限されたサービスの制限にすぐに達することが明らかな場合は、対応するアラートが発生します。はい、キューなどを保存する以外は何もできませんが、少なくともすぐにそのような問題が発生する可能性があり、すでに準備を開始できることを知っています。



これは、いくつかの一般的なことにおけるスケーリングについてです。そして、これらすべてのサービスを備えたパセリは、最終的には側面から何か他のものを見たという事実につながりました-これはGitlab CIです。







従来は、TeamCityを通じてサービスを収集していました。ある時点で、すべてのサービスに1つのテンプレートがあることに気付きました。各サービスは一意であるため、彼は自分自身をコンテナに入れる方法を知っています。これらのプロジェクトを作成することは非常に困難になりました、それらの多くがあります。また、ymlファイルで記述し、サービス自体と組み合わせると非常に便利であることがわかりました。そのため、これまで少しずつこのことを紹介していますが、その見通しは興味深いものです。



まあ、実際に私たちがこの全体を始めたときに私たち自身に言いたいこと。



まず、マイクロサービスの開発について話している場合、最初にアドバイスすることは、何らかのオーケストレーションシステムをすぐに開始することです。コマンドで実行するのと同じNomadと同じくらい簡単にしましょうnomad agent -dev



すぐに完全なターンキーオーケストレーションシステムを手に入れ、すぐにConsulが育ち、Nomad自身とこのすべてのキッチンを使います。



これにより、あなたが一種のブラックボックスで作業していることが明らかになります。特定のマシン、特定のマシンのファイルシステムに結び付けられた状態からすぐに離れようとします。このような何か、それはすぐにあなたの思考を再構築します。



そして、もちろん、開発段階では、各サービスに少なくとも2つのインスタンスがあることを定めておく必要があります。



次の瞬間は、もちろん、いくつかの建築物です。マイクロサービス内で、これらの最も重要なものの1つはメッセージバスです。。



典型的な例：ユーザー登録があります。それを最も簡単な方法にする方法は？登録するには、アカウントを作成し、ユーザーに課金を依頼し、ユーザーをアバターなどにする必要があります。ここには、特定の数のサービスがあり、特定のそのようなスーパーサービスに対する要求があり、彼はすでにすべての病棟で要求を分散し始めています。その結果、彼は完全に登録するためにどのサービスをプルする必要があるかについてますます知っています。



別の方法で行う方がはるかに簡単で、信頼性が高く、効率的です。登録を行う1つのサービスを残します。彼はユーザーを登録しました。次に、「ユーザー、IDなど、最小限の情報などを登録しました」というイベントをこの共有バスにスローします。そして、この情報が役立つすべてのサービスを取得します。 1つは請求先アカウントに移動し、もう1つはウェルカムレターを送信します。



その結果、システムはそのような緊密な接続を失います。あなたは、すべての人とすべての人について知っているようなスーパーサービスを持っていません。これにより、実際にそのようなシステムでの操作が非常に簡単になります。



さて、私がすでに言及したこと。これらのサービスを修復する必要はありません。特定のインスタンスに問題がある場合は、それをローカライズして、トラフィックを他のインスタンス（おそらく発生したばかりのインスタンス）に転送してみてください。そして、何が悪いのかを理解してください。これにより、システムの実行可能性が大幅に向上します。



当然、システムで何が起こっているか、どれほど効果的かを理解するには、メトリックを収集する必要があります。



ここに重要なポイントがあります。何らかのメトリックを理解していない場合、使用方法がわからない場合、何も伝えていない場合は、収集する必要はありません。ある時点で、これらのメトリックは10億になるからです。必要なものを選択するためだけに多くのプロセッサ時間を費やし、不要なものを除外するために膨大な時間を費やします。それは自重です。



何らかのメトリックが必要であることを理解しています。収集を開始します。何かは必要ありません-収集しないでください。これにより、このデータの処理が大幅に簡素化されます。これは、データが非常に高速になり、非常に高速になるためです。



何らかの問題が発生した場合、急いで全員のために何かをする必要はありません。ほとんどの場合、システム自体が何らかの形で応答する必要があります。何らかのアクションが必要な状況でのみアラートが本当に必要です。深夜に何かを実行する必要がない場合、それはアラートではなく、考慮した何らかの種類の警告であり、条件付きの標準モードで処理できることを意味します。



それだけです。ありがとう





マイクロサービス：忙しいプロジェクトでの経験