「利益は大きい。 これまでになかった多くの自由を手に入れました。」-マイクロサービスのウラジミールプリズガ

今ではマイクロサービスを実装するのが非常に流行していますが、誰もがそれをうまくできるわけではありません。 特に大企業や銀行システムに関しては。 何年も誰かが彼のモノリスを切断することはできません、誰かが耐障害性などについて確信を持っていません。

今日は、1991年以来金融セクターの情報技術分野で活動する企業グループである金融技術センター（CFT）でのマイクロサービスアーキテクチャの実装についてお話します。 つまり、これは製品の品​​質が非常に重要な組織であり、実際のお金はそれに依存しています。

同様に、過去6年間、ウラジミールプリズガはCFTのインターネットバンクと関連サービスのバックエンドの開発に没頭しており、マイクロサービスやその他のファッショナブルなものに積極的にdrれています。 彼と話をするために、私は直接CFTオフィスに来て、自分撮りと赤い象の必須写真を撮りました:-)

議論されたトピック：

• マイクロサービスが必要な理由;
• それらと共存する方法（RESTとSOAPの運命、ステートフルとステートレス、モノリスからマイクロサービスへの移行、レガシーとの互換性など）。
• マイクロサービス技術（Spring Cloud Netflix、Zuul、...）、それらにどんな問題があるか、何を完了する必要があるか。
• ドキュメンテーション：ロシア語または英語で？ ドキュメントの作成と生成（Swagger、SpringMVC、SpringFox）。 建築図-何を描くべきか、どのように保存するか。
• 監視、障害からの回復。
• まあ、そして最も重要なこと：ゲームはろうそくに値するか？

（左側にウラジミール、右側にオレグチル ）

-私の名前はウラジミール・プリズガです。CFT会社で数年間働いています。 主にJavaでバックエンド開発を行います。 それ以前は、彼は他の分野でかなり働いていましたが、これは学生と学生の期間に起因する可能性があります。 もっと正確に言うと、私は現在金融サービスを開発しています。ブローカーやクォートはよく「金融」という言葉を聞いて、インターネット銀行や関連サービスでよく耳にします。 たとえば、ギフトカード追跡サイトなどのツール-現金の代わりにユニバーサルブランドのカードを提供すると、これらのカードが受け入れられた場所ならどこでも支払うことができます。 アプリケーションが添付されており、このカードを使用して、このカードのコストを管理したり、履歴を確認したり、アクティブ化したり、他の利益を受け取ったりできます。

-この証明書カードは充電可能ですか？

-製品の変更の種類によって異なります。 それらのほとんどは補充されません。 獲得者自身、それを与える者は、彼にとって快適な量、通常は300ルーブルから15,000ルーブルまでカードを補充すると、それを与えます。 補充できる個別の変更があります。 しかし、これは証明書、すなわち支払いカードではなく、本格的な金融商品です。 しかし、それはむしろ担保であり、私たちにとっての主なものは正確にプリペイドカードです。つまり、人々にとっては、電子的または本物のウォレットへの一種のカードです。 そこでは、任意の便利な方法でお金を使うことができ、少なくともインターネット上で、少なくとも店舗で、少なくとも支払いアカウント自体（通常、「インターネットバンキング」ではなく「支払いアカウント」と呼びます）を介して支払います。 「幼稚園の支払い」、「公共料金の支払い」などの基本的な支払いサービスに至るまでのニーズ-合計5,000を超えるサービスがサポートされています-AliExpressなどでのあらゆる種類の支払いで終わります。 原則として、あらゆる電子。

このすべてにおける私の役割は、現時点では、バックエンドに関するアーキテクチャ上の決定が私の中を通過するという事実にあります。 マイクロサービスについては以上です。 現在、モノリスからマイクロサービスへの移行の道を歩んでおり、徐々にモノを切り離し、ルール（すでに退屈している人）に従うためにモノリスに新しい機能を追加することはもうありません。 また、コードレビューなど、基本的に新しい機能に関連するものを含む多くのビジネスタスクが通過します。 まあ、およびパフォーマンス、アーキテクチャの改善に関する関連事項...ある意味では、バックエンド開発者の典型的な仕事。

-あなたは直接建築家建築家ですか、エディターでキューブを描きますか？

-いいえ、私自身はまだいくつかの発明されたブロックのコードを直接書いているアプリケーション開発者から成長しているので、実際的な目標と現実に基づいて構築することは私に近いです。 時には抽象化のレベルを上げて、いくつかの立方体と図にそれをレイアウトしようとする必要がありますが、私はこれらの雲に浮かぶのではなく、私が働かなければならない現実に近づけるようにします。 これらがマイクロサービスである場合、特定の概念とそれに固有のパラダイムによって示されます。 特に抽象化しないようにします。

-しかし、それでも、UMLダイアグラムを描画しますか？

-はい、描画しますが、構文、正確さなどをサポートするという極端なことは行いません。

-つまり、それらはコード生成のソースではありません。

-いいえ、そうではありません。

-私もそのような経験をしただけであり、膨大な数のマイクロサービスがある場合に問題が発生し、何が起こっているのかを完全に把握したいと考えています。 この全体像を維持する方法、目の前でそれを修正する方法？

