Zhuanzhuan Sun Xuan: マイクロサービスアーキテクチャで中古品取引プラットフォームを構築する方法

中国電子技術標準化研究所が主催し、51CTOが主催する「第7回中国クラウドコンピューティング標準および応用会議」が、2018年1月4日から1月5日まで北京で成功裏に開催されました。この会議では、中国の国家クラウドコンピューティング標準開発作業の成果を包括的に紹介し、国内のクラウドコンピューティング産業政策を解釈し、クラウドコンピューティング標準化作業の重要な進捗状況を報告しました。同時に、この会議では、国家オープンソース分野における主要な標準化製品も発表され、クラウドコンピューティングの最新の技術動向とアプリケーション革新の成果が共有され、クラウドコンピューティング製品とソリューションの第5回評価証明書が発行されました。さらに、第2回中国優秀クラウドコンピューティングオープンソース事例選定の結果も会議で発表されました。

[[216347]]

同カンファレンスのクラウドコンピューティング基盤と実践フォーラムでは、Zhuanzhuan社のアーキテクチャアルゴリズム部門責任者である孫玄氏が「マイクロサービスアーキテクチャに基づく中古取引プラットフォームの構築方法」と題する基調講演を行った。まず、マイクロアーキテクチャ サービスとは何かという話から始め、垂直分野、ビジネス モデル、分散トランザクション ソリューションの導入という 3 つの側面から、優れたマイクロアーキテクチャ サービスを提供する方法を皆さんと共有しました。このフォーラムの最後の講演者として、遅い時間であったにもかかわらず、彼の素晴らしい内容の共有は、すべての聴衆を魅了し、立ち止まって耳を傾けさせました。

以下はスピーチの記録です。

皆さんこんにちは！

現時点で、皆さんがまだここに座って私の話を聞いているというのは、簡単なことではありません。実は、劉哲さんが今言ったことはとても素晴らしかったです。彼は、今回の会議では技術的な事柄については話すべきではないと述べた。たまたま今日用意したものは２つの部分に分かれています。一部は自慢するためのものですが、残りは乾物です。乾物の部分については、劉哲氏は、よりマクロなことについて話す必要があるので、技術的なことについてはできるだけ話さないほうがよいと述べました。

今日は、マイクロサービス アーキテクチャ全体に基づいて、中古品取引プラットフォーム全体のクラウド インフラストラクチャを構築する方法についてお話しします。

まず最初に、自己紹介をさせてください。私は58で長年働いています。 58は急速に成長し、私は58グループ全体のトップアーキテクトになりました。その後、私は全員を率いて技術的に難しいタスクをいくつか実行しました。当時私がなぜ 58 に参加したのかを知るのは実は非常に興味深いことです。私は2011年にBaiduで働いていましたが、その後Baiduを辞めたいと思いました。どこに行けばいいですか？実は知りませんでした。ヘッドハンターは私に「58に行きたいですか？」と尋ねました。はい、と言いましたが、58 が何なのか分かりませんでした。私が知っていた唯一のことは、ヤン・ミーが毎日バスや地下鉄の中で58.comを魔法のウェブサイトとして話していたということだった。魔法のようだったので、ここに来て何年も滞在しました。 58 歳の時の私の経験は比較的単純なものでした。基本的には、eコマースに似たチャットツールの開発から始め、その後、Zhuan Zhuan 製品に取り組みました。

私は現在、Baidu で Baidu Space に取り組んでいます。この商品をご存知ですか？わからない。それを知っている人は、若さをさらけ出しています。私はそれ以前に浙江大学で勉強し、多くの経験を積んでいたので、会社を代表して多くのプレゼンテーションを行いました。基本的にはAI全般も含め、顔が見える業界のカンファレンスにはすべて出席してきましたし、実はアーキテクチャに関するカンファレンスにも数多く出席してきました。最近なぜAIなのか？実は、私は個人的な経験としてアーキテクチャについてお話ししてきましたが、実は電子商取引においてより重要なのはアルゴリズムなのです。たとえば、機械学習を通じて、推奨と検索全体で一定量の注文を生成することができます。今は私がこの部分を担当しているので、個人的にはアルゴリズムに重点を置いています。興味のある学生は私と連絡を取ることができます。これも私の個人的な紹介です。

