Dodo IS アーキテクチャの歴史: バック オフィス パス

ハブルは世界を変えています。 私たちはXNUMX年以上ブログを続けてきました。 約 XNUMX か月前、私たちはハブロビ人から次のような完全に論理的なフィードバックを受け取りました。「ドードー、あなたはどこでも自分のシステムがあると言っています。 そして、このシステムは何ですか？ そして、なぜピザチェーンにそれが必要なのでしょうか?

私たちは座って考え、あなたの言うことが正しいことに気づきました。 私たちはすべてを指で説明しようとしますが、それはばらばらになってしまい、システムの完全な説明はどこにもありません。 こうして、情報を収集し、著者を探し、Dodo IS に関する一連の記事を書くという長い旅が始まりました。 さあ行こう！

謝辞: フィードバックをお寄せいただきありがとうございます。 彼のおかげで、私たちは最終的にシステムを説明し、技術レーダーを編集し、間もなくプロセスの大規模な説明を公開する予定です。 あなたがいなかったら、私たちはさらに5年間そこに座っていたでしょう。

連載「Dodo ISとは？」 について語ります:

1. ドードー IS の初期のモノリス (2011 ～ 2015)。 （進行中...）
2. バックオフィスのパス: 拠点とバスを分離します。 （あなたはここにいる）
3. クライアント側のパス: ベース上のファサード (2016-2017)。 （進行中...）
4. 本物のマイクロサービスの歴史。 (2018-2019)。 （進行中...）
5. モノリスの切断が完了し、アーキテクチャが安定化しました。 （進行中…）

他に知りたいことがあれば、コメントに書き込んでください。

年代順の記述に対する著者の意見
私は定期的に新入社員向けに「システムアーキテクチャ」をテーマにしたミーティングを開催しています。 私たちはこれを「Dodo IS アーキテクチャの紹介」と呼んでおり、新しい開発者のためのオンボーディング プロセスの一部です。 何らかの形で私たちの建築やその特徴について語ることで、私はその記述に対してある種の歴史的なアプローチを生み出しました。

従来、私たちはシステムを一連のコンポーネント (技術レベルまたはより高いレベル)、つまり何らかの目標を達成するために相互作用するビジネス モジュールとして見てきました。 そして、そのような見方がデザインとして正当化されるとしても、それは説明や理解にはまったく適していません。 ここにはいくつかの理由があります。

• 現実は紙の上のものとは異なります。 すべてが計画通りにうまくいくわけではありません。 そして、それが実際にどのようになり、機能するかに興味があります。
• 一貫した情報の提示。 実際、最初から現在の状態まで時系列に進むことができます。
• 単純なものから複雑なものまで。 普遍的ではありませんが、私たちの場合はそうです。 アーキテクチャは、より単純なアプローチからより複雑なアプローチに移行しました。 多くの場合、複雑さによって実装速度と安定性の問題が解決され、非機能要件のリストにある他の数十の特性も解決されました (ここに 他の要件との複雑さの対比についてはよく説明されています)。

2011 年の Dodo IS アーキテクチャは次のようになっていました。

2020 年になると少し複雑になり、次のようになります。

この進化はどのようにして起こったのでしょうか? システムのさまざまな部分が必要なのはなぜですか? どのようなアーキテクチャ上の決定が行われたのか、またその理由は何ですか? この一連の記事で調べてみましょう。

2016 年の最初の問題: なぜサービスはモノリスから離れる必要があるのか

このサイクルの最初の記事は、モノリスから最初に分離されたサービスについての記事になります。 状況を説明するために、2016 年の初めまでにシステムにどのような問題があり、サービスの分離に対処する必要があったのかを説明します。

単一の MySql データベース。その時点で Dodo IS に存在していたすべてのアプリケーションがレコードを書き込みます。 結果は次のとおりです。

• 重い負荷 (リクエストの 85% が読み取りに占められています)。
• 基地が成長しました。 このため、コストとサポートが問題となっていました。
• 単一障害点。 データベースに書き込みを行う XNUMX つのアプリケーションが突然、より積極的に書き込みを行うようになると、他のアプリケーションもそれを感じ取ってしまいます。
• ストレージとクエリの非効率性。 多くの場合、データは、一部のシナリオには便利でも、他のシナリオには適さない構造で保存されていました。 インデックスにより一部の操作は高速化されますが、他の操作は遅くなる可能性があります。
• 一部の問題は、急遽作成したキャッシュとデータベースへのリードレプリカによって解決されましたが (これについては別の記事で説明します)、時間稼ぎができただけで、根本的な解決にはなりませんでした。

