Istio は Spring Cloud を置き換えることができますか?

過去には、私たちは「あらゆることを行う」大規模なモノリシック アプリケーションを運用していました。最初のアプリをオンラインにするだけでよかったので、これは製品を市場に出すのに最適な方法でした。

そして、いつでも戻って改善することができます。複数の小さな部分を構築して展開するよりも、1 つの大きなアプリケーションを展開する方が常に簡単です。

集中化:

クラスタ：

配布：

分散型アプローチと集中型アプローチが併用されます。

ウェブサイトを構築する際、特に同時リクエスト数が多い場合に、ユーザーのリクエストにタイムリーに応答するには、リクエストを処理するための分散クラスターを構築する必要があります。

弊社のサーバーの 1 つの処理能力が制限されています。デバイスの 1 つをサーバーとして使用すると、同時実行性が高くなり、同時に訪問する数が数百に達する可能性があります。その後、サーバーがダウンしました。その後、サーバーを再起動することしかできず、同時アクセスが多いと再びクラッシュします。

したがって、ユーザーのリクエストを処理するには、より多くのサーバーを並行して動作させる必要があります。そこで疑問になるのが、サーバーが稼働しているときに、大量のリクエストをどのようにして異なるサーバーに分散するかということです。

通常、リクエストの分散と処理には (1apache+nTomcat) またはサーバー モードが使用されます。または、nginx を使用してリクエストを分散します。

マイクロサービスは、独自のプロセスで実行される、独立してデプロイ可能なサービス スイートです。通常、HTTP リソースを使用して通信し、各サービスは通常、アプリケーション全体の単一の領域を担当します。

一般的な電子商取引カタログの例では、製品リスト サービス、レビュー サービス、評価サービスがあり、それぞれが 1 つの領域に重点を置いたものになります。

このアプローチにより、ポリグロット サービス (異なる言語で記述されたサービス) も可能になるため、Java/C++ サービスでより計算集約的な作業を実行したり、Rails/Node.js サービスでより多くのフロントエンド アプリケーションをサポートしたりできるようになります。

マイクロサービスは、大規模な分散アプリケーションの主流のアーキテクチャになります。複雑なエンジニアリングの問題は、分割して解決する方法に簡略化できます。分割して解決する方法とは、複雑な問題を 2 つ以上の同一または類似のサブ問題に分割し、そのサブ問題をさらに小さなサブ問題に分割することを意味します...

最後のサブ問題が単純かつ直接的に解決されるまで、元の問題の解決策はサブ問題に対する解決策の組み合わせになります。マイクロサービスの本質はサービスの分解であり、これはエンジニアリング分野で一般的に使用される「分割統治」アプローチと一致しています。

Spring Cloud と K8S

Spring Cloud と Kubernetes という 2 つのプラットフォームは非常に異なっており、両者の間に直接共通する機能はありません。

これら 2 つのフレームワークは、異なる範囲の MSA 障害に対処しており、その対処方法は根本的に異なります。 Spring Cloud のアプローチは、JVM で各 MSA の課題を解決しようとするものですが、Kubernetes のアプローチは、問題をなくし、プラットフォーム レベルで開発者のために解決しようとするものです。

Spring Cloud は JVM で非常に強力であり、Kubernetes はそれらの JVM の管理で非常に強力です。繰り返しになりますが、両方のツールを組み合わせ、両方のプロジェクトの長所を生かすのは自然な流れのように感じました。

ご覧のとおり、焦点のほぼ半分は運用と保守に関連しています。この観点から見ると、Spring Cloud と Kubernetes を比較するのは少し不公平に思えます。 Spring Cloud は単なる開発フレームワークであり、アプリケーションのデプロイやスケジュール設定には無力ですが、Kubernetes は運用および保守プラットフォームです。

おそらく、Spring Cloud + Cloud Foundry を Kubernetes と比較する方が合理的ですが、Cloud Foundry の PaaS 機能が追加されたとしても、Spring Cloud は依然として「侵入的」で言語依存であるのに対し、Kubernetes は「非侵入的」で言語非依存であることに注意する必要があります。

Spring Cloud と Istio

Service Mesh の機能に基づいて、これらのコンテンツのうちどれを削除したり実行したりできますか (Istio を例に挙げます)?

分析の結果、置き換え可能なコンポーネントには、ゲートウェイ (ゲートウェイまたは Zuul、Ingress ゲートウェイまたは egress に置き換え)、サーキット ブレーカー (hystrix、SideCar に置き換え)、登録センター (Eureka および Eureka クライアント、Polit および SideCar に置き換え)、バランシング コンポーネント (Ribbon、SideCar に置き換え)、リンク トラッキングとそのクライアント (Pinpoint および Pinpoint クライアント、SideCar および Mixer に置き換え) が含まれます。

Spring Cloud 解析で実現する必要があるのは、削除または置換する必要があるサポート モジュールを識別することです。

springcloud が注力している機能は kubernetes のサブセットであると言えます。