マイクロサービス アーキテクチャについて話すとき、まずマイクロサービス アーキテクチャとは何か、そしてマイクロサービス アーキテクチャの下で中古品取引プラットフォームを中心にどのようなインフラストラクチャが構築されるのかについてお話ししましょう。ここで、典型的なケースを 2 つ選んでお話しします。例えば、中古取引プラットフォームの下で分散システム全体をどのように設計し、取引全体をどのように行うのでしょうか?それについて話す前に、まずこのことについて話しましょう。皆さんこれ見たことありますか？これは実は私たちのロゴの 1 つです。私たちは中古品ビジネスを営んでいるため、「買う買う買う」から「売る売る売る」までの問題を解決しなければなりません。もともと友人の輪の中で文章を見て、とても興味深いと思いました。実際、それは買う、買う、買う、売る、売る、売るという問題も解決します。もちろんシェアリングエコノミー時代の循環でもあります。使わなくなったものを中古品プラットフォームで売って、少なくともお金を稼いで、少なくともお金を嫌わないようにすることをお勧めします。

垂直分野に応じてマイクロサービスアーキテクチャを開発する

マイクロサービスについて話すとき、マイクロサービス時代全体でこのアーキテクチャを提案した人物がいたことを言及する必要があります。そのアーキテクチャは Martin Fowler によって提案されました。マイクロサービス アーキテクチャのアイデアは古くから存在していましたが、実際に提案されたのは 2014 年になってからでした。アーキテクチャ モデルであるため、何らかの仕様やアーキテクチャ設計コンセプトに従う必要があります。ご覧のとおり、まず第一に、マイクロサービスはいくつかの小さなサービスの組み合わせです。小規模サービスの組み合わせとは何ですか?かつての会議で、ある先生がマイクロサービスを定量的に実現できると言っていました。私は彼にどうやってそれをやったのか尋ねました。彼らの上司は、私たちはコードの行数に従って作業しており、1,000 行がマイクロサービスとして定義されていると言いました。彼はそれが可能かどうか私に尋ねました。コードが 1001 行あったらどうしますか?彼は、この問題にはまだ遭遇していないようだと答えました。

マイクロサービスを実現したいと考えています。ドメイン駆動設計について聞いたことがあるはずです。これは大きな理論ですが、実際にどのように実行するのでしょうか?事業全体の縦の領域に合わせて参画できます。中古品の取引も行っております。当社にはユーザーシステムと製品システムがあります。取引システム、検索システム、トレーディングシステムがあります。縦に分割します。ユーザーは 1 つの部分であり、製品は 1 つの部分であり、推奨事項は 1 つの部分です。分割後、各部分はマイクロサービスになります。このまま分割しても大丈夫でしょうか？もちろん違います。検索を分割した後、すべてのロジックとデータ アクセスが一緒になる場合、モジュールの機能は必然的に非常に肥大化します。水平に分割する必要があります。これをゲートウェイ、ビジネス ロジック レイヤー、および DB に分割できます。私たちが業界でやっていることは、垂直分割と水平分割に他なりません。この部分を実行するのは比較的簡単です。

結局、分解してみると、実は同じでした。たとえば、上部は IOS や Android などのクライアント全体であり、下部はゲートウェイ全体です。ゲートウェイの下にはビジネス ロジック層があり、その下にはデータ アクセスがあり、その下には TB がこれを実行します。縦割りと横割りをしました。私の意見では、アーキテクチャ モデル全体の観点から見ると、マイクロサービス アーキテクチャは垂直分割と水平分割を組み合わせたものに過ぎません。もちろん、最も難しいのは水平分割ではなく垂直分割なので、これは比較的簡単です。マイクロサービス全体のビジネス アーキテクチャは、ビジネス ドメイン モデルに従って分割する必要があります。分割後、水平分割を行うことができます。これは実は非常に簡単です。

