Javaプログラマーは「プラスポイント」を再開しますが、マイクロサービスアーキテクチャテクノロジーについてどのくらい知っていますか？

記事を開く前に、マイクロサービスに対するいくつかの態度を述べます。

多くのアーキテクチャパターンがあり、マイクロサービスだけが選択肢でも特効薬でもありません。国内の中小企業の大多数がやみくもにマイクロサービスの導入を進めており、このような技術選択を行う技術者のインフラの質が不十分であることがわかります。

「マイクロサービスを使用するには、十分な身長が必要です。」マイクロサービスインフラストラクチャ、特にコンテナテクノロジー、自動展開、自動テストは不完全であり、マイクロサービスは無駄であり、質的な改善はもたらされません。

マイクロサービスアーキテクチャの鍵は、特定の実装ではなく、サービス境界を合理的に分割する方法と、組織構造が一致するかどうかです。研究開発チームの規模や構成に関係なく、マイクロサービスを盲目的にリストすることは、テクノロジーの選択としては不適切です。

Spring Bootは、Springのファミリーバケットの上位カプセル化であり、まったく新しいテクノロジーではなく、独自のキラーになるに値するテクノロジーでもありません。

SpringCloudのSpringCloud Netflixのコンポーネントは本番環境で検証されていますが、他のコンポーネントは慎重に選択することをお勧めします。

マイクロサービスとは

マイクロサービスは、2005年のクラウドコンピューティングエキスポでPeter Rodgers博士によって提案されたMicro-Web-Service（Micro-Web-Service）に端を発しています。基本的な考え方は、Unixパイプラインの設計コンセプトに似ています。2014年、MartinFowlerとJamesLewisは共同でマイクロサービスの概念を提案し、マイクロサービスアーキテクチャスタイルは一連の小さなサービスを通じて単一のアプリケーションを開発する方法であると定義しました。各サービスは独自のプロセスで実行され、通信用の軽量メカニズムを通過します。（HTTP API）。3つの重要なポイントは、小さく、自動化され、軽量です。

マイクロサービスは、SOAと比較して、SOAのサブセット、軽量のSOAと見なすことができ、よりきめ細かいサービス、独立したプロセス、データ分離、および俊敏性、継続的デリバリー、DevOps、分散型プラクティスに重点を置いています。一般的なアーキテクチャの原則：

単一責任
関心の分離：制御とロジックの分離
モジュール性と分割統治

特徴：

サービスによるコンポーネント化
ビジネス機能を中心に整理する
プロジェクトではなく製品です
エンドポイントインテリジェンスとダムパイプ：制御ロジックはエンドポイントにあり、パイプは単なる送信です
完全に自動化された展開
言語とデータの分散制御
失敗のための設計
プログレッシブデザイン

まとめると、その長所と短所は次のとおりです。

利点：

モジュールの強い境界
独立した展開
技術選択の多様性

短所：

分散はプログラミングの複雑さとリモート呼び出しの消費をもたらします
強い一貫性を放棄し、究極の一貫性を実現する
運用の複雑さには、成熟した運用および保守チームまたは運用および保守インフラストラクチャが必要です

マイクロサービスを採用する理由

マイクロサービスを選択するかどうかは、設計するシステムの複雑さによって異なります。マイクロサービスは複雑なシステムを制御するために使用されますが、それに伴ってマイクロサービスの複雑さが導入されます。自動展開、監視、フォールトトレラント処理、結果整合性など、他の分散システムが直面する問題を解決する必要があります。一般的に使用されるソリューションがいくつかある場合でも、かなりのコストがかかります。

生産性と複雑さの関係を図に示します。システムが複雑になるほど、マイクロサービスによってもたらされるメリットが大きくなることがわかります。さらに、モノリシックアプリケーションであろうとマイクロサービスであろうと、チームのスキルを制御できる必要があります。

Martin Fowlerの見解の1つは、単一のアプリケーションを管理するコストがすでに複雑すぎない限り（大きすぎると変更とデプロイが困難になる）、マイクロサービスを考慮しないでください。ほとんどのアプリケーションは、モノリシックアーキテクチャを選択し、モノリシックアプリケーションをサービスに分割するのではなく、モジュール化するのに適しています。

したがって、最初は、システムはモノリシックアーキテクチャを採用し、十分にモジュール化されています。その後、システムがますます複雑になり、モジュール/サービス間の境界が明確になるにつれて、マイクロサービスアーキテクチャパスに再構築するのが合理的なアーキテクチャです。

