仕事内容
ECシステムをマイクロサービスに分割します。
背景: あなたが今、新興企業の CTO であるとします。開発チームは約 30 人で、そのうち 5 人のフロントエンドと 25 人のバックエンドです。バックエンドの開発者は全員 Java です。今、あなたは、 0 ビジネスからの小規模プログラムの電子商取引の場合は、マイクロサービス分割アーキテクチャとマイクロサービス インフラストラクチャの選択を設計してください。
必須：
サービス分割の考え方を明確にし、分割システムのアーキテクチャの絵を描く必要があります。
マイクロサービス インフラストラクチャの選択を明確にし、マイクロサービス フレームワークを選択する必要があります。
1～2ページのPPTを使用します。
回答
分割方法 - 事業別分割
0からのスタートなので事業別分割を選択します。
ビジネスの境界線を分ける
ビジネスの専門家がいるかどうかに関係なく、電子商取引システムは比較的明確なモデルを持つシステムであるため、次のように業界の実装を直接参照してください
。
サービスの分割
三銃士の原則によれば、平均 3 人の開発者が 1 つのマイクロサービスを担当します。現在、バックエンドは 25 個あり、最大 25/3 = 8 個のマイクロサービスが存在できます。
5つのフロントエンドをどのように分割するか? マイクロサービスは主にエンドツーエンドの階層化サービスのビジネス層に位置し、ユーザー層やプレゼンテーション層とはほとんど関係がないため、ここではフロントエンド開発者の数は考慮されていません。
現在、10 個の事業ドメインが分割されており、そのうち 2 つを統合する必要がありますが、通常は事業ごとに分割されているため、同じ大きな事業ドメインに属するサブドメインは事業の類似性に応じて統合されます。
商品とショッピングカートを 1 つのサービスに統合する。
通常、注文と支払いは 1 つのトランザクションで行う必要があるため、注文と支払いを 1 つのサービスに統合すると、システムの複雑さを軽減できます。同時に、合併後の内部の複雑さのため、4 人の開発者がこのサービスの責任者に割り当てられました。
最終的なサービス区分とシステム構成は以下の通りです
実装方法
ゼロからのスタートなのでワンステップで実現できるものを選択します。
マイクロサービス インフラストラクチャの選択
バックエンド開発者は全員 Java 言語を使用します。
規模が小さいスタートアップ企業ですので、無駄なメンテナンスコストを避けるために Spring Cloud または Dubbo を選択してください。
Spring Cloud は適用範囲が広く、コンポーネントがより包括的であるため、Spring Cloud がマイクロサービス インフラストラクチャとして選択されています。
注記 パート
マイクロサービス アーキテクチャ 詳細説明
マイクロサービスと SOA
SOA の目的は、企業内の既存の異種 IT システムを接続し、冗長構築を削減することです。その手段は、ESB を介してさまざまなシステムを疎結合することです。その結果、ESB ロジックが肥大化し、パフォーマンスが低下し、スケーリングが困難になります。スマート パイプとダム エンドポイント。
Martine Fowler 氏の言葉を借りれば、マイクロサービスの目的は、大規模なシステムを小さなサービスに分割し、軽量のメカニズムを通じて相互に通信し、サービスを自動的にデプロイできることを強調することです。スマート エンドポイントとダム パイプ。
両者の関係については、次のようないくつかの見解がありますが、最後の見解が正確です。つまり、両者の間には多くの違いがありますが、サービスの方向性という点では同じです。
Qin Jinwei氏の説明によると、SOAとマイクロサービスの全体的なアーキテクチャは異なる
SOA/ESB: プロキシ呼び出し、直接拡張
分散サービス: 直接呼び出し、サイド拡張
マイクロサービスの発展に伴い、マイクロサービス インフラストラクチャは強力かつ複雑になりました。
モノリシック アーキテクチャ、SOA、およびマイクロサービス アーキテクチャは、サーバー側アーキテクチャの進化におけるいくつかの異なる段階です。
マイクロサービスと他のスケーラブルなアーキテクチャの関係
華蔡氏は、「DDD実践講座」と同様、クリーンアーキテクチャをマイクロサービスを実装するためのアーキテクチャ形式とみなしている。
ただし、「DDD実践講座」では視点が少し異なり、DDDの4層アーキテクチャもマイクロサービスの具体的な形式として使われており、ここでいう階層化アーキテクチャとはより一般的な意味でのものです。
階層化アーキテクチャとの関係
階層化されたアーキテクチャは、エンドツーエンドのアーキテクチャ、または特定のルールに従って異なるレベルに分割された単一システムの内部アーキテクチャです。J2EE も階層型アーキテクチャの一種です。
マイクロサービスは、エンドツーエンドの階層化アーキテクチャにおけるビジネス層のアーキテクチャです。
「DDD実践講座」では、DDDの階層構造を直接解説します。
そして、単一のバックエンド サービスの 3 層アーキテクチャと上記の 4 層アーキテクチャを比較します。
クリーンアーキテクチャとの関係
単一のマイクロサービスのアーキテクチャは、クリーンなアーキテクチャにすることができます。
マイクロカーネルアーキテクチャとの関係
単一のマイクロサービスのアーキテクチャは、リスク管理、マーケティング、ワークフロー マイクロサービスなどのマイクロカーネル アーキテクチャにすることができます。
「DDD 実践コース」では、マイクロサービスで利用できるアーキテクチャ モデル、ヘキサゴナル アーキテクチャ (「ポート アダプタ アーキテクチャ」とも呼ばれます) も提供します。
SOA アーキテクチャと比較
して、マイクロサービスのコストはどれくらいですか? またはその欠点は何ですか?
マイクロサービスのコストは、システムノード間の関係が非常に複雑になり、ビジネスが多数のサービスノードを経由し、ノード間でメッシュ接続が形成されることだと思います。しかし、SOA は異なります。ESB を中間ノードとして導入することにより、メッシュ接続が「ハブスポーク」タイプのリンクに変更されます。
これにより、アーキテクチャ内の接続が増加し、組織内の通信コストが増加しました。
マイクロサービス アーキテクチャの罠と課題
6 つの主要な罠
私は個人的に、これらの罠は、マイクロサービスの全体的なネットワーク接続によって引き起こされるシステムの複雑さの増加によって引き起こされると考えています。
粒度が細かすぎる
1. 複雑なサービス関係
これにより、単一の小規模サービスの内部の複雑さは軽減されますが、システム間の接続の外部の複雑さは増大します。要件分析、ソリューション設計、テスト、導入…難易度は上がります。
2. チーム効率の低下
要件分析、ソリューション設計、テスト、展開...作業負荷は増加します。これが組織への影響です。
3. 問題を特定するのが難しい
ノード間の接続が高すぎるため、1 つのノードに障害が発生すると、多くのノードに問題が発生します。
4. システムパフォーマンスの低下
呼び出しチェーンが長くなるほど、1 つのリクエストにかかる時間も長くなります。分割後は、単一サービスの処理パフォーマンスが向上しますが、コール チェーンによる消費を補うことはできません。消費時間を決定する主な要因はストレージ システムの呼び出しであるため、単一のサービスに分割した後は、単一のサービスの向上には限界があり、呼び出しチェーンで消費されるパフォーマンスが単一のサービスのパフォーマンスの向上を超えます。 。
インフラの不足
5. すぐに納品できない
自動テストのサポートがなければ、テストごとに多数のインターフェイスをテストする必要があります。
自動展開サポート、人間による操作、メンテナンスがなければ、手は麻痺してしまいます。
自動監視がなければ、障害箇所ごとに、数十のマシンと数百のマイクロサービスのさまざまな状態とさまざまなログ ファイルを手動でチェックする必要があります。
6. サービス管理が混乱している
サービスルートが必要です
障害の切り分けが必要
サービスの登録と検出が必要です
上記の落とし穴については、次のことが必要です。
適切な粒度
充実した基本サービス
マイクロサービス アーキテクチャの 4 つの課題
データ分散がもたらす課題
1. データは異なるサービスノードに分散され、分散されたものが生成されます
マイクロサービスの集約はデータの変更と永続化の基本単位であり、各集約はデータの永続性を実現するウェアハウスに対応します。
エンティティと値オブジェクトがデータベース テーブルまたはデータベース テーブルのオブジェクトとして理解される場合、集約はデータベースまたはスキーマになります。
サービスがルールとデータとして理解される場合、集約には対応するウェアハウスがあるため、理論的には集約はサービスに対応します。
マイクロサービスとアグリゲーションは 1 対 1 ではなく、1 対多です。集約は、必要に応じてマイクロサービス間で移行できます。たとえば、ビジネス ニーズに従って、または品質属性に従って (頻繁にアクセスされる集約を独立したマイクロサービスに移行する)、または頻繁な変更の程度に従って、分離を実行します (頻繁に変更されるサービスとあまり変更されないサービスを分割します)。さまざまなサービスに)。
集約内のデータの強い一貫性と、集約間のデータの最終的な一貫性。
トランザクション内で変更できる集約の状態は最大 1 つです。
2. グローバル冪等性を確保する必要がある。分散呼び出しは失敗して再試行される可能性があるため、冪等性を保証する必要があります。
サービス分散によってもたらされる課題
3. インターフェイスには互換性が必要です
4. インターフェースループ呼び出しによる問題を解決するには
BASE、CAP、線形化可能性の 4 つの主要な課題への対応
前述したように、集約内のデータは強い整合性を持たず、集約間のデータは最終整合性モデルを採用します。最終的な整合性に関する BASE 理論があります。
BASE:Basically Available (基本的に利用可能)、Soft State (ソフト状態)、および最終的に Consistent (最終的な一貫性)。最終的な整合性は、分散システムの CAP 理論によって説明されます。
CAP は、一貫性、可用性、およびパーティション許容度の 3 つのプロパティで構成されます。このうち、パーティションフォールトトレランスとは、ネットワーク上で元々接続されていたマシンが複数の独立した部分に分割されてしまうネットワーク上の問題を指し、スプリットブレインとも呼ばれます。
分割耐性を放棄すればスタンドアロンデータベースとなり、分散システムではPを放棄することは不可能であり、分割が発生する前提で、整合性と可用性を組み合わせるのではなく、どちらかを選択する必要があるAP および CP の 3 つのプロパティ。CA および CA から 3 つのうち 1 つを選択します (CA はスタンドアロン データベースに相当します)。
また、CAPのCは線形化可能性（Linearizability）を指しますが、分散環境では整合性と非整合性だけでなく、客観的に整合性があるか、整合性があるように見えるかなど、中間の選択肢も存在します。
状態の一貫性とは、データの客観的状態と実際の状態に反映される一貫性を指します。
操作の一貫性とは、プロトコルで合意された操作を通じて外部ユーザーが読み取ることができるデータの一貫性を指します。たとえば、さまざまなセッションの一貫性、つまりクライアントから見て一貫性があるように見えます。
線形整合性/線形化可能性は、
「分散金融アーキテクチャ コース」から取得されます。
線形整合性の英語名は Linearizability です。線形一貫性は、分散システムにおいて最も重要な一貫性です。線形一貫性とは、分散環境における直列化可能性であると理解できます。
シリアル化可能
データベース内の複数のトランザクションは同時に実行でき、シリアル化によってこれらの同時実行トランザクションの結果が指定されます。これには、これらの同時実行トランザクションの最終結果が、それらの順次実行の結果と常に等しいことが必要です。
上記のように、トランザクション T1 と T2 の実行順序を調整した後、これら 2 つのトランザクションの間に時間の重複はなくなります。このとき、これら２つのトランザクションは順次実行される。
同時に、トランザクションの実行順序を調整した後の最終的な読み取りおよび書き込み結果は、調整前とまったく同じになります。
最後に、この調整結果は一意ではありません。
競合の直列化可能性
「葛藤」とは、読むことと書くこと、読むことと書くこと、書くことと書くことの三つの葛藤を指します。シリアル化可能性が競合している場合でも、トランザクションのシリアル化可能な結果と同等のものが必要です。ただし、シリアル化と同じではありません。シリアル化では同等のシリアル結果を見つけるだけで済みますが、競合のシリアル化では、同等のシリアル実行のために一連の競合のない交換プロセスを通じて元の実行シーケンスを変更する必要があります。
2 つの操作間に競合がない場合、それらの順序を交換できます (非競合交換プロセスとも呼ばれます)。
2 つの操作の目的は異なります
どちらの操作も読み取り操作です
例は次のとおりです。
データベースの実装プロセスでは、トランザクションの実行順序は一般にロックを通じて調整され、ロックを使用すると一般に競合のシリアル化が発生する可能性があります。ロックを通じてシリアル化を実現する方法は、2PL (Two Phase Lock) と呼ばれます。
2PL（二相ロック）
2PL のプロセスは非常に単純です。どのトランザクションでも、このトランザクションは最初にアクセスされたすべてのリソースをロックし、次にすべてのリソースにアクセスし、最後にすべてのロックを解放する必要があります。ロックとロック解除のプロセスを交互に行うことはできません。
2PL プロセスでのロック数の変更プロセス (以下は最も一般的なプロセスであり、他にもバリエーションがあります。たとえば、以下を参照してください。MySQL ではバリアントが使用されています)。これは、ロックがオペレーションまで継続的にオンデマンドで取得されることを意味します。すべてのロックが保持された後にのみ実行できます。
2PL を使用したシリアル化可能性の競合
基本的な原則は、最初にロックされたトランザクションはロックを持ち、後続のトランザクションはロックを保持しないと同じリソースに書き込むことができない、つまり 2 つのトランザクション間に競合がないということです。そのため、これらのトランザクションは自然に交換可能な実行順序になります。したがって、競合の直列化可能性が実現します。
複数のロックが保持されている可能性があるため、より具体的には、最初のトランザクションが最初のロックを解放する前に、そのロックは他のすべてのトランザクションのすべての操作と競合しないため、競合のない操作を通じてロックを交換できます。他のトランザクションの前の最初のトランザクション。このようにして、最初のトランザクションを残りのトランザクションから分離できます。
2PL では、アクセスされるすべてのデータが何であるかを事前に知る必要があるため、ロックを解除する前にすべてをロックできます。ロックを解放すると、他のロックされたリソースを追加できなくなります。これが 2PL の制限です。
しかし、MySQL は、事前に知っておく必要があるという点と、オンデマンドでロックするという点を改善したようです。
MySQLの2段階ロック（内容は「MySQL実戦45講座」「分散データベース30講座」をまとめたものです）
次の例のように
上の図では、トランザクション B の更新ステートメントはブロックされます。これは、InnoDB トランザクションでは、必要なときに行ロックが追加されますが、必要がなくなってもすぐに解放されず、トランザクションが終了するまで解放されないためです。取引を開始します。これは、次のような 2 フェーズ ロック プロトコル、またはバリアント厳密 2 フェーズ ロック プロトコル (Strict 2PL、S2PL、つまり、トランザクションはトランザクションが終了するまで、取得したすべての書き込みロックを常に保持します) でもあります。
したがって、トランザクションで複数の行をロックする必要がある場合は、ロックの競合を引き起こし、同時実行性に影響を与える可能性が最も高いロックをできるだけ後ろに置く必要があります。たとえば、映画のチケットを購入するビジネス シナリオは次のとおりです。
-
顧客 A の口座残高から映画チケットの代金を差し引きます。
-
映画チケットの価格を劇場 B のアカウント残高に追加します。
-
トランザクションログを保存します。
同時に劇場 B のチケットを購入したい別の顧客 C がいる場合、これら 2 つのトランザクション間の矛盾の部分はステートメント 2 であると想像してください。同じ劇場アカウントの残高を更新したいため、同じデータ行を変更する必要があります。
2 フェーズ ロック プロトコルによれば、ステートメントの順序をどのように配置しても、トランザクションがコミットされると、すべての操作に必要な行ロックが解放されます。したがって、例えばステートメント 2 を最後に 3、1、2 の順に配置すると、劇場アカウント残高行のロック時間が最も短くなります。これにより、トランザクション間のロック待機が最小限に抑えられ、同時実行性が向上します。
線形一貫性
シリアル化は、複数のトランザクションの実行順序を調整するスタンドアロン プログラムです。これにより、合理的な順序が見つかり、同時トランザクションの順次実行の結果が同時トランザクションで指定された結果と一致するようになります。
また、線形整合性とは、複数のプログラムの環境であり、異なるプログラム操作の開始時間と終了時間を調整して、これらの操作間に時間が重ならないようにします。
線形整合性には時間調整の要件もあります。つまり、2 つの操作間に時間の重複がない場合、これら 2 つの操作間の時間シーケンスを変更することはできません。同時に、調整結果が正しいかどうかを検証することも必要です。
厳密なシリアル化可能性
スタンドアロンの場合の最も重要な一貫性は直列化可能性であり、分散の場合の最も重要な一貫性は線形化可能性です。次に、この 2 つを組み合わせて分散ケースで最も強い一貫性を実現します。これは厳密なシリアル化可能性 (Strict Serializability) と呼ばれます。
直列化可能とは、2 つのトランザクション内のすべての操作の実行結果が、これら 2 つのトランザクションの特定のシーケンスの実行結果と同等であることを意味します。ここでの「ある」には制限はありません。
厳密なシリアル化により、この「誰か」が規定され、2 つのトランザクションの実行結果が唯一の連続した実行結果と同等であることが要求されます。この結果では、誰のトランザクションが最初に終了しても、順次実行の場合は、最初に終了した人のすべての操作が終了します。
厳密なシリアル化は正確性の保証が強いものの、作業効率が非常に低いため、一般的にはほとんど使用されません。
ビジネスレベルの分散トランザクション - ローカルトランザクションメッセージ
重要なのは、ビジネス データの書き込みとメッセージ データの書き込みを同じローカル トランザクションに配置して両方の成功または失敗を確認し、バックグラウンド スレッドに依存して継続的に再試行して、メッセージ データが別のサービスに送信されて正常に実行されることを確認することです。 。
ビジネス データの書き込みに加えて、サービス A はメッセージ データもテーブルに書き込みます。その後、バックグラウンド スレッドがメッセージ データを継続的に読み取ってサービス B に送信し、サービス B がデータを変更できるようにします。このバックグラウンド スレッドはMySQL マスター/スレーブ/マスター-スレーブとの同期 マスター ノードのダンプスレッドは次のように非常に似ています。
サービスBはトランザクションメッセージを受信すると、トランザクションメッセージの実行結果を含むビジネスデータとメッセージデータの書き込みも同時に実行します。次に、トランザクション メッセージ処理応答を A サービスに送信します。
「2. トランザクション メッセージ」が失われると、サービスは再試行を続けます。
「4. 処理応答」が失われた場合、サービスは再試行を続けます。
サービスBは、2.のトランザクションメッセージを繰り返し受信し、メッセージテーブルが処理済みかどうかを確認し、処理済みであれば処理結果を直接返し、未処理であれば通常通りに処理します（冪等） ）。
ビジネスレベルの分散トランザクション - メッセージキューのトランザクションメッセージ
メッセージがメッセージ キューに配置される点を除けば、ローカル トランザクション メッセージと非常によく似ています。RocketMQ の操作は、Andy のクラスで説明されました。
準備済みメッセージを送信すると、メッセージのアドレスが取得されます。
ローカルトランザクションを実行します。
1 で取得したアドレスを使用してメッセージ ステータスを変更します。
RocketMQ はメッセージ クラスター内のトランザクション メッセージを定期的にスキャンし、準備済みメッセージが見つかった場合はメッセージ送信者に確認し、送信者が設定したポリシーに従ってロールバックするか確認メッセージの送信を続行するかを決定します。
より一般的な原理は次のとおりです。（「メッセージキューマスターコース」第4回講義「トランザクションメッセージを使って分散トランザクションを実現するには？」より引用）
本質は「ローカル トランザクション メッセージ」と同じで、ローカル トランザクションの実行とトランザクション メッセージの送信が成功するか失敗するかを保証します。違いは、「ローカル トランザクション メッセージ」はリトライによって解決され、メッセージ キューは **「read commited」分離レベルに依存して実装されることです (これは原文には書かれていないので私がまとめたものです)。メッセージキューは「読み取りコミット」分離レベルをハーフメッセージ**に保ちます。
ハーフ メッセージは、メッセージのコンテンツが不完全であることを意味するものではなく、メッセージの完全なコンテンツが含まれています。ハーフ メッセージと通常のメッセージの唯一の違いは、トランザクションがコミットされるまではメッセージがコンシューマに表示されないことです。
注文が正常に作成された場合は、トランザクション メッセージを送信すると、ショッピング カート システムはこのメッセージを使用して後続のプロセスを続行できます。
注文の作成が失敗した場合、トランザクション メッセージはロールバックされ、ショッピング カート システムはメッセージを受信しません。
このようにして、「すべて成功するか、両方とも失敗するか」という一貫性要件が基本的に実現されます。
4 番目のステップでトランザクション メッセージのコミットに失敗した場合はどうなりますか?
Kafka のソリューションは比較的単純かつ失礼で、例外を直接スローし、ユーザーが自分で処理できるようにします。送信が成功するまでビジネス コードで繰り返し送信を再試行するか、以前に作成した注文を削除して補正することができます。
RocketMQ のトランザクション実装では、トランザクション メッセージの送信失敗の問題を解決するために、トランザクション リバース チェック メカニズムが追加されています。プロデューサーが注文システムであり、トランザクション メッセージが送信またはロールバックされるときにネットワーク例外が発生し、RocketMQ のブローカーが送信またはロールバックのリクエストを受信しない場合、ブローカーは、対応するローカル トランザクションのステータスを定期的にチェックします。プロデューサー上のトランザクションに送信し、リバースチェックの結果に従って、トランザクションをコミットするかロールバックするかを決定します。
このトランザクション アンチチェック メカニズムをサポートするには、ビジネス コードで、ローカル トランザクションが成功したか失敗したかを RocketMQ に通知するアンチチェック ローカル トランザクション ステータスのインターフェイスを実装する必要があります。RocketMQ は、トランザクション リバース チェックの結果に従って、トランザクション メッセージを自動的にコミットまたはロールバックします。
ビジネスレベルの分散トランザクション - TCC は
主に次の点を記録します。
存在しないトランザクションをキャンセルすることができます (空のロールバックとも呼ばれます)。現時点では、Try メソッドはネットワークの問題によるタイムアウトを受け取っておらず、トランザクション マネージャーはこの時点で Cancel コマンドを発行するため、Try を実行せずに正常にキャンセルできるようにするには、Cancel をサポートする必要があります。
吊り下げ防止。Try メソッドは、ネットワーク輻輳タイムアウトにより、トランザクション マネージャーが Cancel コマンドを発行するようにトリガーしますが、Cancel コマンドの実行後に Try リクエストが到着します。明らかに、この時点では Try コマンドを実行すべきではありません。処刑されるべきでしょうか？次の項目を参照してください。
Cancel の後に Try が続きます。トランザクション マネージャーにとって、この時点でトランザクションは終了しており、Cancel 操作は「中断」されています。したがって、Try の再呼び出しを防ぐために、空のロールバックはシステムに記録を残す必要があります。
TCC にはいくつかの亜種があります。
標準TCC
トライなしのTCC
非同期 TCC
非同期 TCC は、ローカル トランザクション メッセージおよびメッセージ キュー トランザクション メッセージと非常によく似ています。Try の間、メッセージは書き込まれるだけであり、消費することはできません。確認は実際にメッセージを送信する操作であり、キャンセルはメッセージの送信をキャンセルすることです。これは半分です。 -メッセージ。
グローバル冪等性 グローバル
冪等性により、各冪等操作がグローバルに一意であることが保証されます。
デザインキー
グローバルにユニークなID
ステートマシン
インターフェイスの互換性
マイクロサービスの一部のインターフェイスはアップグレードされますが、これらのインターフェイスに依存するマイクロサービスはすべて同時にアップグレードできない場合があります。
解決：
インターフェイスには複数のバージョンがあり、古いインターフェイス コードを直接コピーし、古いインターフェイス コードを変更して、インターフェイス URL に v1/v2 を追加します。
これは組織構造にも関係しており、現在の会社では、コア インターフェイスのアップグレードにより、依存するすべてのシステムが強制的にアップグレードされます。
Andy 氏は、現時点でコードをコピーすることは DRY 原則ではないことを特に強調しました。このため：
既存の機能には影響しません。
古いインターフェースがオフラインの場合はより便利であり、不必要なテストを避けることができます。
インターフェイス ロジックには互換性があり、同じインターフェイス コードは新旧のロジックと互換性があり、相互に影響しやすく、古いインターフェイスがオフラインの場合はコードを変更する必要があります (非推奨)。
インターフェイスの循環呼び出し
たとえば、ビジネスプロセス中に、AがBを呼び出し、Bが再びAを呼び出すと、Aの処理が前の処理ロジックに入り、循環呼び出しが発生し、ビジネス全体が無限ループに陥ります。
解決策: 良い解決策はほとんどありません。運が良ければテストして見つけることができますが、運が悪ければオンラインで見つけることができます。
考えるための質問
職場でコース中に遭遇した落とし穴や技術的な課題を思い出して、その主な理由を考えてみましょう。
残念なことに、同社のマイクロサービスは始まったばかりです...
マイクロサービスインフラストラクチャの選択
マイクロサービスインフラストラクチャとその優先順位
モジュールは全部で 20 あり、分類図は以下のとおりです。緑色のボックスはマイクロサービス フレームワークのコアです。
マイクロサービス フレームワーク (コア) モード
組み込み SDK モード
ダボやスプリングクラウドなど。
リバースプロキシ
APISIXなど。
ネットワークプロキシ（サービスメッシュ）
イスティオなど。
サービス グリッドと Spring Cloud または Dubbo の共通点は、サービスの登録、サービスの検出、およびサービスのルーティングに比較的大きな重複があることがわかります。したがって、それらは一緒に比較されます。
各モードを個別に記録するのではなく、比較表を直接記録します
オープンソースのマイクロサービス フレームワークの選択方法 考えられる
質問
マイクロサービスのインフラストラクチャは ESB よりも複雑であるため、マイクロサービスの必要性は何ですか?
マイクロサービスが開発され、インターネット テクノロジーが従来の業界に浸透したため、SOA に戻って再び取り組むことは不可能です。
マイクロサービス分割スキル スキル
に関わる3つの要素
分割方法
インフラ
ストラクチャ 実装方法
実装提案
上の表から、マイクロサービスの分割は、アーキテクチャの 3 つの原則 (適切性の原則、進化の原則、簡素性の原則) に従っていると同時に、アーキテクチャの複雑さを最初に解決し、これにより、アーキテクチャの品質が向上します。
つまり、マイクロサービスの分割でも、まず正確性を追求し、次に最適化を追求する必要があります。
新しいマイクロサービス（0から業務システムを構築したり、単一のマイクロサービスを変革したりすることを含む）の場合、サービス自体がDDDの指導の下で実行されるビジネスコンセプトであるため、ビジネスに応じて分割する必要があります。 DDDはまさにStart with businessです。（適合性の原則）
マイクロサービスを最適化するなら品質に応じて分割できる（進化原理）
インフラストラクチャは必須です
新しいマイクロサービスを作成する場合、新しいインフラを構築する必要がありますが、インフラにも優先順位があり、優先順位に従って段階的に実装する必要があります（単純原則、進化原則）
マイクロサービスを最適化する場合は、既存のインフラストラクチャを再利用します (適合性の原則)
サービスの実装には2つの方法（適合性の原理、進化の原理）がある
ワンステップで完了
新築の建物を建てる際にはワンステップアプローチが採用されます。
一歩ずつ
特に単一のアーキテクチャを変革する場合は、非コア ビジネス モジュールから始めます。
分割方法の詳細な説明
ビジネスに応じたマイクロサービスの分割
DDD の難しさ
理論的には、DDD 手法を指針として使用する必要があります。
しかし、DDD は次の理由から実装が困難です。
境界付けられたコンテキストの分割の決定は、ビジネス専門家の影響力に依存します。
境界のあるコンテキストは実際には「チームの境界」です
境界付けられたコンテキストは、チームの規模などのチームの条件にも影響されます。
要するに、組織形態の影響が大きいということです。
実際の事業境界分割プロセス
実際の分割プロセスは DDD ではありませんが、次のとおりです。
最初に大まかに分割してから進化させる必要があり、最初に細分化してから統合する必要はないことに注意してください。後者の理由:
まず第一に、ワークロードが非常に大きくなります。マイクロサービス ビジネスを正しく効率的に運営するには、大量のインフラストラクチャが必要になります。
第二に、段階的な分割よりも合併自体が困難です。
実際のビジネスドメインとサービスの対応関係 - サービス分割 DDD の概念には
、下から上、小さいものから大きいものまで、次の概念があります。
エンティティ（充血モデルのエンティティクラス、エンティティは0、1、または複数のデータベース永続オブジェクトに対応し、個別のビジネスを実現する機能）、値オブジェクト（貧血オブジェクトに対応するクラス）
重合。エンティティと値オブジェクトは集合体を構成します。複数のエンティティにわたるビジネス ロジックは、集合体上にあるドメイン サービスを通じて実装されます。
集計はデータの変更と永続化の基本単位です。各集計はデータの永続性を実現するためのウェアハウスに対応します。エンティティと値オブジェクトがデータベース テーブルまたはデータベース テーブルのオブジェクトとして理解される場合、集計はデータベースまたはスキーマです。 。
サービスをルールとデータとして理解すると、アグリゲーションには対応するウェアハウスがあるため、理論的にはアグリゲーションはサービスに対応しますが、マイクロサービスとアグリゲーションは 1 対 1 の形式ではなく、複数の関係が存在します。つまり、マイクロサービス内に複数の集計を含めることができます。したがって、ビジネス ドメインとサービスの間にはいくつかの種類の対応関係があります。実際には、それらはマイクロサービス分割の粒度を記述しており、粒度のサイズは適切性の原則に従う必要があり、チームの現在の状況に適している必要があります。「」を参照してください。三銃士事件」。
1 対 1: 各ビジネス ドメインがマイクロサービスに対応
多対 1: 複数のビジネス ドメインが 1 つのマイクロサービスで処理されます
1 対多: ビジネス プロセスを分割し、コア ビジネス機能の処理フローをリストし、プロセス内の処理ステップを分割の次元として取り上げます。
さらに、集約にはコンテキスト境界もあり、ドメイン モデルは、境界のあるコンテキストを使用してマイクロサービスの設計を上方向に導くことができ、集約ルート、エンティティ、および値オブジェクトの設計は、集約を通じて下方向に導くことができます。
最後に、集計内のデータには強い一貫性があり、集計間のデータには最終的に一貫性があります。
上記の説明は、華蔡氏の写真で要約できます。
三銃士の原則
定義: 平均 3 人の開発者が 1 つのマイクロサービスを担当します。
なぜ一人ではだめなのでしょうか？
人材のバックアップがなく、一人の考えには限界があるからです。
なぜ 2 ではないのでしょうか?
マイクロサービスの保守は 2 人が担当し、マイクロサービスの複雑さは低くなります。個人の専門的な成長には役立たない！
なぜ 4 か 5 ではないのでしょうか?
4つ以上になると、誰もが1つのサービスの詳細をすべて把握できなくなる可能性があります。
マイクロサービスの数 = サーバー側の開発者の数 / 3;
メンテナンス期間中のサービスについては、メンテナンス担当者が 2 名になる場合があります。
三銃士の事件
品質によってマイクロサービスを分割するということ
は、必要に応じてマイクロサービス間で集約を移行およびマージすることを意味します。
性能に応じて分割
トラフィックの多い業務と相関性の強い業務を分割することで、業務相互の影響度を低減し、分割後のトラフィックの多い業務を最適化し、パフォーマンスの向上とコストの削減を実現します。
業務の重要度に応じた分割
重要度の高い業務（重要度が高い＝トラフィックが多いとは限りません）を分離することで、業務の相互影響を軽減し、分割後の重要度の高い業務の可用性を向上させます。
空き状況に応じて分割する
問題が多い業務を分割して業務の相互作用を軽減し、分割後は問題が多い業務を重点的に改善します。
安定性に応じた分割
安定した事業を分割することで、事業間の相互影響度を低減し、分割後は変化する事業を迅速に繰り返すことができます。
質問について考える
品質属性に従ってマイクロサービスを分割するとき、三銃士の原則に従う必要がありますか?
それはまだ従う必要があります。なぜなら、現時点での分割対象は依然として様々なビジネスサービスであり、ビジネスサービスの構築は三銃士に従う必要があるからである。
ミドル プラットフォームの詳細な分析と実装スキルミドル プラットフォームの登場は、ビジネスの複雑さに対処するためです。
共有アーキテクチャの開発プロセス
「煙突がたくさんある」という共有アーキテクチャはなく、繰り返し開発される。
共有リソース - Iaas アーキテクチャ。
共有ランタイム、ミドルウェア、DBなど
SaaS では、アプリケーション全体が共有されます。
ミドルエンド構造。IaaS、PaaS、SaaSとは異なり、各事業で同じビジネスとデータを共有します。
中台の概念を理解する
華蔡氏は、中台にはビジネス中台とデータ中台の 2 種類があると指摘しました。
ビジネスミドル
プラットフォーム ビジネスミドルプラットフォームは、企業内の複数の類似ビジネスの一般的なビジネス機能をプラットフォーム上にデポジットすることで、冗長な構築を削減し、ビジネス開発の効率を向上させるアーキテクチャ モデルです。3 つの重要なポイント:
仕事関連。これにより、ミドルオフィスと IaaS、PaaS と SaaS が区別されます。
複数のビジネスにわたって。
複数のビジネスが似ています。したがって、あまりにも異なるビジネスをミドルオフィスに押し込むことはできません。
データ センター
データ センターは、企業のすべてのビジネス データを同じプラットフォーム上に配置し、企業間のデータ接続とデータの再利用をサポートし、企業の業務効率を向上させるアーキテクチャ モデルです。重要なポイントは以下の3つです
すべてのビジネス。データセンターはあらゆるビジネスをサポートする必要があります。
データはつながっています。企業間のデータを接続する必要があります。
データの再利用。異なるビジネス間でデータを再利用して、全体的な業務効率を向上させることができます。3 つの中で最も難しいのは、データが異なるビジネスに分散しているため、その差が比較的大きく、ビジネス間での再利用が難しいことです。
ミドルプラットフォームの価値
ビジネスミドルプラットフォーム。その価値は、類似の企業が相互に活用し、機能を共有できることであり、それによって多数の開発の繰り返しを回避し、開発効率を向上させることができます。したがって、ビジネスの類似性が高いほど、そのビジネスにおける台湾の価値は高くなります。華蔡氏は、類似性が60％を超える複数の企業が共同でミドルオフィスを建設することを提案した。
データセンター。その価値は、データの接続と再利用、データの孤立の回避、運用効率の向上にあります。
データセンターを使用する企業が増えれば増えるほど、データセンターの価値は高まります。
データセンターの価値は、統合データ プラットフォーム、クロスビジネス データ接続、クロスビジネス データ再利用 (マイニング) に反映されます。
しかし、企業全体でデータを再利用することは困難です。データ分析は法則性を発見・抽出する作業であり、企業間での差異は大きく、データ再利用の目標をどう設定するか自体が難しい。たとえば、2 つの事業部門が異なるビジネス言語と思考モードを持っている場合、データの相関関係をどのように抽出するか? コミュニケーションは大きな問題です。
ミドルプラットフォームがもたらす問題
中小企業はミドルステージの太ももを抱き、ミドルステージは大企業の太ももを抱きしめる ミドルステージの構築は最終的には組織構造の問題であり、この点ではダメだどう対処するか 最終的には中盤の構築が問題になる 組織構造の問題（コンウェイの法則）
中国と台湾の境界は明確にするのが難しい。それは、どの事業をミドルオフィスが実施するのか、どの事業をミドルオフィスが自ら実施するのかということであり、その境界は明確ではない。ミドルオフィス設計で最も難しいのはドメイン分割ではなく、ミドルオフィスとビジネスの境界分割です。中国と台湾は「複合イノベーション」には適しているが、「破壊的イノベーション」には適していない。パイプラインを使用してさまざまなビジネス プロセスをカプセル化することで、この問題をある程度軽減できます。
ミドルオフィスのプロセス全体の効率は高くありません。本質的な理由は、組織構造上、業務が複数の部門に対応しており、部門を越えたコミュニケーションのコストが比較的大きいことが想像できるからです。
境界はビジネス機能ごとに議論されます。
各ビジネス機能は、すべてのビジネスへの影響を考慮する必要があります。
パイプラインを使用してさまざまなビジネス プロセスをカプセル化することで、この問題をある程度軽減できます。
ミドルエンドのランディング スキル
マイクロサービスを使用してミドルエンドを構築します。ことわざにあるように、「マイクロサービスは必ずしも Zhongtai である必要はありません。Zhongtai はマイクロサービスでなければなりません!」。
Pipeline を使用してさまざまなビジネス プロセスをカプセル化し、ミドル オフィスとビジネス間の境界分割が難しく、プロセス全体の効率が低いという問題を軽減します。
Netty に似たパイプラインは、ハンドラーを使用して、さまざまな処理フロー内のさまざまな関数ポイントをカプセル化します。デザインパターンにおける責任連鎖パターンに相当し、オブジェクト指向における構成に相当します。
さまざまなサービスが SPI でカプセル化されます。デザインパターンにおけるテンプレートパターンに相当し、オブジェクト指向における継承に相当します。
パイプライン ソリューションと SPI ソリューションの比較
デザイン パターンでは継承よりも合成が優先されるという見解によれば、最初に Pipiline を使用する必要があるようです。実際、華蔡氏もそれを最初に使用すべきであると述べました
Pipilineは開発難易度が低いことが主な理由ですが、SPIはミドルプラットフォームとビジネスの境界を明確にする必要があり、開発難易度が高いです
考えられる質問
会社がすでにオンラインで運営しているビジネスを行っており、今後同様のビジネスを行う予定である場合、現時点ではミドル オフィスに行く必要がありますか?
状況によりますと、類似事業が多いほど価値が高くなるため、現時点では類似事業は 2 社しかありませんが、適合性の原則に従えば、そのような事例が多くなければ、する必要はありません。中間プラットフォームに移行する; ビジネス開発が非常に速い場合は、最初に粗粒化してから分割するという原則に従って、単純な中間プラットフォームを作成することを検討できます。
実践的な戦闘 - モバイル ゲーム電子商取引プラットフォーム用のマイクロサービス
既存のアーキテクチャがモノリシックである場合、マイクロサービスの変換は既存のアーキテクチャの問題を解決するための最良かつ自然な解決策であるとは限らず、特定の問題を詳細に分析する必要があります。
考える質問
ビジネスにおける抽象度の高いビジネスモデルの長所と短所は何ですか?
メリット：再利用可能。デザインに対する要求は比較的高く、デザインが良くないと再利用性も良くありません。
短所: 特定のビジネスに直接使用できない、さらなる開発が必要、通信コストが比較的高い。