-現時点では、反対から進んでいます。 写真からマイクロサービスを生成するのではなく、マイクロサービスから写真をサポートします。 ある意味、ある種のUMLであるスキームがあります。 しかし、私たちは主にその認識、サポートの容易さに重点を置き、構文とルールのサポートを無理しないことを強調します。 現時点では、私たちはこの方向にはあまり向いていません。それは私たちを満足させる以上のものです。 私たちのスキームにはドキュメントへのハイパーリンクも含まれており、それ自体にはいくつかの規則があり、それが何を、どこで、どのように示されているかについての伝説があり、これにより私たちは現在、通常の向きになっています。 問題ありません。

-ソースから動的に生成されますか？

-いいえ、Confluenceで彼女をサポートしています。 Gliffyプラグインを使用すると、抽象的な図のレベルで画像を簡単に管理できます。 1つのブロックをドラッグアンドドロップしても、リンクを手動で再描画する必要はありません。 文字通り、これらの基本的なことはこれまでのところ私たちを満足させています。 セクションを別々の図に分割するという事実により、全体像をサポートする必要はありません。それは、この形式の知覚にも適していないためです。 あなたが落ちて別の孤立したエリアを見ることができるブロックがあります。これは直接知覚にも適しています。

-システムは非常に美しく、有能で、正確に設計されているため、これらのブロックは健全な構造を提供しますか？

-現時点では、はい。 私は特に自慢しませんが、これは有能なアーキテクチャよりもシステムの若者によってより広範囲に説明されると思います:-)もちろん、私たちはそれをサポートしようとします。 多くの問題が発生する可能性があります-私たちはそれらを先験的に提示し、準備し、武装しますが、このグローバルな形では、まだ何百ものマイクロサービスについて話していないので、タスクはまだ発生していません。

-さて、マイクロサービスはいくつありますか？

-数十の単位。

-もう悪くない。 多くのものはありません:-)

「しかし、私たちはまだ旅の始まりにいます。」

-この最初の課題は何ですか？

-技術開発、建築の面でのタスク？

-あらゆる面でのタスク。 あなたはここの建築家です！

-私は建築家ですが、まず第一にビジネスのニーズから始めます。 企業は今すぐ価値を獲得したいと考えています。 私たちはアジャイルになろうとしているので、いくつかのものは役に立たないかもしれないと仮定します。 何かに投資すれば、土壌を実験、テスト、調査していることがわかります。 これに基づいて、開発とアプリケーションを構築して、すべてのリビジョンができるだけ安くなるようにする必要があります。非常に安価なので、捨てるのは残念ですらありません。 もちろん、これは絶対的なことではありませんが、それでも、現在の方向のおかげで、モノリスに散らばることなく、何らかの形でいくつかのピースを徐々にカットすることができます。その横にそのような大皿を作ります。 再生し、それがどのように動作するかを確認し、価値の観点からエンドユーザーにどのようなものになるかを確認し、必要に応じて破棄します。 これらの3つの優先順位に基づいて：速度、安さ、および他のコンポーネントからの独立性-コンポーネントをさらに開発しようとしています。

私たちが大きな言葉から行為に移るなら、これが純粋に技術的に明らかにされるもので。 モノリスを作らないようにしなければなりません。 それはすでに私たちにとって非常に大きく、私たちはそれを「コア」と呼びます-それに関係するすべては「核」、「核」、他の何らかの形で...一般的には、もはやそれに入る方法はありません 当然、このコアとそれに付随するサテライトの参加なしに、外部クライアント（これはWebとさまざまなモバイルプラットフォームの両方です）との通信を構築する必要があります。 つまり、すべての接続をエントリポイントを介して直接行うため、ルートレベルで、ロードバランサーレベルで、いつでも切断し、このトラフィックを切り替えて、単一のスレッドでカーネルに注ぐときよりも柔軟に制御できます。

さらに、できる限り安価になるように、開発自体をビルドしようとします。 マイクロサービス全体があります-本格的で動作していますが、何もしません。 そして、それはその唯一の目的を果たします-残りを作成するためのテンプレートになること。 私たちはそれを愚かにコピーし、すでにすべてを知っており、その中ですべてが発生し、構成されており、CIテストに適応し、戦場での拡張に適応しており、すでに簡単に反発することができます。 これは具体的には、開発者が新しいマイクロサービスを開始するための最小限の労力で、今日プレイした時点まで-ひっくり返して捨てなければならないようにするために行われました。

-このテンプレートは何に基づいていますか？ Spring Cloudのような一般的なものか、それとも違うものか？

「既製のクラウドソリューションの場合...おそらく、この方法は採用しませんが、個別のライブラリを使用します。」 これはまず、ユーレカ、ズール-サービスのレジストリ、エントリポイントの標準ソリューションです。

-既に使用していますか、それとも開発の方向ですか？

-すでに使用しています。 エントリポイントとサービスレジストリはすでに動作しています。 このソリューションをテストするために、エンドユーザーからの戦闘トラフィックではなく、あまりアクティブでロードされていないコールセンターからの補助トラフィックを誘導しました。 マイクロサービス自体のベースに関しては、これは原則として他のすべての人にとってのSpring Bootです。 「裸」と見なせるかどうかわかりません。 もちろん、いくつかの追加フレームワークでは、ほとんどの場合、同じSpringのフレームワークです。 私たちは春の決定に最も焦点を当てています。

