車輪の再発明を行う理由：またはM.Video-EldoradoGroupが独自のマイクロサービスアーキテクチャを開発する方法

今日のM.Video-EldoradoGroupの技術インフラストラクチャは、全国の1000を超える店舗にある巨大なレジチェーンをはるかに超えています。内部には、顧客との対話、機械学習、スマート検索アルゴリズム、チャットボット、レコメンデーションシステム、主要なビジネスプロセスの自動化、および電子ドキュメントフローを提供するオンラインプラットフォームがあります。カットの下には、モノリスをマイクロサービスに分割する方向に私たちを駆り立てた理由についての詳細な話があります。

深い古代の伝説

これらすべてが時計仕掛けのように機能するためには、技術の発展を追跡し、ビジネスの要求に迅速に対応する必要があります。残念ながら、グローバルERPシステムの基本的な機能は、社内の顧客の新たなニーズに常に迅速に対応できるとは限りません。 2016年、これはマイクロサービスアーキテクチャへの移行を支持する議論の1つになりました。



同社は、すべての販売チャネルと連絡先（当時：Webサイト、モバイルアプリケーション、キャッシュデスク）で顧客から注文を行うプロセスで、さまざまな販促メカニズムと連携する統一されたビジネスロジックを実装するというかなり困難な課題に直面していました。および店舗の端末とコールセンターのオペレーター）。



同時に、ITランドスケープ内には、Oracle ATG Eコマースプラットフォーム、SAPCRMなどの大規模なモノリシックシステムがありました。私たちの計算によると、それらのそれぞれでロジックを繰り返すか、1つで実装し、別の必要な機能で再利用すると、何年もの時間と数千万の投資が発生しました。



そのため、当時私たちが自由に使える開発者と技術的に有能な人々の小さなチームを集め、私たちのニーズに合わせて別のサービスを作成する方法を考えました。精緻化の過程で、私たちは実際には1つではなく、3つまたは4つの作業ツールが必要であることに気づきました。これが、マイクロサービスアーキテクチャの概念に初めて到達した方法です。



必要な経験があったので、Javaでコーディングすることにしました。Springバージョン3.2を選択しました。その結果、相互に密接に相互接続された、3つまたは4つのサービスで一種の分散型マイクロモノリスを取得しました。それらは独立して開発されたという事実にもかかわらず、誰もが一緒に働くことができました。



しかし、独自の技術開発という点では大きな飛躍でした。Java6からJava8に切り替え、Spring 3の習得を開始し、Spring 4にスムーズに移行しました。もちろん、それは確かな試練でした。



プロジェクトの実装期間をあいまいな「開発にかかる月数」から短縮することに成功し、必要なクロスチャネルビジネスロジックをほぼ2か月で実装しました。

技術の進化

2017-18年に、マイクロモノリスのグローバルリファクタリングを開始しました。マイクロサービス開発の概念は、ITスペシャリストとビジネスの両方に好まれていました。作業タスクの流れが増え始めました。さらに、さまざまな消費者が必要とする機能ブロックを企業のITランドスケープから分離し、それらをマイクロサービスのレールに変換し続けました。



私たちは時代に遅れずについていき、Java 9にジャンプしようとしましたが、成功を収めることはできませんでした。残念ながら、この演習では具体的なメリットは得られなかったため、Java 8を使用しました。



サービスはますます増えており、一元管理して標準化する必要がありました。ここで初めてコンテナ化を試みました。そのとき、Dockerコンテナーは大きくて重く、それぞれ数百メガバイトでした。



その後、トラフィックとサービスの負荷のバランスに関する問題を解決する必要がありました。ソリューションとして、外部クライアントにはConsulを、内部クライアントにはEurekaを選択しました。サービス間通信gRPC、RMIのさまざまなツールを試しました。私たちはほぼ1年間このように暮らしていましたが、マイクロサービスを正常に作成し、マイクロサービスアーキテクチャを構築する方法を学んだように見えました。

シートベルトを締めてください、私たちは溺れています！

2019年には、マイクロサービスの数が大幅に増加し、100を超えました。可能な場合は、サービス間通信に新しいソリューションを適用し、イベントベースのアプローチを実装しようとしました。



一方、オーケストレーションと依存関係の管理の問題はますます深刻になっています。しかし、2019年の初めにすでに私たちに影響を与えた最大の変更は、Javaの使用に関する会社のポリシーの変更に関連していました。



次に何をするかを選択しました。Oracleにとどまって多額のお金を払うか、独自のオープンjdkビルドに投資するか、実際の代替案を見つけようとします。



3番目のオプションを選択し、OpenJDKプロジェクトの開発に関与した5つの世界的リーダーの1つであるBellSoftと一緒に、一連の会議と議論の後に、新しいバージョンのJavaの移行とパイロットの計画を立てました。 、そしてこれをJava 11への直接の移行と組み合わせました。プロセスは困難でしたが、すべてのテストで、深刻で解決できない問題を感じませんでした。