マイクロサービスには、次の4つの状況が考えられます。

多くの人がモジュール/プロジェクトを開発し、コードを送信するときに頻繁に競合が発生します。
モジュールは緊密に結合されており、相互に依存しています。各変更には複数のチームが関与する必要があります。1回の起動には要件が多すぎて、リスクが高くなります。
本業と副業は連動しており、水平展開は複雑です。
ヒューズのダウングレードは、if-elseによって異なります。

マイクロサービスの3つの段階：

マイクロサービス1.0：登録検出のみを使用し、SpringCloudまたはDubboに基づいて開発します。
マイクロサービス2.0：サーキットブレーカー、電流制限、ダウングレードなどのサービスガバナンス戦略を使用し、完全なサービスツールとプラットフォームを備えています。
マイクロサービス3.0：サービスメッシュはサービスガバナンスを一般的なコンポーネントとして採用し、プラットフォームレイヤーに実装されます。アプリケーションレイヤーはビジネスロジックのみに焦点を当てます。プラットフォームレイヤーは、ビジネスモニタリングに従ってパラメーターを自動的にスケジュールおよび調整して、AIOpsとインテリジェントなスケジューリングを実現できます。

マイクロサービスアーキテクチャ

前提条件

迅速な環境プロビジョニング機能：クラウドコンピューティングとコンテナテクノロジーを利用して、環境を迅速に提供します。
基本的な監視機能：基本的な技術的監視とビジネス監視を含みます。
迅速なアプリケーション展開機能：迅速な展開機能を提供するには、展開パイプラインが必要です。
Devopsカルチャー：フルリンクトラッキング、迅速な環境のプロビジョニングと展開などを含む、優れた継続的デリバリー機能が必要です。また、迅速な対応機能（問題と障害への迅速な対応）、および開発と運用と保守の共同作業も必要です。。

さらに、コンウェイの法則と逆コンウェイの法則（技術的構造は組織構造の改善を強制する）によれば、組織構造も非常に重要な要素です。マイクロサービスアーキテクチャに対応して、組織構造は次の原則に従う必要があります。

マイクロサービスはチームによって維持され、チームメンバーは3人であることが望ましい。
単一のチームのタスクと開発は独立しており、他の要因の影響を受けません。
チームは完全に機能し、フルスタックで、自律的で、フラットで、自己管理されています。

インフラ

マイクロサービスの実装は、マイクロサービスのコンパイル、統合、パッケージ化、デプロイ、構成などの提供を含む多くの基盤となるインフラストラクチャに依存する必要があります。PaaSプラットフォームを使用して、開発から運用までのマイクロサービスのライフサイクル管理全体を解決し、異種環境管理、コンテナーリソースの分離と相互通信、サービススケーリングのドリフト、サービスのアップグレードとロールバック、サービスの融合とダウングレード、サービスの登録と検出。

最も基本的なインフラストラクチャ

プロセス間通信メカニズム：マイクロサービスは独立したプロセスであり、マイクロサービス間の通信方法を決定する必要があります。
サービス検出+サービスルーティング：サービスレジストリを提供し、サービスプロバイダーとコンシューマーは、サービス検出を通じてサービス情報を取得してサービスを呼び出し、サービスの負荷分散を実現します。
サービスフォールトトレランス：マイクロサービスアーキテクチャでは、サービスが多いため、1つのサービスがダウンすることが多く、リクエストリンクサービス全体が影響を受けるため、サービスフォールトトレランスが必要です。サービス呼び出しが失敗すると、エラーを処理したり、失敗したりする可能性があります。サーキットブレーカーを含む迅速な、フォールバック、再試行、フロー制御、サービス分離など。
分散トランザクションのサポート：ビジネスがサービスに分割されると、クロスサービストランザクション、つまり分散トランザクションの問題が避けられない場合があります。原則は、分散トランザクションを可能な限り回避することです。それが避けられない場合は、メッセージシステムまたはCQRSおよびイベントソーシングソリューションを使用して、結果整合性を実現できます。強力な一貫性が必要な場合は、2フェーズコミット、3フェーズコミット、TCCなどの分散トランザクションソリューションがあります。

外部サービスのドッキング効率と内部開発効率を向上させる