-しかし、あなたは自分でそれをねじ込みましたか、それとも何を取りましたか？ たとえば、Spring Cloud Netflix。 つまり、注釈、RestTemplateなどです。

-はい。 今、私たちのマイクロサービスの経験は、エントリポイント、つまりサービスレジストリ-アプリケーションコードの観点から-は非常に小さいことです。 ほとんどすべてがアノテーションを追加したという事実に帰着し、残りの魅力はJavaコードの外側にあります：これらはビルドスクリプト、開始スクリプト、およびその環境と現実、CI / CD、さらに開発者への適応に関するすべてです。 ただし、エントリポイントでは、追加のアクセス制御、セキュリティの問題、およびAPIの下位互換性を確保するためのフィルタも追加しました。一般的に、独自のアドオンがあります。 しかし、フィルターの概念でさえも、Zuulライブラリー自体から取得した抽象化であり、Spring Cloudに取り込まれます。

-わかった。 サーキットブレーカーなど、あらゆる種類のものを使用しますか？

-はい、行きます。 しかし、私たちが集まるような状況がありますが、私たち自身はすでにそれを使用しています。 Spring Cloudの配信でZuulにはすでにHystrixが含まれており、既に機能しており、タイムアウトが設定されていることを考慮して、設定を処理することを既に余儀なくされています。 私たちはそれを使用しますが、可能な限り意識的にそれを行い、すべてを制御するとは言えません。

-何かを終えたいという欲求はありましたか？ たとえば、ユーレカでは。 またはズールで。

-幸いなことに、Zuulはそのような欲求が生じないように十分に柔軟であることが判明しました。 いえいえ、嘘をついています。 GitHubにリクエストプールがあります。 いいえ、申し訳ありませんが、現在は単なる問題であり、プールリクエストは開発中です。 一般に、ZuulはそのままではカスタムHTTPステータスをサポートしないことが判明しました。 「カスタム」とは、RFC自体によってHTTPプロトコルに対して標準化されていないものを意味します。 431-必要はありません。どのようにも設定されていません。どこにも輝きません。 Zuulでは、エントリポイントを介して外部にプロキシされる着信コードは、Zuul自体の同じソースコードに縫い付けられた列挙の要素の1つに必ず対応するという事実に基づいて設計されています。 そして、マッピングが存在しないHTTPステータスがそこに到着すると、それは落ちます。 さらに、それは非常にひどく落ち、回避策はありません。 私は彼らに手紙を書いた、彼らは答えた-まあ、はい、おそらくそう、それを修正してみてください。 私は、これが主な故障が発生する場所であり、純粋にデバッグの役割を担っていることに驚きました。 リクエストを適切にデポジットするためにリクエストの一部を噛むことを意図しており、これは「正確に」それがベアHTTPステータスではなく、このまさに列挙の要素をログに記録することを意味します。

-ラッパーを展開する必要があります。

-そして、それはオフにすることができるデバッグのために、しかし、このレベルでそれがまだ動作することが判明し、アプリケーション全体がクラッシュします。 実際、この問題の重大度は低下しています。 カスタムHTTPステータスをいじることについて考えを変えました。

「なぜそれらが必要なのですか？」

-1つのアイデアがありました。興味深い場合は、簡単に説明します。 それらを使用して、発生するエラーのニュアンス、または一般に有限のマイクロサービスからの応答を伝えたいと考えました。 私たちにとって、すべてのビジネスシナリオは、結果からのあらゆる種類のさまざまな逸脱を意味します。 また、クライアントにとって、ビジネスシナリオと各ステップがどのように終了したかを知ることはしばしば重要です。 再送信はユーザーが意識し、クライアントが自動で再試行するか、後で再試行する必要がある場合があります。 これは、そこに何かを変更するための提案を含むダイアログボックスの必要性を示している場合があります。 特定の例を挙げると、プリペイドカードに送金するサードパーティの銀行カードから追加料金を受け取ることができます-このプロセスにはいくつかのリクエストがあり、それらのいくつかはサブシナリオでさらにアクションを分岐することができます。 このようなことは、カスタムHTTPステータスに課税したいだけです。 APIレベルで自分自身と直接交渉し（API全体がSwaggerで文書化されます）、そこに次の形式で記述されます：ステータス+クライアントが行う必要があること。 トピックはいくつかの理由で入りませんでした。 さまざまな理由がありましたが、主な理由の1つです。当時、既存のモノリスには既存のAPIがあり、エラーの色合いをHTTPステータスの形式ではなく、応答の本文のフィールドの形式で伝えることが一般的でした。

-または、HTTPヘッダーを配置する方が良いでしょうか？

-ヘッダーを持つことは可能ですが、いずれにしても、これにはAPIの大幅な変更が必要であり、後方互換性はありません。 倒錯して下位互換性を持たせることもできましたが、これには十分な数のクライアントがあるため、無期限に存続する必要があります。 これらすべてを検討した結果、新しいAPIにまだクロールしていないクライアントとの下位互換性をサポートするために、追加のロジックの巨大なレイヤーを背後にドラッグするよりも、古いAPIをかわして適応する方が簡単であることがわかりました。 簡単なことではありませんでした。クライアントパーツの開発者が私たちにもたらした追加の状況がたくさんありましたが、最終的にこの決定に落ち着きました。