両側の解決策は比較的完全であることがわかります。 Kubernetes 側では、Istio が登場する前は、最も基本的なサービス登録とサービス検出機能しか提供できませんでした (サービスは単なる 4 層の転送プロキシです)。 Istio が登場して以来、比較的完全なマイクロサービス機能を備えています。

Spring Cloud では、リリース、スケジューリング、セルフヒーリングなどの運用保守プラットフォームの機能に加え、その他の機能もより包括的にサポートされています。相対的に言えば、クラウドベンダーは、非侵襲的であるという理由で Kubernetes ソリューションを好みます。

プラットフォーム機能をアプリケーション層から切り離すことで、クラウドベンダーはアプリケーションの状況を気にすることなく、インフラストラクチャを簡単にアップグレードおよび保守できるようになります。これが、サービス メッシュなどのテクノロジーの将来性について私が楽観的な理由です。

スプリングブート + K8S

Spring Cloud を使用しない場合は、Spring Boot + K8S を使用してください。

ここでは、Kubernetes のサービス モデルを Spring Cloud のサービス モデルにマッピングし、Spring Cloud のネイティブ SDK を使用して Kubernetes でサービス ガバナンスを実装するプロジェクト、Spring Cloud Kubernetes を導入する必要があります。

具体的には、k8s のサービスを Spring Cloud のサービスにマッピングし、k8s のエンドポイントを Spring Cloud のインスタンスにマッピングします。このようにして、k8 サービス ガバナンス システムは標準の Spring Cloud API を介して接続できます。

正直に言うと、このプロジェクトはあまり意味がないと思います。結局のところ、すべては k8 上にあり、すでに比較的完全なマイクロサービス機能 (登録センター、構成センター、負荷分散機能) を備えています。アプリケーションは、アプリケーションが認識することなく、直接相互に呼び出すことができます。 SDK 経由で呼び出すのは少し冗長な気がします。

さらに、現在は押し付けがましくない言語に重点が置かれています。 Spring Cloud の大きな制限は、Java 言語のみをサポートしていることです (古い j2ee アプリケーションもサポートされておらず、Spring Boot アプリケーションのみがサポートされています)。そのため、このプロジェクトの使用範囲は、特定のビジネス サービス レベルでは非常に限定されていると個人的に感じています。

Spring Cloud Kubernetes プロジェクトの助けを借りて、Zuul は非侵入的な方法で API ゲートウェイ機能を提供できます。アプリケーションを変更する必要はまったくありません。ゲートウェイはプラグイン可能であり、将来的に他のゲートウェイ製品と柔軟に置き換えることができます。全体的な結合度は非常に低いです。

k8 のサービス機能のおかげで、Zuul は Spring Cloud システムでは利用できない異種アプリケーションへのアクセスもサポートします。

そして、Java ベースで開発されているため、Java プログラマーは Go や Openresty などの馴染みのない言語を学習することなく、Zuul ベースでさまざまな複雑なフィルターを簡単に開発できます。

サービスメッシュの価値

モノリシック アプリケーションでも分散アプリケーションでも、Service Mesh 上に構築できます。メッシュ上のサイドカーは、すべての上位層アプリケーションをサポートします。ビジネス開発者は、基盤となる構造を気にする必要がなく、Java や Go などの言語を使用してビジネス開発を完了できます。

マイクロサービス アーキテクチャ システムが複雑化すると、「ビジネス サービス」と「インフラストラクチャ」を切り離し、マイクロサービス プロセスを 2 つに分割する必要があります。

なぜプロキシはサイドカープロキシと呼ばれるのですか?

上の写真を見れば簡単に理解できます。ビジネスとプロキシは、バイクとサイドカーのように密接に関係しています。

将来的には、サイドカーとプロキシは、マイクロサービス プロセスが 2 つのプロセスに分離された後に基本的な機能を提供するプロキシ プロセスを指すようになります。

Istio の理論的な概念はサービス メッシュです。この概念については詳しく説明する必要はありません。これは実際にはマイクロサービス実装の一種であり、前述の SideCar モデルに多少似ているからです。

その主なアイデアは関心の分離であり、つまり SpringCloud のように R&D に引き渡されることも、責任の混乱を引き起こすために k8s に統合されることもありません。 Istio は、サービスに対してエージェントを構成することにより、サービス検出、負荷分散、電流制限、リンク追跡、認証などのマイクロサービス ガバナンス メソッドを提供します。

Istio は最初から k8s と組み合わせられるように設計されました。 Istio と k8s を組み合わせることで、マイクロサービス アーキテクチャを効果的に実装できます。

Istio は、Spring Cloud や Dubbo などの従来の開発フレームワークが提供できる機能をはるかに超える機能をもたらすだけでなく、アプリケーション プログラムに多くの変更を必要とせず、開発者が上記の機能を実装するために多くの知識を蓄積する必要がないという点で、Spring Cloud や Dubbo などの従来の開発フレームワークを上回っています。

しかし結論としては、Spring Cloud でできることは、K8s + Istio でもできるということですか?それとももっと良いのでしょうか?