APIゲートウェイ：外部システムへのアクセス、およびセキュリティ、ロギング、権限制御、送信暗号化、要求転送、フロー制御などを含む、横断的なパブリックレベルの作業を担当します。典型的なゲートウェイ機能は、ドメイン名xx.comを外部に公開し、第1レベルのディレクトリに従ってxx.com/user、xx.com/tradeを逆ルーティングすることです。ユーザーやトレードなどのディレクトリの各レベルは、サービスドメイン名に対応しています。さらに、APIゲートウェイはサービスオーケストレーション機能を持つこともできます（非推奨）。
インターフェースフレームワーク：サービス間の通信で使用されるデータ形式、解析パッケージ、および自明のドキュメントを標準化して、サービスユーザーがすぐに開始できるようにします。

テストと運用および保守の効率を向上させる

継続的インテグレーション：この部分はマイクロサービスに固有のものではありません。以前のモノリシックアプリケーションでは、この部分は通常必要です。主に、コードプロセスの継続的なコンパイルと構築、および自動化された手段による自動化されたテストを指し、高速で効果的な品質フィードバックを取得して、コードのスムーズな配信を保証します。自動テストには、コードレベルの単体テスト、単一システムの統合テスト、およびシステム間のインターフェイステストが含まれます。
自動展開：マイクロサービスアーキテクチャ。ノードの数は数百または数千になります。自動展開により、展開速度と展開頻度が向上し、継続的デリバリーが保証されます。バージョン管理、リソース管理、展開操作、ロールバック操作などの機能を含みます。マイクロサービスのデプロイ方法には、ブルーグリーンデプロイメント、ローリングデプロイメント、カナリアデプロイメントが含まれます。
構成センター：実行時の構成管理により、構成を動的に変更し、バッチで有効にするという問題を解決できます。構成バージョン管理、構成アイテム管理、ノード管理、構成同期などを含みます。
継続的デリバリー：継続的インテグレーション、自動展開、その他のプロセスを含みます。目標は、小さなステップで繰り返し、迅速に提供することです。

運用・保守効率をさらに向上

サービスの監視：マイクロサービスアーキテクチャには多数のノードがあり、監視する必要のあるマシン、ネットワーク、プロセス、インターフェイスなどの数が大幅に増加しています。リアルタイムを提供できる強力な監視システムが必要です。分析のための情報の収集とリアルタイム分析の早期警告。サービス要求時間の監視、応答時間の分布、最大/最小応答値、エラーコードの分布などを含みます。
サービス追跡：要求の開始時間、応答時間、応答コード、要求パラメーター、戻り結果、その他の情報を含む、要求の完全なパスを追跡します。これは、フルリンク追跡とも呼ばれます。通常のサービス監視はサービス監視と一緒に実行でき、マクロ情報はサービストラッキングによって表示され、単一のサービス/ノードに関するミクロ情報はサービス監視によって表示されます。サービス追跡の現在の実装理論は、基本的にGoogleのDapperペーパーです。
サービスのセキュリティ：原則として、イントラネット間のマイクロサービスコールは、相互にアクセスおよび書き込みできる必要があります。通常、アクセス許可の制御は必要ありませんが、ビジネス要件に限定される場合もあり、インターフェイスとデータのセキュリティ制御要件があります。この部分は、構成可能な方法でサービスレジストリに存在し、サービスにバインドし、要求されたときにサービスプロバイダーとしてのサービスノードのセキュリティポリシーによって制御できます。構成は構成センターに保存して、動的な変更を容易にすることができます。

マイクロサービスの数が少ない場合、上記のインフラストラクチャの優先度は上から下に向かって低下します。そうしないと、手動操作のみに依存すると、入出力比が非常に低くなります。

また、Dockerコンテナテクノロジーについても言及する必要があります。これはマイクロサービスには必要ありませんが、コンテナテクノロジーは軽量で柔軟性があり、アプリケーションに依存し、環境の違いをシールドします。継続的デリバリーの特性は、従来の単一アプリケーションであっても、継続的デリバリーを実現するために重要です。配信効率。

アーキテクチャデザインパターン

マイクロサービスの導入後、従来のモノリシックアプリケーションはサービスになりました。アプリケーションがクライアントアクセス用のインターフェイスを直接提供する以前のアーキテクチャは適用できなくなりました。マイクロサービスアーキテクチャでは、さまざまなデバイスのインターフェイスがBFFレイヤー（フロントエンドのバックエンド）として使用されます。これは、ユーザーエクスペリエンス適応レイヤーとも呼ばれ、マイクロサービスのデータを集約および調整し、それらを必要なデータに変換します。フロントエンド。サービス間の呼び出しは、許可されている場合（遅延を許可する場合）に可能な限り非同期メッセージングを使用するため、ユーザーエクスペリエンス指向のマイクロサービスアーキテクチャデザインパターンが形成されます。以下に示すように：