「あなたはSwaggerと言った。」 それを使用する習慣は何ですか？ どれくらいいいですか？ 楽しいまたは不快な瞬間はありますか？

-十分なそれらおよび他の人。 私たちはすでにそれに取り組んでいるので、もっと楽しいものがいくつかあるとあえて言います。 まず、私たちが得た最も重要なことは（ここではSwaggerのメリットはそれほど大きくありませんが）、説明の単純さです。 たまたま、モノリスがPlay Framework上に構築されています。 PlayにはSwaggerドキュメントを生成するためのプラグインがありますが、いつものように、歴史的な理由から、異なる人々が異なる時期にそれらを書いており、これらのプラグインは何にも不向きです。 したがって、ドキュメントは手動で作成する必要がありました。 まっすぐな仕様で、まっすぐ座って手で書きます。

「世界のほとんどが今やっているように。」

-しかし、好むと好まざるとにかかわらず、あなたは同じコードを書くことを認めなければなりません。

-そして再びjavadokで。 そして、4回目のテストです。

-はい！ なんで？ 私は本当にこれでいくらかのお金を節約したかったので、マイクロサービスの道を進んだとき、自転車を発明しなかったので、いくつかの解決策を分析しました。 現時点では、SpringFoxは最も主流で最も開発されたソリューションのようです。 彼について何か知っていますか？

-いいえ、何もありません。 今、私は名前を知っています。

-このSwaggerドキュメントジェネレーターは、Spring自体のコントローラー記述に基づいています。 特に、Spring Bootで。 しかし実際には、Bootの下ではあまりシャープではありませんが、すべての注釈が由来するSpringMVCに焦点を当てています。 しかし、彼はSpring Bootと友達です。 アイデアは、APIの構造、メソッドのセット、それらのパラメーターが既にメソッドとアノテーションの形式でコントローラーに記述されており、それらを抽出できるということです。 これが作業の大部分であり、ドキュメントの骨組みです。 欠けているのは口頭での説明だけです。 しかし、コード自体に注釈を追加するのが簡単であることは明らかです。 SpringFoxはこのパスに正確に沿って移動します-Swaggerアノテーション（より正確には、swagger-annotationサブプロジェクトから、これはジェネレーターの一部です）を取得し、これらのアノテーションをSpringのコントローラー（SpringMVC、この場合はSpringBoot）に適用します。 その後、オンザフライで解釈され、Swagger仕様が生成されます。 さらにもう1つの魅力-マイクロサービスの一部として、別のエンドポイント（別のポートではなく、別のコンテキスト）を公開し、Swagger UI（これらの美しい緑のHTMLフォーム）を開きます。読むためだけでなく、あなたがそれで遊ぶことができるように-試用ボタンはすぐにボックスから機能してマイクロサービスにリクエストを送信します。 一見すると、魔法のように見えます。仕様を手動で記述する必要はなく、同時に利用可能です。 それをリクエストして、SOAP UIまたはPostmanにフィードできる別のURLがあります。 これはすべてすでにあります。 さらに、各マイクロサービスのポートにドキュメントが展開されており（検索する必要はなく、どこかに記憶する必要があります）、読むのに適しています。 もう1つの利点は、コードの変更はドキュメントの変更を伴うことです。 このような何かを書くことを試みることは依然として必要であり、同じ場所であなたがテキストの形でほぼ同じことを書くことに気付かない。 もちろん、これはそのような決定の不可欠なプラスです。

しかし、正直に言って、それは不完全です。 すべてがスムーズではありません。 SpringFox自体は注釈とSpringのクエリ構造に精通していますが、完全ではありません。 特に、コレクションに問題があります。 メソッドからコレクションタイプが返されると、UIに曲がって表示されます。 さらに、裸のSwaggerが提供するすべてのパラメーターを調整できるわけではありません-考慮すべきウィッシュリストがあります。 いくつかの粗さがあります。 しかし、全体としては、非常に効果的なアプローチです。 しかし、真実はあり、このために再編成しなければなりませんでした。 以前にコントローラー自体にビジネスロジックを追加することに恥ずかしくない場合（たとえば、アノテーションレベルで行われなかった場合の検証）、チームレベルで考えを変える必要がありました。 私たちにとってのコントローラーはエントリーポイントであり、ドキュメントのソースであると言えます。 たとえば、適用された検証のビジネスロジックは存在しないはずです。 そうでなければ、それらは読めなくなり、各メソッドにはたくさんの注釈があります。 単一の@RequestMappingメソッド、@ ApiOperation、@ ApiResponseなどではなく、すべての種類の異なる注釈が突然表示されます。

-コードシートの半分に注釈が記入されていますか？

-現実には、それはさらに起こります。 しかし、ビジネスロジックを個々のサービスに委任することに同意したという事実により、テスト範囲が改善され、明確な線を引くことができました。 コントローラがあり、ドキュメントのソースと外部との通信という2つの問題を解決します。 そして、サービスのアプリケーションロジックで既に残りを実行します。

-プログラマーは常にこのドキュメントを書いていますか、それともドキュメンタリーがありますか？

-いいえ、私たちは開発者だけを書いています。

-そして、これは通常、粗さなしで常に起こりますか？