一方、当社の中古品取引プラットフォーム全体は、実際には電子商取引プラットフォームです。これは電子商取引プラットフォームなので、電子商取引プラットフォームに必要なすべての機能が備わっており、実際には非常に多くのモジュールがあります。以下からわかるように、運用・保守サポートには、当社の出版システムと情報プラットフォーム全体が含まれます。これは運用と保守のレベルです。運用と保守レベルの上には、短縮ドメイン名、ユーザー、売り手、買い手の間の通信のための通信全体、プッシュ サービスなど、当社の基本サービスがあります。技術コンポーネントやデータベース ミドルウェアもあり、これらは自分で構築する必要があります。もちろん、上記のプラットフォームの中には、主にサービス全体向けに設計されたものもあります。たとえば、監視、サービス、ログ追跡がすべて実行されます。もちろん、スケジュールの安定性を確保するためにスケジュールに従って実行されるオフライン タスクもあります。もちろん、主に 3 つの部分で構成される独自のストレージ レイヤーもあります。上の部分はみんなが言ったことです。マイクロサービスを実行する場合は、RPC の実行方法を含め、マイクロサービス フレームワークの問題を解決する必要があります。ゲートウェイをどうやって作るのですか?幸いなことに、私たちは業界のオープンソースのものを使用しておらず、独自の RPC を構築しました。基本的に、業界で知られているdobleとPRCは似ているので、私たちもそれを自分たちでやっていますし、もっといろいろなことを行っています。さらに重要なものを 1 つか 2 つ選んで、皆さんにお話ししたいと思います。

ビジネスモデルに基づいてマイクロサービスフレームワークを構築する

実際、ロックを使用できるシナリオは数多くあります。例えば、取引全体において、中古取引プラットフォームと新品の違いは何でしょうか?新品には在庫という概念がありますが、中古取引プラットフォームには在庫という概念がありません。理論上、すべての商品は 1 つしかありません。したがって、この場合、2 人のユーザーが同時に同じ商品を注文すると、グローバルに一意の制限を設けないと、注文が重複して過剰販売が発生する可能性があります。この場合、リソースの一意性を保証するためにロックを使用する必要があります。一方、消費に関しては、メッセージを生成して MQ に投入したいと考えています。メッセージを送信する場合、その機密性を保証する方法はありません。あなたの機密性は消費者側によって保証されます。どうすれば、メッセージをある人だけが受け取り、別の人が受け取らないようにできるでしょうか?消費の機密性の問題を解決するために、この時点でいくつかのロックも使用されます。

この状況は、リソースが分散環境で一意に書き込まれるという問題を簡単に解決します。これは実は非常に簡単で、解決策があると思います。皆さんご存知のとおり、readis Setnx Timeout を使用するだけです。しかし、これには何が問題なのでしょうか?理論的には、ロックが Redis に配置されると期間が設定され、このロックの期間を制御することはできません。私たちの目標は、強力な一貫性から始めて、これらの問題を解決することです。もう 1 つのポイントは、ロックにピリオドがあることを願うということです。最初は 5 ミリ秒を適用しましたが、5 ミリ秒では足りないことがわかったので、さらに 5 ミリ秒延長しました。しかし、Redis の時代ではこれは不可能です。あなたはロックとして機能し、ビジネス パーティはあなたに接続して要件を作成します。ビジネス関係者があなたとつながるための手順が非常に簡単であることを願っています。技術サービスを行ったことがある場合、ビジネス パーティにコードをもう 1 行記述するように依頼しても、ビジネス パーティはそれを実行できないと言うでしょう。これは非常に面倒なことなので、これをやらなければなりません。視覚的な管理の背景と監視は必須です。

どうやってやるんですか？とても簡単です。当社では業界で十分に検証されたETCDを使用しています。これはシンプルな KV であり、可用性が高く、データ自体が永続性をサポートしているため、ETCD を使用して保存されます。どうやってやるんですか？ ETCD 自体は、可用性の高い分散クラスターです。クライアント上に分散クライアントを構築したいと考えています。もちろん、1 つのロックが複数のモジュールで公平に競争できることを望んでいます。これが私たちの出発点です。

このロックを取得するには 2 つのモードがあります。 1 つのモードはクライアント TTL であり、もう 1 つはサーバー TTL です。サーバー TTL は、ロックの有効期限が切れると、リースの更新に役立つことを意味します。 1 つのクライアントはリースの更新を手伝ってくれますが、もう 1 つは、ETCD 自体がリースを更新してくれることを期待しています。このモードは比較的シンプルです。

クライアントモードは比較的シンプルです。たとえば、クライアント A とクライアント B という 2 人のユーザーがいる場合、ロックを取得するのは非常に簡単です。 ETCD のインターフェースを直接要求するだけです。もちろん、キー、TTL、ロックの一意の識別子でもある UID など、書き込みたいいくつかの情報を渡す必要があります。