クライアント-> APIゲートウェイ-> BFF（フロントエンドのバックエンド）->ダウンストリームマイクロサービス

バックエンドはマイクロサービスアーキテクチャを採用しており、マイクロサービスはさまざまなプログラミング言語とさまざまなストレージメカニズムを採用できます。
フロントデスクはBFFモードを採用して、さまざまなユーザーエクスペリエンス（デスクトップブラウザー、ネイティブアプリ、タブレットレスポンシブWebなど）に適応します。
BFF、APIオーケストレーションレイヤー、エッジサービスレイヤー、デバイスラッパーレイヤーは同じ概念です。
BFFは多すぎることはできません。多すぎると、コードロジックの重複と冗長性が発生します。
Geoip、電流制限、セキュリティ認証など、ゲートウェイによって実行される機能は、BFFと同じレイヤーに配置できます。BFFレイヤーの複雑さは増しますが、パフォーマンス上の利点を得ることができます。

サービス分割

マイクロサービスアーキテクチャのコアリンクは、主にサービスの水平分割です。サービス分割とは、完全なビジネスシステムをサービスに分離することを指します。サービスには、単一の責任が必要であり、それらの間に結合関係はなく、独立した開発と保守が必要です。

サービスの分割は一夜にして行われるわけではなく、開発プロセス中に境界を継続的にクリアする必要があります。サービスを完全に分類する前に、サービスの分割、特にデータベースの分割を延期してみてください。

分割方法は次のとおりです。

ビジネスロジックに基づいて分割
スケーラブルな分割に基づく
信頼性に基づいて分割
パフォーマンスに基づいて分割

その中で、変更できないレガシーシステムについては、元のシステムを直接変更するのではなく、レガシーシステムの外部に新しい機能を追加してマイクロサービスを作成し、古いシステムを徐々に置き換えるという絞殺モードが採用されています。

分割時に従う必要のある仕様は次のとおりです。

最初に少なく、次に多く、最初に粗く、次に細かい（粒度）
サービスは、垂直方向に最大3つのレイヤーに分割でき、2回呼び出すことができます：コントローラー、複合サービス、基本サービス
片道通話のみ、周期通話は禁止されています
シリアルコールがパラレルコールまたは非同期コールに変更されます
インターフェイスはべき等である必要があります
インターフェイスデータ定義を埋め込み、透過的に送信することは固く禁じられています
標準化されたプロジェクト名
最初にサービスを分割し、サービスの粒度が決定された後にデータベースを分割します。

マイクロサービスフレームワーク

上記は、マイクロサービスアーキテクチャの多くのインフラストラクチャについて説明しています。各インフラストラクチャを独自に開発する必要がある場合、それは非常に大きな開発作業です。市場にはすでに多くのオープンソースマイクロサービスフレームワークから選択できます。

スプリングブーツ

Spring Bootは、新しいSpringアプリケーションの初期セットアップと開発プロセスを簡素化するために使用されます。これはマイクロサービスフレームワークではありませんが、本来の目的は基本的にマイクロアプリケーションの基盤となるフレームワークであるため、マイクロサービスインフラストラクチャの開発やマイクロサービスアプリケーションの開発に非常に適しています。特にSpringテクノロジースタックチームにとって、SpringBootに基づいてマイクロサービスフレームワークとアプリケーションを開発することは自然な選択です。

ダボ&&モータン

DubboAliのオープンソースサービスガバナンスフレームワーク。マイクロサービスの概念が登場する前に登場し、SOAフレームワークの傑作と見なすことができます。ただし、サーキットブレーカー、サービストラッキング、ゲートウェイなど、マイクロサービスインフラストラクチャの機能の一部のみが含まれています。実装されていません。

Motanは、Dubboよりも軽量なWeiboのDubboに似たオープンソースのRPCフレームワークです。

サービスディスカバリ：サービスの公開、サブスクリプション、通知
高可用性戦略：フェイルオーバー、フェイルファスト、リソースの分離-負荷分散：最もアクティブでない接続、コンシステントハッシュ、ランダムリクエスト、ポーリングなど。
拡張性：SPI拡張機能（サービスプロバイダーインターフェイス）をサポート
その他：通話統計、アクセスログなど。