-ここでは、マイクロサービスでは、非常に簡単です。 すべての粗さは、開発者が手動でモノリスのドキュメントを保持したときでした。 彼らは常に何かを忘れ、絶えず分散し、時代遅れになり、モバイル開発者はドキュメンテーションが古くなったので呪われました-それは本当に錫でした。 そして今、それが起こったとき、開発者は幸せなだけです。

-どの製品をターゲットにしていますか？

-ロシアへ。

-そして、文書はどの言語で書かれていますか？

-ロシア語。 私たちには独自のチームがあり、リモートオフィスを含む外国人はいないため、全員ロシア語で行動します。

-このドキュメントは、社内での作業用に生成されたものですか？ または、外部の請負業者に渡しますか？

-私たちにはそのような経験がありましたが、今はそうではなく、ロシア語を話す請負業者がいます。

-とてもラッキーです。

-わかった！

-このSpringFoxのコードを見ましたか？ 本当にしたい場合は、パッチを適用できますか、それとも地獄のような錫はありますか？

-はい、できます。 もちろん、重要な場所があります。 しかし、全体的には普通に書かれています。 すばらしいとは言いませんが、悪くはありません。 あらゆる種類の滑りやすい場所を修正するために、すでに数回手を挙げていましたが、時間が見つかりませんでした。 そして第二に、かなり活発な人が彼の後ろにいて、彼らは彼をかなりよく見ています。 私たちが望むほどアクティブではありませんが、定期的にいくつかのアップデートを公開しています。 確かに、これまでにウィッシュリストのどれもカバーされていません。

-HTTPに関して：特定の方法論、たとえばRESTにリクエストを課そうとしていますか？

-はい、私たちは試みています。 かつて、マイクロサービスへの移行が始まった当初、私たちはこれに非常に頼っていました。 議論し、話し合って、白熱した議論がありました。

「しかし、地球上でフクロウを引っ張ることは通常非常に困難です。」 これはどうですか？

-歴史的にこれはいつも通りです。 覚えているなら、以前のAPIとの後方互換性の強制サポートについては既に言及しましたが、このAPIには膨大な数の顧客がいます。 何十万人もの人々が電話をインストールしています。 そして、そのAPIとの後方互換性を維持することを余儀なくされたという事実のために、あらゆる点で安らかであるという私たちのすべての試みは世界中からoffいました。 そして、APIは、控えめに言っても、完全に安らぐわけではありません。 エンティティを削除するか編集するかに関係なく、POSTとGETのみを使用します。 REST全体が構築される「エンティティ」などの概念-彼らはまた、特にそれを遵守しませんでした。 そこでは、このアプローチはJava自体に似ています。何らかの方法があります。名前をアドレス自体に詰め込みましょう。 ここでは、このアドレス自体、getBySomethingに存在します。 このアプローチはひどいものではなく、正常に機能しています。 RESTを使用すると、もちろん、より簡潔できれいになりますが、APIが十分に大きく、大人であるにもかかわらず、適用される大きな価値は感じませんでした。 単一のパラダイムは存在しないという事実のために、彼はおしゃべりになるリスクを冒したように思えましたが、原則としてそれはひどく判明しました。 そして今、私たちは頭の中にいくつかのRESTチップを置いて使用しようとしているという事実にもかかわらず、本質が最前線にあるようにメソッドのアドレスを設計しようとし、次にそれがいくつかに分割されるスラッシュに続く繊細さは要求の奥深くにありますが、下位互換性のこれらの側面に限定する必要があります。 つまり、このような準RESTがあります。

-ステートレスまたはステートフル？

-マイクロサービスは現在すべてステートレスです。 1つには、おそらく疑問があります。近い将来の次の段階は、オーケストレーションシステムでの展開になるからです。 DockerコンテナでKubernetesにすべて展開する予定です。 運用に同意した主な要件の1つは、原則として非常に自然なもので、ステートレスマイクロサービスです。 その理由は理解できます。そのため、いつでもそれらのいずれかをドロップし、すぐに次のものを上げて、リクエストを受け取ることができます。 そのため、持ち上げや損傷ができる限り簡単になります。

-また、重いサービスがまだある場合は、どうすればよいですか？ k8sがヒップで400ギグのサービスを落とすと......

-このデータをどうしますか？

-データをどうするか、サービスがそのような移行に耐えられるように適切に設計する方法は？

-いくつかのアプローチがあります。 私たちが実践しているものの1つは（この場合彼が良いとは言えませんが）分散ストレージを使用することです。 ヒップと呼ばれる場所がヒップだけでなく、マイクロサービス間のどこかに保存されるようにします。 クラシックソリューション（誰にとってもクラシックなのかわかりませんが、私たちにとっては1つになっています）はHazelcastです。 Hazelcastベースの分散ストレージ。 これがモノリスの仕組みです。 クラスター化され、共通の分散ストレージがあります。 データの断片はすべてのノードに保存されます。 1つのノードが落ちた場合、誰もこのデータを失うことはありません（もちろん、複製できた場合）。

-複製の程度は？

「今、私はあなたに確かに伝えません。」

-これがfullsink以下であるとだけ言ってみましょう。

-データに依存します。 場合によっては、フルを使用しますが、重要度の低い繰り返しやすいデータには2/3があります。 つまり、データは3つのノードのうち2つに格納されます（クラスターに3つのノードがある場合）。 しかし、ここで私は何かに嘘をつくことができます。 これは1つのオプションです。

