【WOT2018】Shen Jian: 58 Expressアーキテクチャの分離とマイクロサービスの実践

[51CTO.comより引用] 2018年5月18日〜19日、51CTO主催のグローバルソフトウェアおよび運用技術サミットが北京で開催されました。このサミットでは、人工知能、ビッグデータ、モノのインターネット、ブロックチェーンなど12の核心的なホットトピックに焦点を当て、国内外から60人の第一線の専門家が集まります。これはハイエンドのテクノロジーの饗宴であり、トップクラスの IT 技術者が学び、ネットワークを拡大するための見逃せないプラットフォームです。

「マイクロサービス アーキテクチャ設計」セッションでは、58 Daojia CTO の Shen Jian が「58 Express マイクロサービス アーキテクチャ分離のベスト プラクティス」について基調講演を行いました。会議後、51CTOの記者がWOT2018グローバルソフトウェアおよび運用技術サミットでの沈建氏の講演内容をまとめました。

【講師プロフィール】

58 Shen Jian、インターネットアーキテクチャ技術の専門家であり、公開アカウント「The Road to Architect」の著者。彼は、Baidu のシニア エンジニア、58.com のシニア アーキテクト、58.com 技術委員会の委員長を務めてきました。 2015年に58daojiaのシニアディレクター兼技術委員会委員長に異動し、インフラ、技術プラットフォーム、運用保守セキュリティ、情報システムなどのバックエンド技術システムの構築を担当。 2017年に58 ExpressにCTOとして異動し、58 Expressの技術システムの構築を担当。

ビジネス開発にはマイクロサービスアーキテクチャが必要

58 Express アーキテクチャは、次の図に示すように、3 層構造と 3 つのビジネスで構成されています。このうち、PC/H***PPなどのエンドポイント、Webサイトアプリケーション、データストレージの3層構造となっています。 3つの事業セグメントは、to C、to 2 small B、to large Bです。

58 エクスプレスアーキテクチャ

アーキテクチャが生まれ、結合が続きました。カップリングとは、もともと無関係だったコード、モジュール、サービス、システムが何らかの理由でリンクされているアーキテクチャの状態です。彼らの独立性は低く、お互いに影響を与え、お互いを変化させます。業務は少しずつ開発されますが、コードは行ごとに書かれていないため、重複したコードの結合が発生します。ビジネスが成長するにつれて、データの量が増加し、複雑さの広がりの結合により、強制的なリンクのアップグレードが必要になります。さらに、データベース結合、サービス結合などがあります。これらを排除するにはどうすればよいでしょうか?マイクロサービスは潜在的な解決策です。

マイクロサービスアーキテクチャの詳細な説明

サービス指向開発以前は、インターネットの高可用性アーキテクチャはおおよそ次のとおりでした。

（１）ユーザー側はブラウザまたはAPPクライアントです。

（２）バックエンドエントリは、リバースプロキシとして使用される高可用性のnginxクラスタです。

（３）ミドルコアは高可用性ウェブサーバークラスターであり、R＆Dエンジニアが主にコーディング作業を行う場所です。

（4）バックエンドストレージは高可用性データベースクラスターであり、データはこの層に保存されます。

より一般的には、Web サーバー層は DAO/ORM などのテクノロジーを通じてデータベースにアクセスします。

このことから、元のアーキテクチャにはサービス層がなく、この時点で次のような問題点が発生することがわかります。コードがあらゆる場所にコピーされます。複雑さが広がる;ライブラリの再利用と結合。 SQL の品質は保証できず、ビジネスは相互に影響を及ぼします。クレイジーな DB カップリングなど

上記の問題を解決するために、インターネットの高可用性階層化アーキテクチャの進化の過程で「サービス層」が導入されました。

サービス レイヤーを導入する主な利点としては、呼び出しが容易になることなどが挙げられます。コードのコピーを防ぐ高い再利用性。根本的な複雑さを隠すことに重点を置く。 SQL 品質の保証。便利なデータベース分離。制限されたインターフェースを提供し、最高のパフォーマンスを実現するなど。

どのくらい小さいのが適切でしょうか?

データ量、トラフィック、ビジネスの複雑さが増す中、マイクロサービス アーキテクチャはアーキテクチャを進化させる唯一の方法です。では、マイクロサービス アーキテクチャはどの程度「マイクロ」であるべきでしょうか?

[粗粒度: 1 つのサービス層]