もちろん、この時点では実際にロックを取得できるのは 1 人のユーザーだけです。 A がロックを取得した場合、B は確実にロックを取得できなくなります。この時点で、A がリースの有効期限が切れた後にリースを更新したい場合、クライアント モードにはリースの更新を支援するスレッドがあります。クライアント モードでは、クライアントがリースの更新を支援する必要があります。

もう 1 つは、サーバー モデルが非常にシンプルであることです。鍵を取得するのは同じですが、誰がリースを更新するのでしょうか?もちろん、サーバーがそれを実行してくれることを願っています。実際に何を使うのでしょうか?プロセス数が少なく、プロセスが安定しているほど、クライアント アクセスも安定するため、サーバー側モデルを使用する必要があります。

ビジネスへのアクセスは比較的簡単です。 JDK7 以降の場合は、Try コードを使用します。 JDK7 より前のバージョンの場合は、ロックを取得した後、リリース インターフェイスを使用してこれを実行する必要があります。 2人同時に申し込んでも大丈夫です。 ***掃除。 JDK7以上をご利用の場合はリリース後すぐにリリースさせていただきます。これは比較的単純なので、説明に多くの労力を費やす必要はありません。

分散トランザクションソリューションの導入

さらに、取引の問題についてお話ししたいと思います。先ほど、マイクロサービス アーキテクチャでは、モジュールが実際には多数のモジュールに分割されていると述べました。多くのモジュールに分割した後、リクエストが来ると、さらに多くのモジュールを設計することになり、これらのモジュールは複数のモジュールに同時に変更を加えることになります。現時点では、複数のモジュールのデータが成功か失敗かをどのように確認できるでしょうか?実際には、分散環境全体やマイクロサービス アーキテクチャに適したモジュールが多数あります。この時点で、いくつかの分散トランザクション ソリューションを導入する必要があるかもしれません。

分散トランザクションソリューションを解決する良い方法はありますか?理論上、分散トランザクションは長いトランザクションです。長いトランザクションを解決するには、基本的に長いトランザクションを短いトランザクションに変換する必要があります。ショート トランザクションは、実際にはローカル トランザクションです。このようにして、問題が発生した場合、分散トランザクションによって調整の問題を解決できます。補償など、分散トランザクションを解決する方法は多数あります。もちろん、非同期環境では MQ を介して実行することもできます。非同期環境では、MQ を介して分散ロック全体を実装し、分散トランザクションを使用してこれを実行するにはどうすればよいですか?私たちの最終的な目標は、データの一貫性を確保することです。

どうやってやるんですか？とても簡単です。 MQ は実際に TCC と同様の分散機能を提供できます。これは、MQ トランザクション メッセージを通じてデータの最終的な一貫性の問題を解決したいと考えているためです。ビジネスシナリオとは何ですか?いくつかの非同期シナリオでこれを使用すると言いました。現在、トランザクション環境で支払いの注文を行っています。注文が正常に行われた後、メッセージが生成され、MQ に配置されることを期待します。このとき、支払いリンクは MQ 内のメッセージを読み取り、非同期的に処理します。このリンクは非同期シナリオです。重要なのは、注文が確実に成功するようにするにはどうすればよいかということです。注文を正常に行い、注文後のメッセージを MQ に入力できれば、企業は成功できます。通常のMQを使用する場合、注文前にMQにメッセージを入れることは可能ですか？可能ですが、メッセージを MQ に入れた後に注文が実際に失敗する可能性があります。この時点では、あなたが入れたメッセージは無意味です。最初に注文を出し、注文が正常に行われた後にメッセージを MQ に入れるという選択もできますが、メッセージを MQ に入れて再度失敗する可能性もあります。これは 2 段階の操作であるため、一貫性を保証する方法がありません。これは頭​​痛の種だ。非同期環境での私の注文とメッセージ生成は、MQ に配置すると失敗する可能性がありますが、失敗した後、ビジネス パーティが再度確認する口実を提供して、再度確認し、成功したかどうかを教えていただければ幸いです。成功したらまたこれをやります。

アイデアは非常にシンプルです。私たちのビジネス パーティが、セミメッセージとメッセージ取得と呼ばれる 2 つの状態を含むローカル操作取得インターフェイスを提供できることを期待しています。この図はフロー図です。 MQ 送信者は MQ クライアントであり、ローカル トランザクションが注文を発行します。どうすればいいでしょうか?最初のステップとして注文する前に何をすればよいでしょうか?まず、MQ サービス トランザクション エンドにセミメッセージを送信します。このとき、MQ の下流には送信されません。 MQ は成功メッセージを受信すると、セミメッセージが MQ に送信されたことを認識します。ビジネスパーティーでは何ができるでしょうか? 3 番目のステップでは、注文を行うローカル トランザクションを実行できます。注文のローカルトランザクションが正常に実行されると。