2番目のオプションは、マイクロサービスが400GBまで膨れ上がった場合で、これはすべて貴重なデータです。マイクロサービスですべてが大丈夫ですか？ 彼は本当にそのように振る舞うべきですか？

-彼はもはや「ミクロ」ではなく、「ファットサービス」です。

「他のいくつかのマイクロに変換する必要があるようです。」 または、その下に、そのようなことから彼を保護する永続的なパッドが必要です。 もちろん、アジャイル性は低下しますが、データの価値に依存します。 おそらく、それらをどこかに分けておくのが理にかなっています。 必ずしも本格的なDBMSであるとは限らず、より軽量なソリューションを使用する価値があるかもしれません。 しかし、これまでのところ、このような問題は発生していません。十分に小さくしてください。 落ちて貴重なデータの山を下に引っ張った人はいません。

-マイクロサービスのチェーンの途中で、近隣でアクティブに使用されているものが完全または部分的に落ちた場合はどうなりますか？ 優雅な劣化や何かがありますか？

-ほとんどの場合、いいえ。ただし、一部の地域ではまだ保険をかけています。 しかし、Hystrixでフォールバックを使用する場合、同じSpring Cloud Netflixに組み込まれているツールではありません。それらについては知っていますが、試してみましたが、今のところ必要はありませんでした。 代わりに、独自の手段を管理し、そのような状況で何ができるかをコードで直接知っています。 別のリクエストを満足させるために、リクエストが途切れるのを許可するどこかで。 または、キャッシュからデータを取得し、そこにデータがあり、それを行ったデータベースから最新のデータよりも古いデータを取得して中断することもできます。 それはすべて状況に依存します。 しかし、そのような場所はあまり多くありません。

-私はさまざまな人々と話しました。正直なGD / DRを持っていない人々のための2つの主な戦略：10億人の中国人がいて、マイクロサービスグラフの一部が落ちたら、私たちは嘘をついて10億人の中国人を解決しようとさえしないか、「すべてが失われました」 「、私たちは恐怖で輪になって走り始め、管理者を叫んで蹴ります。 これはどうですか？ あなたとはどうなりますか？

-最初に近いと思います:-)

-回避策がない場合の2番目のケースでは、どうにかしてprodがまったく落ちないように配置する必要があります。

「まあ、はい、いいですね。」 しかし実際には、これはどの程度実現可能ですか？

「できますか？」 あなたはそれをしますか？

-いいえ、ご覧の通り。 現時点ではまだです。 代わりに、より正確なソリューションで対処しようとします。 または、最も重要な個々のピースを保護します。たとえば、同じモノリスをクラスター化しようとしました。 彼は10億に耐えることはできませんが、基本的なクラスタリングのために三重の負荷を取り除くことができます。 確かに落ちる可能性のあるいくつかの個別のビジネスケースではなく、負荷のためだけでなく、客観的な理由（外部システムへのアクセス不能）のために、キャッシュなどの助けを借りてそれらをバイパスしようとします。 しかし、私たちはまだすべての場面で普遍的な解決策を持っているわけではありません。

「これは、生きている人々である搾取によって対処されます。」

-はい。 これがなんらかの直接的な虐殺、数十億人の中国人である場合、多くの監視システムとあらゆる種類のカバーシステムがあるという事実にもかかわらず、彼らが同じ中国の州から来た場合、彼らは一度にすべて禁止され、彼らは単にノックすることができません-そのような資金。 しかし、これはすでに人々の参加による半自動モードで行われます。

「悪用は、私たちにとって何かが悪いことをどのように理解しますか？」 モニタリングをほのめかします。

-さまざまなレベルで監視される監視。 SQL- Apache . , (, , , ..) — . - . , — . , , , . .

— - - ?

— . , - — , Java — . JAMon, SpringBoot Actuator (, ). , — , , — . , — , , , , . , . - , . , .

— - -, : , ?

— . - , , , . , ( ), , , - . — ( , ), — , , , , … . , , , , , . , , .

— , ?

— . , , . , — , , . Machine Learning, .

— , .

— . , , , . , , .

— ?

— , , . Java Melody — , Spring Boot. , - , , . , . , JAMon — , Zabbix. JAMon — - -, , … , , .

— , 20 : , , ? , , ?

— … , ?

— , . - — . Java - , . , , , , API, , , — .

— , . , . . , . , . . — , . . , — Ops DevOps . , — , , . . , . , Ops' — , , . , - , , , . Ops-, . , , , , , . CI. Jenkins, .

— , API, , — , . , , . . . , , , , - . , . — , , ( , ). , . - , . , , , — , . , . , , .

, . , - -300. -400 «» , -300 , . (102 ), . , , , . , , , , , , . , . , , , — , , , . —— , . , , , . .

— , , ?

— , , — , , . , . . , , , , . , , , , . , , , , , , . , , - : , , API — . .

— , , , , . , , 100 . . ?

— . - - , . . API, , , , -, . . , , , , - ( ). , — — API. , SpringFox Spring Boot . , API . API Swagger UI, : , API, ? , , - . , , . - . , , , Confluence, . , . , , , - , Swagger UI.

— , HTTP, REST .

— , , . , , — , , .

— - , HTTP/REST? , , SOAP.