次のステップは、Kubernetesのコンテナ管理の実装でした。このおかげで、しばらくの間、すべてが順調であるように思われ、私たちは深刻な成功を収めました。しかし、その後、インフラストラクチャに関する次の問題が発生しました。彼女は単に負荷の絶え間ない増加に対処することができませんでした。



単にスケーリングする時間がありませんでした。次の基本的な技術変革の必要性が明らかになりました。そこで、私たちはクラウドテクノロジーに目を向け始め、自分たちでそれらを試すよう努めました。

雲の上に上がる

2020年の初めには、社内テクノロジーの開発、マイクロサービスアーキテクチャの理解と改善において、大きな一歩を踏み出すことが約束されました。先は雲への大きな一歩でした。悲しいかな、彼らが言うように、計画はプレーの過程で修正されなければなりませんでした。



COVID-19のパンデミックにより、クラウドサービスの可能性を徐々に移行して調査するのではなく、パンデミックによるお客様の変化するニーズを満たすための新しいツールを全社で探す必要がありました。私たちは実際に次のマイクロサービスを作成し、同時に新しいテクノロジーを導入し、それでもクラウドインフラストラクチャに移行しました。



私たちにとって、コンテナのサイズは2つの単純な理由で重要になっています。それは、消費されたクラウドコンピューティング能力と、開発者、つまり会社全体がコンテナの持ち上げ、同期と構成、自動テストの実行に費やす時間です。等々。そしてここで、LibericaJDKランタイムを使用したコンパクトなコンテナーの利点と有用性を十分に感じました。



パンデミックの深刻さにもか​​かわらず、数か月で、完全にクラウドインフラストラクチャに基づいて、20のマイクロサービスを実装し、生産的な運用を開始することに成功しました。



2020年の終わりに、私たちはプロセスに焦点を当てました。製品アプローチの構築、マイクロサービスの開発、ビジネスユニットのさまざまな領域に関する独自のメトリックとKPIを持つ個別のチームの選択と形成に多くの時間と労力を費やしました。 。

注文計算サービスの例を使用して、モノリスをマイクロサービスにソーイングする

あなたの忍耐力をテストしないために、マイクロサービスインフラストラクチャを操作する具体的な例とロジックを示したいと思います。標準的なIT環境での典型的な注文計算を見てみましょう。



私たちはさまざまな課題に直面しました。私たちのマスターデータは、バックオフィスのシステムの奥深くにありました。各ITシステムは、データベース、アプリケーションサーバーという古典的なモノリスです。マスターシステムとITランドスケープの他の参加者との統合は、「ポイントツーポイント」として実行されました。つまり、各ITシステムは、独自の方法で、毎回新たに統合されました。



統合は主に、データベースレベルでのレプリケーション、ファイル転送の2つのタイプでした。計算ロジックは各ITシステムで個別に繰り返されました。つまり、異なる開発言語では、隣接するチームのコードでさえ再利用する方法はありません。



さまざまなITシステムのロードマップとリソースコストが異なるため、すべてのシステムで計算ロジックを同時に同期することは非常にコストがかかり、ほとんど不可能でした。

また、お客様からの苦情に対応する際に、正しい価格や割引が提供されなかった理由を特定することは非常に困難でした。







私たちは何をしましたか？注文値を正しく計算するために必要なコンテキストを分析して決定しました。次に、ビジネスドメインを選択し、それらを内部で個別のマイクロサービスに分割しました。そのため、たとえば、注文のコストを計算するプロセスで考慮に入れる必要のある商品に関するデータを強調しました。



キュー（Kafka）を使用して、マスターシステムからオンラインでデータをインポートするサービスを実装しました。データに加えて、製品カテゴリとその属性（products-attribute-service、products-categories-service）で動作するアトミックマイクロサービスを実装しました。価格とプロモーションのコンテキストでドメインについても同じことを行いました。



これとは別に、注文価格を計算するためのロジックと手順を別の注文計算エンジンに移動し、割引基金とプロモーションカードを使用して、価格とコストを計算するための単一の統合ロジックを実装しました。



また、注文決済のロジックを実装するすべてのクライアント向けに、標準化されたRESTAPIを実装しました。サービス間通信には、protobuf3の説明を含むgRPCプロトコルを選択しました。



その結果、今日の標準的なマイクロサービスは次のようになります。これは、GitLab CIを使用してDockerコンテナーに収集され、KubernetesクラスターにデプロイされるSpringBootアプリケーションです。

収益は何ですか？

技術の進化の過程で、まず、サービス自体を開発し、チームを形成するプロセスへのアプローチを改訂しました。私たちは製品アプローチに焦点を合わせ、自律性の最大原則に基づいてチームを募集しました。