問題はモノリスそのものの存在だった。 結果は次のとおりです。

• シングルおよびレアリリース。
• 大人数での共同開発の難しさ。
• 新しいテクノロジー、新しいフレームワーク、ライブラリを導入できない。

基地とモノリスの問題は、たとえば 2018 年初頭の墜落事故に関連して何度も説明されてきました (ムンクのように、あるいは技術的負債について一言, ドードーISが停止した日。 非同期スクリプト и フェニックス家のドードー鳥の物語。 ドードーISの大崩壊）なので、あまりこだわりません。 サービスを開発する際に、より柔軟性を持たせたかったということだけは言っておきます。 まず第一に、これはシステム全体で最も負荷が高くルートである認証とトラッカーに関するものでした。

バックオフィスのパス: 個別のベースとバス

章のナビゲーション

1. モノリス計画 2016
2. モノリスのアンロードの開始: 認証とトラッカーの分離
   
3. 認証って何をするの？
4. 荷物はどこから来たのですか？
5. アンロード認証
6. トラッカーは何をするのですか?
7. 荷物はどこから来たのですか？
8. アンロードトラッカー

モノリス計画 2016

ここに Dodo IS 2016 モノリスの主要なブロックがあり、そのすぐ下に主なタスクの記録があります。

レジの配達。 宅配業者を計算し、宅配業者に注文を出します。
コンタクトセンター。 オペレーターによる注文の受付。
Site。 当社のウェブサイト (dodopizza.ru、dodopizza.co.uk、dodopizza.by など)。
認証。 バックオフィス向けの認可および認証サービス。
トラッカー。 キッチンの注文トラッカー。 注文の準備時に準備ステータスをマークするサービス。
レストランのレジ。 レストランでの注文の受け取り、レジ係のインターフェイス。
輸出。 会計用に 1C でレポートをアップロードします。
通知と請求書。 キッチンでの音声コマンド (「新しいピザが到着しました」など) + 宅配業者向けの請求書印刷。
シフトマネージャー。 シフト マネージャーの仕事のためのインターフェイス: 注文のリスト、生産性グラフ、従業員のシフトへの移動。
事務長。 フランチャイジーとマネージャーの仕事のためのインターフェイス: 従業員の受付、ピッツェリアの仕事に関するレポート。
レストランスコアボード。 ピッツェリアのテレビにメニューが表示されます。
管理者。 特定のピッツェリアの設定: メニュー、価格、会計、プロモーション コード、プロモーション、Web サイトのバナーなど。
従業員の個人アカウント。 従業員の勤務スケジュール、従業員に関する情報。
キッチンモチベーションボード。 キッチンに吊り下げられ、ピザ職人のスピードを表示する別のスクリーン。
コミュニケーション。 SMS と電子メールを送信します。
ファイルストレージ。 静的ファイルを受信および発行するための独自のサービス。

問題を解決するための最初の試みは私たちを助けてくれましたが、それは一時的な休息にすぎませんでした。 それらはシステムソリューションにはならなかったので、基地について何かをしなければならないことは明らかでした。 たとえば、一般的なデータベースをいくつかのより特殊なデータベースに分割します。

モノリスのアンロードの開始: 認証とトラッカーの分離

他のサービスよりもデータベースの記録と読み取りが多かった主なサービスは次のとおりです。

1. 認証。 バックオフィス向けの認可および認証サービス。
2. トラッカー。 キッチンの注文トラッカー。 注文の準備時に準備ステータスをマークするサービス。

認証って何をするの？

認証は、ユーザーがバック オフィスにログインするためのサービスです (クライアント側に別の独立した入り口があります)。 また、要求内で、必要なアクセス権が存在すること、およびこれらのアクセス権が最後のログイン以降変更されていないことを確認するために呼び出されます。 それを通して、デバイスがピッツェリアに侵入します。

たとえば、ホールに吊り下げられたテレビに、完了した注文のステータスを示すディスプレイを開きたいとします。 次に、auth.dodopizza.ruを開き、「デバイスとしてログイン」を選択すると、シフトマネージャーのコンピュータの特別なページに入力できるコードが表示され、デバイス（デバイス）の種類を示します。 テレビ自体がピッツェリアの目的のインターフェイスに切り替わり、そこに注文の準備ができている顧客の名前が表示され始めます。

荷物はどこから来たのですか？

バック オフィスの各ログイン ユーザーは、リクエストごとにデータベース、ユーザー テーブルに移動し、SQL クエリを通じてユーザーを抽出し、このページに必要なアクセス権と権限があるかどうかを確認します。

各デバイスはデバイス テーブルに対してのみ同じことを行い、その役割とアクセスをチェックします。 マスター データベースへのリクエストが多数あると、マスター データベースがロードされ、これらの操作のための共通データベースのリソースが浪費されます。

アンロード認証

認証には分離されたドメインがあります。つまり、ユーザー、ログイン、またはデバイスに関するデータは (当面は) サービスに入り、そこに残ります。 誰かがそれらを必要とする場合、その人はデータを得るためにこのサービスにアクセスします。

そうだった。 元の作業スキームは次のとおりです。

それがどのように機能したかを少し説明したいと思います。

1. 外部リクエストがバックエンド (Asp.Net MVC) に到達し、Redis(1) からセッション データを取得するために使用されるセッション Cookie をもたらします。 これには、アクセスに関する情報が含まれており、コントローラーへのアクセスがオープンになっているか (3,4)、オープンしていないかのいずれかです。
2. アクセスできない場合は、認証手続きが必要です。 ここでは、ログインページへの遷移ですが、簡単のため同じ属性内のパスの一部として示しています。 肯定的なシナリオの場合、正しく完了したセッションを取得し、バックオフィス コントローラーに進みます。
3. データがある場合は、ユーザー データベース内でそのデータの関連性を確認する必要があります。 彼の役割は変わったので、今はページに登場させるべきではないでしょうか? この場合、セッションを受信した後 (1)、データベースに直接移動し、認証ロジック層 (2) を使用してユーザーのアクセスを確認する必要があります。 次に、ログイン ページに移動するか、コントローラに移動します。 非常にシンプルなシステムですが、完全に標準ではありません。
4. すべてのプロシージャが渡された場合は、コントローラーとメソッドのロジックをさらにスキップします。

ユーザー データは他のすべてのデータから分離され、別のメンバーシップ テーブルに保存され、AuthService ロジック層の関数が API メソッドになる可能性があります。 ドメインの境界は、ユーザー、その役割、アクセス データ、アクセスの許可と取り消しなど、非常に明確に定義されています。 すべてが別のサービスで取り出せるように見えます。

なる。 そこで彼らはこうしました:

このアプローチには多くの問題があります。 たとえば、プロセス内のメソッドを呼び出すことは、http 経由で外部サービスを呼び出すことと同じではありません。 レイテンシー、信頼性、保守性、操作の透明性がまったく異なります。 アンドレイ・モレフスキーはそのような問題について報告書の中でさらに詳しく語っている。 「マイクロサービスの 50 の色合い」.

認証サービスとそれに付随するデバイス サービスは、バック オフィス、つまり運用環境で使用されるサービスとインターフェイスに使用されます。 クライアント サービス (Web サイトやモバイル アプリケーションなど) の認証は、Auth を使用せずに個別に行われます。 分離には約 XNUMX 年かかりましたが、現在私たちは再びこのテーマに取り組み、システムを新しい認証サービス (標準プロトコルを使用) に移行しています。

なぜ別居にこれほど時間がかかったのでしょうか？
途中で多くの問題が発生し、作業が遅れました。

1. 私たちは、ユーザー、デバイス、認証データを国固有のデータベースから XNUMX つに移動したいと考えていました。 これを行うには、すべてのテーブルと使用法を int 識別子からグローバル UUId 識別子に変換する必要がありました (最近このコードを作り直しました) ロマン・ブキン「ウイド - 小さな構造の大きな物語」 そしてオープンソースプロジェクト プリミティブ）。 ユーザー データ (個人情報であるため) の保存には制限があり、国によっては個別に保存する必要があります。 ただし、ユーザーのグローバル ID は必須です。
2. データベース内の多くのテーブルには、操作を実行したユーザーに関する監査情報が含まれています。 これには、一貫性を保つための追加のメカニズムが必要でした。
3. API サービスの作成後、別のシステムへの長期にわたる段階的な移行期間がありました。 切り替えはユーザーにとってシームレスである必要があり、手動作業が必要でした。

ピザ屋におけるデバイス登録スキーム:

認証およびデバイス サービスを抽出した後の一般的なアーキテクチャ:

注意。 2020 年に向けて、OAuth 2.0 認証標準に基づいた新しいバージョンの認証に取り組んでいます。 この標準は非常に複雑ですが、パススルー認証サービスの開発には役立ちます。 記事では「認可の微妙さ: OAuth 2.0 テクノロジーの概要» 私たちアレクセイ・チェルニャエフは、皆さんが標準を勉強する時間を節約できるように、標準についてできるだけ簡単かつ明確に説明しようとしました。

トラッカーは何をするのですか?

次に、ロードされたサービスの XNUMX つ目について説明します。 トラッカーは XNUMX つの役割を果たします。

• 一方では、そのタスクは、キッチンの従業員に、現在どのような注文が処理されているか、どの製品を調理する必要があるかを示すことです。
• 一方、厨房内のすべてのプロセスをデジタル化します。

新しい製品が注文に含まれると (ピザなど)、ロールアウト トラッカー ステーションに送られます。 このステーションにはピザ職人がいて、必要なサイズのパンを取り出してそれを伸ばします。その後、彼はトラッカータブレットに仕事を完了したことを記録し、丸めた生地のベースを次のステーション「開始」に移します。 。

そこで、次のピザ職人がピザを詰め、タスクを完了してピザをオーブンに入れることをタブレットに記録します (これもタブレットに記録する必要がある別のステーションです)。 このようなシステムは Dodo の最初から、そして Dodo IS の存在の最初からありました。 すべての取引を完全に追跡し、デジタル化することができます。 さらに、トラッカーは特定の製品の調理方法を提案し、製造計画に従って各種類の製品をガイドし、製品の最適な調理時間を保存し、製品に対するすべての操作を追跡します。

トラッカー「ラスカットカ」のステーションでのタブレットの画面はこんな感じ

荷物はどこから来たのですか？

各ピッツェリアにはトラッカー付きのタブレットが約 2016 台あります。 100 年には 600 軒以上のピッツェリアがありました (現在は 10 軒以上)。 各タブレットは XNUMX 秒ごとにバックエンドにリクエストを送信し、注文テーブル (クライアントとの接続と住所)、注文構成 (製品との接続と数量の表示)、モチベーション会計テーブル (押した時間が記録されます)。 ピザメーカーがトラッカー上の製品をクリックすると、これらのテーブルすべてのエントリが更新されます。 注文テーブルは一般的なもので、注文を受け付けたときの挿入、システムの他の部分からの更新、およびピザ屋に吊り下げられ、完成した注文を顧客に表示するテレビなどの多数の読み取り値も含まれます。

負荷と格闘している間、ありとあらゆるものがキャッシュされ、ベースの非同期レプリカに転送されると、トラッカーによるこれらの操作はマスター ベースに送られ続けました。 遅延があってはならず、データは最新である必要があり、同期がずれていることは許容されません。

また、独自のテーブルとインデックスがないため、用途に合わせてカスタマイズされたより具体的なクエリを作成できませんでした。 たとえば、トラッカーにとって、注文テーブルにピザ屋のインデックスがあると効率的である可能性があります。 ピッツェリアの注文は常にトラッカー データベースから削除されます。 同時に、注文を受ける場合、それがどのピッツェリアに該当するかはそれほど重要ではなく、どのクライアントがこの注文を行ったかの方が重要です。 そして、クライアントのインデックスが必要であることを意味します。 また、トラッカーは、注文に関連付けられた印刷されたレシートやボーナス プロモーションの ID を注文テーブルに保存する必要もありません。 この情報は当社のトラッカー サービスには関係ありません。 一般的なモノリシック データベースでは、テーブルはすべてのユーザー間で妥協するしかありません。 これは元々の問題の XNUMX つでした。

そうだった。 元のアーキテクチャは次のとおりです。

個別のプロセスに分離された後でも、コード ベースのほとんどはさまざまなサービスで共通のままでした。 コントローラー以下はすべて単一であり、同じリポジトリに存在していました。 私たちは、サービス、リポジトリ、共通のテーブルが配置される共通のベースの共通の方法を使用しました。

アンロードトラッカー

トラッカーの主な問題は、異なるデータベース間でデータを同期する必要があることです。 これは、Auth サービスの分離との主な違いでもあり、順序とそのステータスは変更される可能性があるため、別のサービスで表示する必要があります。

レストランのチェックアウトで注文を受け付けます (これはサービスです)。注文はデータベースに「承認済み」ステータスで保存されます。 その後、トラッカーに到達し、ステータスを「キッチン」から「梱包済み」にさらに数回変更します。 同時に、レジ係またはシフト マネージャー インターフェイスからの外部の影響が注文に発生する可能性があります。 注文ステータスとその説明を表に示します。

注文ステータスを変更するスキームは次のようになります。

ステータスはシステム間で変化します。 そして、ここでのトラッカーは、データが閉じられた最終的なシステムではありません。 このような場合に考えられるパーティション分割のアプローチをいくつか見てきました。

1. すべての注文アクションを XNUMX つのサービスに集中させます。 私たちの場合、このオプションでは注文を処理するには多すぎるサービスが必要になります。 ここで止めれば、XNUMXつ目のモノリスが得られるでしょう。 私たちは問題を解決しません。
2. あるシステムが別のシステムに電話をかけます。 XNUMX 番目のオプションはすでにより興味深いものです。 しかし、これを使用すると、呼び出しのチェーンが可能になります (連鎖的な障害)、コンポーネントの接続性が高くなり、管理がより困難になります。
3. 私たちはイベントを主催し、各サービスはイベントを通じて他のサービスと通信します。 その結果、選択されたのは XNUMX 番目のオプションであり、これに従ってすべてのサービスが相互にイベントを交換し始めます。

XNUMX 番目のオプションを選択したということは、トラッカーが独自のデータベースを持ち、注文の変更ごとに、これに関するイベントを送信し、他のサービスがサブスクライブし、マスター データベースにも分類されることを意味します。 これを行うには、サービス間でメッセージを確実に配信するサービスが必要でした。

その時までに、すでに RabbitMQ がスタックに存在していたので、それをメッセージ ブローカーとして使用することが最終決定されました。 この図は、レストランのレジ係からトラッカーを介した注文の遷移を示しており、そこでステータスが変化し、マネージャーの注文インターフェイスに表示されます。 鉄鋼:

段階的な注文パス
注文パスは、注文ソース サービスの XNUMX つから始まります。 こちらがレストランのレジ係です。

1. チェックアウト時には注文の準備が完了し、トラッカーに送信する段階に入ります。 トラッカーがサブスクライブされているイベントがスローされます。
2. トラッカーは、自分自身で注文を受け付けると、その注文を自身のデータベースに保存し、イベント「トラッカーによる注文受付」を作成して RMQ に送信します。
3. 注文ごとにイベント バスにすでにサブスクライブされているハンドラーがいくつかあります。 私たちにとっては、モノリシックな基盤と同期を取ることが重要です。
4. ハンドラーはイベントを受信し、そのイベントから重要なデータを選択します。この場合、これは注文のステータス「トラッカーによる承認」であり、メイン データベース内の注文エンティティを更新します。

誰かがモノリシックテーブル注文からの注文を必要とする場合、そこからそれを読み取ることもできます。 たとえば、シフト マネージャーの注文インターフェイスには次のものが必要です。

他のすべてのサービスは、トラッカーからの注文イベントをサブスクライブして、それを自分自身で使用することもできます。

しばらくしてから注文が処理されると、まずデータベース (トラッカー データベース) 内のステータスが変更され、すぐに「OrderIn Progress」イベントが生成されます。 また、RMQ にも入り、そこからモノリシック データベース内で同期され、他のサービスに配信されます。 途中でさまざまな問題が発生する可能性があります。それらの詳細については、Zhenya Peshkov のレポートを参照してください。 トラッカーにおける結果整合性の実装詳細について.

認証とトラッカーの変更後の最終アーキテクチャ

中間結果をまとめると次のようになります。 当初、Dodo IS システムの XNUMX 年間の歴史を XNUMX つの記事にまとめようと考えていました。 進化の段階について手早く簡単に話したいと思いました。 しかし、座って資料を読んでみると、すべてが思っているよりもはるかに複雑で興味深いことに気づきました。

このような資料の利点 (または欠点) を熟考した結果、本格的な出来事の記録、詳細な回顧、および過去の決定の分析がなければ、継続的な開発は不可能であるという結論に達しました。

私たちのこれまでの道のりについて知っていただくことが有益で興味深いものであったことを願っています。 次の記事で Dodo IS システムのどの部分を説明するか、コメントに書くか投票するかの選択を迫られています。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

次の記事では、Dodo IS のどの部分について知りたいですか?

• 視聴者の３８%がドードー諸島の初期のモノリス (2011-2015)14

• 視聴者の３８%が最初の問題とその解決策 (2015-2016)14

• 視聴者の３８%がクライアント側のパス: ベースよりもファサード (2016-2017)12

• 視聴者の３８%が実際のマイクロサービスの歴史 (2018-2019)21

• 視聴者の３８%がモノリスの完全な切断とアーキテクチャの安定化26

• 視聴者の３８%が今後のシステム開発計画について17

• 視聴者の３８%がDodo IS11 については何も知りたくない

58 人のユーザーが投票しました。 6名のユーザーが棄権した。

出所： habr.com