— , , « ». — , , . , 95% — , . . . SOAP — , , , .

— - ?

— , , , TCP-. , :-) , — - , , .

— , - -. HighLoad, , .

— , , , , HTTP, XML. WSDL, . - , . « req, — ans». . .

— , . ? — , 4 ? どうする

— , - ! , . , . , , , XML. - - — . API, , , , . multipart/form-data, , , — - — , . . — . , CLOB BLOB ( , ) input output-. , . , — . , , , . , — , DOM, .

— , ? , , ? ? ? ?

-最初に頭に浮かぶのは、意見に基づいたアプローチを尊重することです。これに基づいて、Spring Bootが構築されます。 他の人の経験の集約と一般化に基づくアプローチとツール（マイクロサービスや関連タスクには関係ありません）。 私たちの経験が示すように、これはサードパーティ製のツールからのみ入手できるほとんど最も貴重な追加です。 それらが単に設計されているのではない場合、「あなたが望むものをカットし、ここでいくつかの基本的な抽象化を提供し、そして今あなたが望むものをします。」 ここに代表的な例があります-Antはそのようなものでした。 非常に強力で非常に柔軟なツールですが、何をするにしても、すべてをゼロから作成すれば、常に自分で蓄積していきます...

-またはメイクファイル。

-はい、メイクファイル。 私の意見では、Gradleは非常に良い解決策です。 彼らはすでにそれ自体が証明されているものをたくさん置いて、実用的な解決策として確認しました。 デフォルトと見なされる基本ディレクトリ構造から始めて、なぜそれを明示的に宣言し、ホイールを再発明するのですか？ これはまた、人々が十分な経験を持っていないときに動物園につながり、それが一般に受け入れられているものに対応せず、完全な崩壊が始まることがわかります。 したがって、これらのデフォルトの意見のあるアプローチは、初心者のチームと継続する人の両方にとって非常に価値があります。すでにこの道を歩き、熊手と地雷原を集めた他の人々の膨大な経験を再利用することができるからです。 したがって、特定のツールやサービスに焦点を当てることさえしなくても、私は意見のあるアプローチの優位性をグローバルなアイデアと考えています。

「あなたが話していることを正確に理解できるように、意見を述べた言葉を説明してください。」

-意見に基づくアプローチ。 たとえば、Spring Bootのメンバーがどのように書いたのか、なぜ今のように設計したのかを思い出してください。新しいものは発明しませんでしたが、彼らの経験をまとめました。 基本的なプロジェクトである彼らの意見では、製品はこのように見えるはずです。 デフォルトで。 これは誰にとってもこのように見えることを意味するものではなく、同意しない場合は森に沿って進みます。 これは、気にしたくない場合、このように見えることを意味します。 これは彼らの意見です。 そして、あなたは何とかそれを締め、修正し、修正する機会を与えられます-あなたのニーズに、すでにあなたの意見に。 豊富な経験と柔軟性のこの組み合わせは、このようなソリューションの最大の価値です。

これは常に良いとは限りません。 最初のPlayの例（2番目のPlayで少し機能しました）-意見もありますが、そこでは非常に具体的な意見がありました。 どんなヒップスターが書いたのか分かりません:-)

-それはまだJavaのものですか？

-はい。 彼と仕事をしなかったのですか？

-働いたが、それはずっと前、私の人生はすべて過ぎ去った。

-覚えているなら、何らかの理由でJavaパッケージの標準構造を受け入れません。 彼らは、何かを袋に入れたら、それをここ、根元に置くと信じています。 ここでは、いくつかのorg.company.app.controllersではなくコントローラーを呼び出しましたが、コントローラーだけです。

-構造がないときにフラッシュを解決する方法は？ クラス名で構造を整理できます...

-ハ、「素晴らしい」ソリューション！ そして、そのようなスズはいつもそこにあります。 または、例えば、彼らはウェブ全体が静的であると考えます。 したがって、すべてのコントローラーのすべてのメソッドは静的です。 まあ、彼らの意見では、これはそうです。 これは単なる例です。

「しかし、特定の部分に集中することで、開発の複雑さを軽減しました。」 そして、もしあなたがこの幸せな作品から出てきたら、あなたはカペトします。

-私たちの経験は、この作品を超えることは非常に簡単であることを示しています。 アプリケーションがハムスターや実験室の仕事からもう少し深刻なものに変わるとすぐに-それだけです。

-そして、彼らは2番目のPlayを書き、岩の上でそれを書き直しさえしました。 ところで、私はあなたがモノリスで最初のプレイを使用していることを正しく理解しましたか？ それで、あなたはそれを使い続けますか、それとも代わりに何かを取りますか？

「代わりに、モノリスの値がゼロになるまで、モノリスからピースを徐々に刈り取ります。」

-とにかく、顔を見せるために何らかのWebフレームワークが必要ですか？

-いいえ、必要ありません。 私たちの場合、モノリスは単なるバックエンドカーネルです。 そして、前部は別の衛星アプリケーションによって分離されています。 次に、Webパーツについては、完全に自分の世界に住んでいて、React.js上の独立したWebアプリケーションとしてWebパーツを正確に見た個々の人に責任があります。 私たちは彼らにAPIのみを提供します-テンプレートもHTMLもありませんが、それらはアプリケーションで使用する裸のAPIです。 もちろん、携帯電話でも同じです。 APIのみが一致する場合、ここではどのフレームワークにも縛られていません。 また、APIはHTTPです。