春の雲

Spring Cloudは、Spring Bootに基づくマイクロサービスフレームワークであり、一連のマイクロサービス実装仕様と見なすこともできます。基本的に、構成管理、サービスディスカバリ、サーキットブレーカー、インテリジェントルーティング、マイクロエージェント、コントロールバス、グローバルロック、意思決定キャンペーン、分散セッション、クラスター状態管理など、マイクロサービスインフラストラクチャのすべての側面をカバーします。それは春の生態学に基づいており、コミュニティのサポートはとても良いです。ただし、そのコンポーネントの多くは実稼働環境で検証されていないため、慎重に選択する必要があります。

Spring CloudNetflixはSpringCloudのサブプロジェクトであり、SpringのNetflixOSSの統合実装です。Netflixの大規模な使用に基づいて、広く使用されているコンポーネントは次のとおりです。

さらに、別のサブプロジェクトSpring Cloud Alibabaは、AlibabaのオープンソースのSpring Bootベースのマイクロサービスフレームワークであり、主にAlibabaCloudサービスをサポートしています。

ユーレカ：サービス登録とサービス発見
リボン：柔軟でインテリジェントなプロセス間およびサービス通信メカニズム、クライアントの負荷分散
Hystrix：ヒューズ、動作中の遅延とフォールトトレランスの分離を提供
ズール：サービスゲートウェイ

サービスメッシュ

前述のマイクロサービスフレームワークはすべて煩わしいものであり、サービスのプロセスにはコード変換が必要です。サービスメッシュは次世代のマイクロサービスアーキテクチャであり、最も明白な機能は非侵入型です。サイドカーモデルは、システムアーキテクチャがマイクロサービスされた後、サービス間の通信とガバナンスの問題を解決するために使用されます。以下に示すように：

現在の主流のオープンソースの実装は次のとおりです。

サービスメッシュによって引き起こされるパフォーマンス遅延のコストとサイドカーの配布の複雑さの増加に限定され、大規模な展開（多数のマイクロサービス）、異種の複雑な（複数のタイプの対話プロトコル/開発言語）マイクロサービスアーキテクチャをもたらします。大きくなります。

Linkerd and Envoy：サイドカーをコアとして、適切なプロキシを実行する方法に焦点を当て、いくつかの一般的なコントロールプレーン機能を完了します。これらのサイドカーの管理と制御の欠如。
IstioとConduit：現在最も人気のあるサービスメッシュ実装ソリューションは、より強力なコントロールプレーン（サイドカーはデータプレーンと呼ばれます）機能に焦点を当てています。前者はGoogleとIBMのコラボレーションであり、サイドカー部分の実装としてEnvoyを使用します。後者は、Linkerdの作者の作品です。それに比べて、Istioは巨大な背景を持ち、強力ですが、その使いやすさと使いやすさは高くありません。一方、Conduitは比較的シンプルで、機能に重点を置いています。

ソファスタック

Ant Financialは、金融レベルの分散アーキテクチャを構築するためのミドルウェアのセットを開きます。マイクロサービス開発フレームワーク、RPCフレームワーク、サービスレジストリ、フルリンクトラッキング、サービスモニタリング、サービスメッシュなどの分散アプリケーション開発ツールのセットが含まれます。

特に言及する価値があるのはSOFAMeshです。実際、Istioの改善と拡張に基づいた、次世代のマイクロサービスアーキテクチャサービスメッシュの大規模な実装の実践は、中国で最も成熟したオープンソースのサービスメッシュソリューションになるはずです。

さらに、コードに侵入することなく、マイクロサービス機能のサポート（ドメイン名によるサービス検出）の一部を提供するKubernetes（K8s）についても言及する必要があります。ただし、サービスコールとサーキットブレーカは自分で実装する必要があります。

要約すると、同社の技術チームの現在のテクノロジースタックはSpringであり、既存のサービスの実装はDubboに基づいているため、Spring Cloud Netflixが基本的なマイクロサービスフレームワークとして選択されています。未成熟または不足しているコンポーネントの場合、業界はより成熟しました。コンポーネントは交換できます。

APIゲートウェイ：ズール
サービスレジストリ：Dubbo
構成センター：disconf
サービスモニタリング&&フルリンクトラッキング：CAT
サービス開発フレームワーク：Spring Boot
ログの監視と警告：ELK + Elasalert
フロー制御：Sentinel
メッセージキュー：Kafka