4 番目のステップでは、成功した場合、ローカル トランザクション全体が実行されたことを MQ に通知する別のメッセージを送信します。この時点で、私はあなたの消費者にメッセージを届けることができます。すべてがうまくいけば、MQ は送信者にメッセージを受信したことを伝え、それで完了です。メッセージを送信した際に、ネットワークの異常により、送信者が実際にメッセージを受信しなかった可能性があります。これは非常に簡単です。 5番目のステップを見てみましょう。現時点で MQ に送信したメッセージを私の MQ 送信者が受信しない場合は、非常に簡単です。送信者はローカルトランザクションをチェックして、操作が成功したかどうかを確認します。ローカルトランザクションをチェックして、私が実際に注文を行ったことがわかったとします。こんな時どうしますか？当然のことながら、第 7 ステップでは、トランザクションに応じてリバックします。この方法により、メッセージが最終的に正常に消費されることを常に保証できます。野生の鳩の解決策は理論的には問題ありません。その利点はより一般的です。欠点は、ビジネス側がコールバック インターフェイスを提供する必要があることです。ローカル トランザクションを実行するたびに、クエリのためにローカル トランザクションのコールバック インターフェイスを MQ 送信者に提供する必要があります。これはビジネス側にとってもコストがかかります。もちろん、そのプロセスを説明する必要はありません。

4 番目のステップは、ローカル操作を実行することです。 OKが出たら送信します。この時点で、送信者は実際にブロークを送信またはロールバックする必要があります。最大の問題は服従ではない。問題は、そのような取引を行うたびに、私の取引先がバックチェック インターフェイスを提供しなければならないのに、多くの場合、あなたの取引先はそれを望んでいないことです。この計画自体には何も問題はありません。再設計において一貫性を実現できるソリューションはありますか?可能です。私たちは何を期待しているのでしょうか?前述のように、注文を出して MQ メッセージを生成するという 2 段階の操作を実行できることを期待しています。ローカル注文を行ってメッセージを生成する場合、それを直接 MQ に入力することはありません。ローカル トランザクションを通じて、注文操作とメッセージ生成操作を 1 つにまとめることはできますか?これらを 1 つにまとめることができれば、注文と注文の配置、注文とメッセージの生成は成功するか失敗するかのいずれかになります。この時点では、ローカル メッセージ テーブルからメッセージを読み取り、それを MQ に渡すだけです。こうなると、ビジネス側は実際に検索インターフェースを提供する必要がなくなり、より便利になります。

とても簡単です。一緒にやってみませんか？ユーザーがローカル操作トランザクション テーブルを実行している間に、ローカル メッセージ テーブルを配置し、ローカル トランザクションを開始してこれを実行できることを期待します。これがプロセスです。このプロセスはマイクロサービスのクライアントであり、これはマイクロサービスのデータベースです。

前のステップと何が違うのでしょうか?最初のステップは、ビジネスデータとサービスデータを書き込むことです。 3 番目のステップは、トランザクション操作を実行できるものをここに配置することです。たとえば、3 番目のステップが成功または失敗した場合、成功した場合はどうすればよいですか?トランザクション テーブルからローカル トランザクションを読み取り、それを MQ に格納します。したがって、3 番目のステップでは、それを読み取った後、マイクロサービスはこのプロトコルを再度 MQ に書き込むことができます。同時に、MQ はそれをマイクロサービスとクライアントに提供し、これを実行できます。これには、MQ クライアントがさらに多くの処理を実行し、送信したローカル メッセージ テーブルからそれを読み取り、それをローカルに配置することが必要になります。これがその方法です。

時間の制約があるため、最終的にこの方法を選択しました。他のことについては詳しく説明できません。ご興味がございましたらご連絡させていただきます。これが今日私がお話しする内容です。さらに、これを行うには、ローカル トランザクション メッセージ テーブルを使用します。

これで今日のシェアは終了です。私は主に、マイクロサービス アーキテクチャ設計全体とクラウド トランザクション全体の概念を全員に学習させました。 2 つの例と、ロックとトランザクション全体の実行方法を示しました。