最も大まかな方法​​では、すべての基本データはサービスを通じてアクセスされます。ビジネスが特に複雑でない場合は、これで問題ありません。ビジネスが複雑になると、サービス層が非常に重くなり、結合ポイントの 1 つになります。 WeChat のシナリオを例にとると、基本データにアクセスするための一般的なサービス レイヤーがあると仮定すると、このサービス レイヤーは次のようになります。

ユーザー情報、友人情報、グループ情報、メッセージ情報がすべて通過する統合サービス層があります。

詳細: WeChat の 1 対 1 メッセージングは​​、読み取りよりも書き込みが中心であるため、キャッシュはありません。

【サブ事業ごとに1つのサービス】

すべての情報が 1 つのサービスに保存されている場合、1 か所のバグがビジネス全体に影響を及ぼします。したがって、より合理的なアプローチは、サービス層をセグメント化することです。アーキテクチャをセグメント化するにはどうすればよいでしょうか?垂直セグメンテーションは良い解決策です。サブビジネスを一つずつ分離します。すると、WeChat のサービス指向アーキテクチャは次のようになるかもしれません。

（１）ユーザー関連サブサービスには、ユーザーサービスが含まれる。

（２）フレンド関連サブサービスにはフレンドサービスが含まれる

（３）グループ関連サブサービスには、グループサービスが含まれる。

（4）メッセージ関連のサブサービスにはmsg-serviceが含まれる

こうすることで、1 つのサービスに問題があっても他のサービスに影響が及ばなくなり、データ層も業務に応じて垂直に分割されます。

サービスの粒度が細かくなるにつれて、ビジネスとサービス間の接続がより複雑になるという新たな問題が発生します。良い最適化ソリューションはありますか?

一般的に、高可用性サービス分散層クラスターを追加し、プロトコル設計中にサービス番号を追加すると、スパイダーウェブの依存関係を軽減できます。

（１）発信者は配信層を頼りにサービス番号を渡す

（２）配布層はサービス層に依存し、サービス番号パラメータを通じて配布される。

[1つのデータベースは1つのサービスに対応します]

データ アクセス サービスは、もともと DAO/ORM のデータ アクセスのニーズから派生したものであるため、1 つのデータ テーブルに 1 つのサービスというアプローチを採用している企業もあります。

1 つのサービスに対応する 1 つのサブビジネスのゲームプレイは次のとおりです。

（１）サービス層：グループ事業全体がサービスである

（２）ストレージ層。実際にはグループ情報、グループメンバー、グループメッセージなどの複数のデータテーブルに対応する場合がある。

1 つのデータ テーブルと 1 つのサービスに分割すると、アーキテクチャは次のようになります。

グループ情報テーブル、グループ メンバー テーブル、グループ メッセージ テーブルなどのさまざまなデータ テーブルも分離されており、相互に影響を与えません。

[1つのインターフェースは1つのサービスに対応します]

より極端なマイクロサービス アーキテクチャでは、1 つのインターフェースが 1 つのマイクロサービスに対応します。この場合、アーキテクチャは次のように変わります。

進化したもの:

（１）グループ情報サービスの変更

（２）グループ情報サービスの追加

（３）団体情報サービスの取得

複数のサービスが同じデータ テーブルを操作し、同じキャッシュを使用します。いずれかのインターフェースで問題が発生しても、他のインターフェースには影響しません。

粒子サイズの長所と短所

上で述べたサービタイゼーションとマイクロサービスのさまざまな粒度の利点と欠点は何ですか?

一般的に、細分化された分割の利点は次のとおりです。

（１）サービスは独立して展開できる

（２）容量の拡大・縮小が容易であり、資源利用率の向上に寄与する。

（３）サイズが小さくなると、カップリングも小さくなります。

（４）内訳が詳細であればあるほど、耐障害性は向上する。 1 つのサービスに問題が発生しても、他のサービスには影響しません。

（５）スケーラビリティの向上

（６）…

細分化された分割の欠点も明らかです。

（１）内訳が詳細になるほど、システムは複雑になる

（２）システム間の依存関係もより複雑になっている

（３）O&Mの複雑化

（4）監視はより複雑になる

（５）問題が起きたときにその原因を特定するのが困難になる

（６）…

一般的に、サービス指向とマイクロサービスの粒度に関する Shen Jian 教授の見解は、マイクロサービスの単位として「サブビジネス システム」の粒度を使用する方が適切であるというものです。

上記内容は、WOT2018グローバルソフトウェアおよび運用技術サミットにおける58 Daojia CTO Shen Jian氏へのインタビューに基づいて51CTO記者がまとめたものです。 WOT の詳細については、.com をご覧ください。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]