-それはおとぎ話のように聞こえます、多くはmany望で燃えます。

-よくわからない...苦しんだ、インターネットバンキングの最初のバージョンは古いもので、かなり前に書き直した、Wicketフレームワークにあった、これについて聞いた？

-はい、これはひどいフレームワークです。長年取り組んできました。心から憎みます。

-私はあなたを理解することができます、私はほとんど彼を捕まえました。 コンポーネントの概念があり、HTMLに適合し、wicketIdがあり、その場で生成され、置き換えられることを覚えていますか？ 私たちはそれを持っていて、そこを去りました。 どこへ行くのか、何を離れるのか、何に疲れているのかを理解しました。 原則として、このフレームワークは絶望的ではありません。どこかでもいいのです。すべてがその場所にあります。

-私が理解している限り、Wicketの拡張は非常に困難です。

-正直なところ、何もありません。

-クラス階層のルートにIClusterableインターフェイスがあります。 理論的には、彼から作業してTerracottaをドラッグできますが、開発者自身はこれに頼ることはありません。

-私たちはこのポイントに到達することさえしませんでした-私たちはすべてを単に書き直して、普通にクラスター化し始めました。

一部のアプリケーションはまだWicketで正常に動作しますが。

「私たちは1時間以上話していました。」 このすべてからレポートを作成するアイデアはありましたか？

-まだです。 私にとって、これはすべて非常に近いので、これは普通のことのように思えます。 みんなが何をしているのか教えてください。 しかし、一方で、他の人が来て、教えても、何もしません。

-大きな違いがあります：他の人にとってはまだうまくいきませんが、あなたにとっては判明します。

「私がここで話していたことに加えて、他のものが引き継いでいます。」 たとえば、JBreakで説明するトピック。 また、最近のプロジェクトでは、テスト環境でサーバーログを集計するツールを開発しました。 マイクロサービスの開発に関連して、いくつかのインデックス付きのログではなく、ログをすべて1か所で、それらがどのように記述されているか、今すぐ見ることが重要になりました。 一方では、ELK、Logstash、Kibanaなどの多くのソリューションがすでに発明されていますが、経験が示すように、テストでは大砲からスズメを撃ちます。 フォーマット、インデクサーを構成する必要がありますが、それらは常にリアルタイムで機能するとは限りません。 ツリー自体は3つのアプリケーションであり、それぞれを展開する必要があります。 迅速に展開でき、サーバー上のログのすべてをすばやく簡単に確認できる、より軽量なソリューションが必要です。 そして、明らかに、UIさえも持たないリモートサーバー上で。 できることは、コールテールだけです。

-それには、SSH経由でアクセスする必要がありますか？

-SSH経由でのみアクセスできます。SFTP経由でアクセスできます。他のオプションはありません。 そして、これはまさに私が長年直面してきたタスクです。その時点でこれらのファイルを単純に流し込み、ブラウザーで開いているWebページに戻す単純なユーティリティを作成しました。 そして彼女はリアルタイムで直接書き込みます。 そのような尾、ブラウザのみ。 アプリケーションをインストールする必要はありません。ただ取得して注ぎます。 しかし、これはマイクロサービスに関しては十分ではありませんでした。 それらを集約するには何らかの解決策が必要でした。 そして、Spring Bootで、tailを実行し、非同期でリッスンするzapililアプリケーションです。メッセージが表示されるとすぐにそれらを集約し、AngularのアプリケーションをWebページに送信します。 私はWeb開発者ではないので、気にしませんでした。Angularではすべて見ました。

-ご存知のように、Web開発者は時々Angularで書くこともあります:-)

-はい、Angularが大丈夫ではないことが一般的に受け入れられているのはごく最近です。もっと新しいものが必要です。

-2番目または1番目？

-StackOverflowでは、彼に関するほとんどの質問があったため、最初の質問があります。 実際、さまざまな関連タスクがそこで解決されています。 タイムスタンプが不均一に書き込まれているという事実にもかかわらず、最終ログのすべてが必然的に順序どおりになるようにタイムスタンプを認識する方法。 交差しないように、つまり メッセージにステクトレースがある場合、他のログからの誰かのメッセージが途中で忍び寄らないようにします。 集計、タイムスタンプの認識、およびこれらすべてが順番に配置されます。

-さて、すべてが議論されました。 次のステップは、レポートにアクセスすることです。 答えてくれてありがとう、ウラジミール！

広告の分。 ウラジミールは、 JBreak 2018カンファレンス（ 今週の 日曜日に開催予定）のスピーカーです。 彼の講演「Side Effect Injection、またはVirtuous Crutches」で、彼はSide Effect Injectionのアプローチについて話し、Javaコードをコンパイルするためのオプションを賞賛し、JVMでバイトコードを変更する1つのケースを選び、正式なJava文法を分析し、実際の例を使用してこれをすべて確認しますアプリケーション。 会議にはディスカッションゾーンがあります。そのため、レポートの後、ウラジミールと会い、副作用注入だけでなく、たとえばマイクロサービスなど、さまざまな問題について話し合うことができます。 チケットは公式ウェブサイトで購入できます 。