同時に、チームが特定のビジネスドメインおよび領域に対応し、したがって、ビジネス機能の責任者とともに、特定のビジネス領域の開発に参加できるようにします。



技術開発の観点から、サービス間通信ツールの1つとして、Kafkaストリームを含むKafkaを使用した非同期接続を選択しました。これにより、チームは他のチームから実質的に独立することができました。また、原子炉プロジェクトなどのリアクティブな開発手法を積極的に使用して実践しています。私たちはまだプロジェクトLoomを試してみたいと思っています。



開発をスピードアップするために、タイミングに大きな影響を与えることができるいくつかの技術的および組織的要因の開発に焦点を合わせました。



技術的な側面は、CI \ CDプロセスの自動化の最適な速度を保証するクラウドテクノロジーへの移行です。ここでは、特定のマイクロサービスの完全なリグレッションとデプロイの速度と期間が重要です。



たとえば、今日、フルラン（すべてのタイプの単体テスト、契約、統合を含む）CI \ CDパイプライン（稼働中の生産的なビジネスアプリケーション用）─これは相互接続された約12〜15のマイクロサービスです）は約31分、つまり7〜8です。 2020年初頭の指標よりも数分少ない。



したがって、結果を待つ時間は約17〜18％少なくなります。この節約により、他の食料品の仕事に取り組むことができます。これは主に、Alpine Linuxをベースにしたコンパクトなコンテナーを使用しているためです。このコンテナーは、1時間ごとに高速化および軽量化されています。



一般的に、マイクロサービス開発の面でより効率的になっています。そして、これはお客様のユーザーエクスペリエンスにプラスの効果をもたらします。速度は現在、当社のオンライン製品（Webサイトおよびモバイルアプリ）の主要な指標の1つであり、Liberica JDKを使用すると、この向上を実現することもできます。これは、パフォーマンスの観点から、お客様に良い体験をもたらします。



さらに、マイクロサービス開発への適切なアプローチにより、製品を市場に投入するまでの時間を大幅に短縮することができました。必要に応じて、展開A \ B、缶詰工場などのさまざまな戦略を使用して、個々のサービスを本番環境に導入する方法を学びました。これにより、マイクロサービスの作業に関するフィードバックをすばやく受け取ることができます。



2か月で、ショッピング体験にいくつかの新しいサービスを開発して実装しました。 2時間以内のいわゆる高速配達（さまざまなタクシーと配達アグリゲーターを使用）と、最も予期しない場所（Pyaterochkaストアやロシアの郵便局、大きな駐車場でも）での注文の発行について話します。ビジネスセンター）。



私たちのマイクロサービスのおかげで、M.Video-Eldorado Groupのクライアントの中には、店から直接家に商品を持ってタクシーに乗る機会があります。

クリエイティブプラン

2021年の計画には、クラウドインフラストラクチャの積極的な開発と、完全にコードとしてのインフラストラクチャの概念（「コードとしてのインフラストラクチャ」）への移行が含まれます。



IstioとAdmiralに基づくサービスメッシュソリューションの形で、マイクロサービスの制御と相互作用のための透過的なソリューションの構築に大きな注意を払う予定です。 Observabilityスタック全体を微調整および改善し、リクエストトレースとメッセージログを監視するために、私たちの前には多くの作業があります。



また、Javaで試してみたいという願望を含め、サーバーレステクノロジーの使用を試みる予定です。さらに、マルチクラウドインフラストラクチャとエコシステムを構築するという、これまでのところ遠いが非現実的ではないアイデアがあります。



私たちのテクノロジースタックに手で触れることに興味がある場合は、遠慮なく、誰にとっても十分な作業があります。ボランティア登録は24時間年中無休で行われます： こちら。 どういたしまして。

福利厚生、ライフハック、個人的な経験

ドミトリーChuikoのJava microservicesのための小さなドッカーコンテナの秘密に、BellSoftシニアパフォーマンスアーキテクト、：

─ . , . Docker-. , : , .



Linux , . JDK. , , .



1.

CentOS CentOS slim. ? Debian. Alpine musl. BellSoft Alpine Linux, — Linux. Liberica JDK 11.0.10 + 11.0.10 Linux.







Liberica EA 3–6 14,7 % Alpine musl java.base. 7,6 %. Docker-, JRE java.base. Liberica JRE EA — 16 %.



Liberica Lite . , , — . - Java SE JVM, Standart, JIT- (C1, C2, Graal JIT Compiler), (Serial, Parallel, CMS, G1, Shenandoah, ZGC) serviceability, .



2. JDK

— jdeps JLINK. . Java (JDeps). - Java, . . JAR, , . JDeps JDK, Java-. , , .







jdeps , java.base. jlink. , BellSoft Docker- java.base. DockerHub, .



docker run –rm bellsoft/liberica – openjdk -demos- asciiduke.







CLI-like java.base. Liberica JDK Lite Alpine Linux musl 40,4 .



.



Enjoy!