SpringCloud とクラウドネイティブについてお話しましょう。わかりますか？

歴史的な理由により、多くの企業が独自の RPC フレームワークを持っています。

特に2015年から2017年にかけては、Spring Cloudがリリースされたばかりで、Dubboは長年メンテナンスを停止していました。多くの企業は、独自の RPC フレームワークを設計する際に、Spring Cloud をベースに二次開発を行うことになります。また、Spring Cloud Netflix 関連のモジュールやコードも多数使用されます。

したがって、Spring Cloud の過去と現在、およびクラウドネイティブの将来の開発動向を整理することで、これらの RPC フレームワークの進化にインスピレーションをもたらすことができます。

1. スプリングクラウドの歴史

Spring Cloud は、2015 年 3 月のリリース以来、Java マイクロサービスエコシステムの開発者にとって、急速に好まれるテクノロジースタックになりました。

Spring Cloud は Spring Boot をベースに、Java 開発の習慣を維持し、分散機能を追加し、開発者が分散システムで一般的なパターンを迅速に構築できるようにする一連の一般的なツールを提供します。現在では、最も広く使用されているマイクロサービスアーキテクチャの 1 つとなっています。

Spring Cloud は、マイクロサービス開発に必要な構成管理、サービス検出、サーキットブレーカー、インテリジェントルーティング、クラスター状態管理などのコンポーネントを提供します。最も重要なのは、Spring Boot フレームワークと併用することで、マイクロサービスアーキテクチャの開発が非常に便利になることです。

Spring Cloud 自体は新しいフレームワークではありません。これは一連のフレームワークの有機的な組み合わせです。 Spring Boot の開発の利便性を活用して、分散システムインフラストラクチャの開発を巧みに簡素化します。

すべてのコンポーネントが Spring によって提供されるわけではなく、Netflix が重要な役割を果たしていることに注意してください。登録センター Eureka、サーキットブレーカー Hystrix、負荷分散コンポーネント Ribbon、ゲートウェイ Zuul などの重要なコンポーネントはすべて Netflix によって提供されており、主な貢献は Netflix OSS から行われています。

2. 今日の春雲

Netflix のオープンソース投資の戦略的調整により、Eureka、Hystrix、Ribbon が相次いでメンテナンスの中止を発表し、当時の開発者のほとんどが Spring Cloud = Spring Cloud Netflix だと信じていたため、コミュニティにパニックを引き起こしました。

しかし実際には、Spring Cloud は一連の仕様です。この仕様セットは Netflix OSS に限定されません。 Spring Cloud Alibaba、Spring Cloud Zookeeper、Spring Cloud Consul、Spring Cloud Kubernetes などの実装もあります。最近、Tencent も Spring Cloud Tencent をオープンソース化しました (まだ Spring Cloud 公式コミュニティには参加していません)。

2.1 スプリングクラウドアリババ

Spring Cloud Alibaba (略して SCA) は、最も多くのコンポーネントを備えた中国で最もアクティブな Spring Cloud 実装であり、Spring Cloud Netflix を置き換えるのも最も簡単です。

次の図は、関連する機能とコンポーネント間のマッピング関係を明確に表しています。

（出典：https://www.oschina.net/question/4489239_2321891）

SCA の Spring Cloud 実装では、現在非常に人気のあるいくつかのプロジェクトが採用されており、基本的に高速アクセスと安定した使用を実現できることがわかります。

ただし、ここで注意すべき点が 1 つあります。 SCA バージョン 2.2.7-RELEASE 以降、dubbo のクイックアクセスはサポートされなくなりました。代わりに、Spring Cloud のネイティブ呼び出しメソッド (OpenFeign および RestTemplate) が直接使用されます。

なぜ？問題を確認したところ、コミュニティのディスカッション https://github.com/alibaba/spring-cloud-alibaba/issues/2398 が見つかりました。

まとめると、いくつかの理由があります。

SCA の Spring Cloud Dubbo モジュールにはいくつか問題があり、それを保守する人員が不足しています。あまり利用されていないため、今後はメンテナンスされなくなります。

SCA の目的は、SpringCloud 関連モジュールを nacos、sentinal、seata、rocketMQ などの Alibaba Cloud 関連コンポーネントに素早く置き換えることです。

Dubbo 独自のエコシステムは非常に成熟しており、通常は Spring Cloud と混在させる必要はありません。通常は、2つのうち1つだけを選択する必要があります。特に Dubbo 3.x 以降では Mesh がサポートされており、REST 呼び出しを通じて自己完結型のシステムを形成できます。

2.2 春のクラウドテンセント

Spring Cloud Tencent（以下、SCT）は、Tencent が最近オープンソース化した SC 実装フレームワークです。プロジェクトのアドレスは https://github.com/Tencent/spring-cloud-tencent です。

これは、Tencent Cloud Polaris をコアとして、登録センター、構成センター、サービスルーティング、電流制限などを実装した、自社開発のコンポーネントの完全なセットです。

現時点では、テンセントグループ内での利用が比較的多く、社外の事例は少ないです。

2.3 まとめ

Spring Cloud Netflix はメンテナンスされなくなりましたが、Spring Cloud は依然として非常に人気があり、SCA は中国で最適な実装オプションになる可能性があります。

3. Spring Cloudとクラウドネイティブ

3.1 機能の違い

まず、Spring Cloudはクラウドネイティブに近いと考えています。

https://github.com/spring-cloud/spring-cloud-commons より：

クラウドネイティブは、継続的デリバリーと価値主導型開発の分野でベストプラクティスを簡単に採用できるようにするアプリケーション開発スタイルです。関連する分野として、12 要素アプリケーションの構築があります。この分野では、宣言型プログラミングや管理、監視などを使用することで、開発手法が配信と運用の目標と整合されます。 Spring Cloud は、さまざまな特定の方法でこれらの開発スタイルを容易にします。出発点は、分散システム内のすべてのコンポーネントが簡単にアクセスする必要がある機能のセットです。

ただし、Spring Cloud と最も人気のあるクラウドネイティブのサービスメッシュシステムの間には依然として大きな違いがあります。

比較は次の4つの側面から行うことができます。

(表の出典: https://medium.com/codex/a-spring-cloud-compatible-service-mesh-6ce58c571012)

前述したように、Spring Cloud システムは実際には、サービス登録と検出、負荷分散、回路遮断と劣化などを含む一連のプログラミングモデル (仕様) を定義します。

しかし、これらの一部はアプリケーションに依存せず、インフラストラクチャ内に埋め込まれるのでしょうか?

クラウドネイティブ環境では、そうです。

つまり、Spring Cloud で定義された仕様の一部は、クラウドネイティブ環境では若干冗長になる可能性があります。サービスメッシュはアプリケーションに依存しません。

もちろん、Spring Cloud は、インターフェースレベルのガバナンス、よりきめ細かいリンクトラッキングなど、Service Mesh ではできないいくつかの機能を実行できます。

さらに、クロスランゲージも Service Mesh の大きな障害となります。

クラウドネイティブ環境では、コンテナ化された操作とマルチクラウド展開により、マイクロサービスは正確なテクノロジースタックを気にする必要がなくなります。 Python、C++、Nodejs はすべてクラウドネイティブ環境で簡単に実行できます。

ただし、Spring Cloud は Java エコシステムにのみ適しており、Java アプリケーションコードに侵入するため、複数の言語に対しては比較的弱いです。（実は、これはコンテナ化後のJava言語の優位性にも影響を与えています）

3.2 成熟度の違い

成熟度という点では、Service Meshのistio + envoyの組み合わせは多くの大規模・中規模企業で実践されていますが、Spring Cloudにはまだ遠く及びません。

2022年9月24日、クラウドネイティブコミュニティが主催する第1回サービスメッシュサミットが上海で開催されました。カンファレンスの内容から、Service Mesh は使いやすさ、汎用性、学習コストの面で依然として比較的高いことがわかります。

市場はサービスメッシュに注目するとより合理的になり、サービスメッシュ自体はより「実用的」になり、迅速かつスムーズな実装を出発点として、パフォーマンス、リソース使用量、クラスター間、マルチプロトコルサポート、機能拡張など、実装プロセスにおけるさまざまな問題を解決します。これらの問題を解決するには、Istio/Envoy システムを最適化し続けるか、他の実装に切り替えて、MOSN、Pipy、APISIX、Linkerd Proxy などのデータプレーンプロキシを置き換えるか、eBPF、WASM、RDMA、DPDK などの他のテクノロジを導入して問題を解決します。

4. どこへ行く？

4.1 k8s をコンテナのオーケストレーションとスケジューリングとしてのみ使用しますか?

現時点では、Java ベースのマイクロサービスシステムは比較的完成しているため、k8s を使用する場合でも、istio のサービスガバナンス機能に接続せずに、コンテナオーケストレーションにのみ k8s を使用できます。

Spring Cloud ファミリーが、Java システム下でのマイクロサービスの設計と実装をワンストップで満たせることは間違いありません。

もちろん、主な問題は、クラウドネイティブでは多言語ガバナンス機能が欠けていることです。

また、knativeやseldonなどのプラットフォームと接続する場合、トラフィック管理のためにistioに直接接続されるため、トラフィック管理がより面倒になります。

4.2 Spring Cloud の今後の方向性は?

Mesh システムでは、HTTP 呼び出しが当然サポートされているため、Spring Cloud 呼び出しアクセスは比較的便利であり、Spring Cloud Kubernetes プロジェクトでも登録センターが開設されています。

主な問題点は、統合コントロールプレーンのサービスガバナンスへのアクセスにあります。

Spring Cloud の場合、目標はプロキシレスシステムを実装することですが、公式コミュニティではこの点に関して特別な検討は行われていません。

ただし、Spring Cloud Alibaba のサービスガバナンスコンポーネントである Sentinel にはいくつかの変更があります。

センチネルの歴史

2012年に、入口トラフィック制御を主な機能とするSentinelが誕生しました。
2013年から2017年にかけて、SentinelはAlibabaグループ内で急速に発展し、すべてのコアシナリオをカバーする基本的な技術モジュールになりました。その結果、Sentinel には多数のトラフィック集約シナリオと実稼働プラクティスが蓄積されました。
2018 年に Sentinel はオープンソース化され、進化を続けています。
2019 年、Sentinel は多言語拡張の方向性を模索し続け、C++ ネイティブバージョンをリリースしました。同時に、サービスメッシュアーキテクチャにおける多言語の現在の制限の問題を解決するために、サービスメッシュシナリオ向けの Envoy クラスタートラフィック制御サポートも開始しました。
2020 年には Sentinel Go バージョンがリリースされ、クラウドネイティブに向けた進化が続いています。
2021 年、Sentinel は 2.0 クラウドネイティブの高可用性意思決定センターコンポーネントに向けて進化します。同時に、Sentinel Rust ネイティブバージョンもリリースされました。同時に、Rust コミュニティでは Envoy WASM 拡張や eBPF 拡張などのシナリオも検討しています。
2022 年に、Sentinel ブランドはトラフィック管理にアップグレードされ、トラフィックルーティング/スケジューリング、トラフィックカラーリング、フロー制御の低下、過負荷保護/インスタンスの削除などの領域をカバーします。同時に、コミュニティはトラフィック管理関連の標準を OpenSergo 標準に抽出し、トラフィック管理標準として Sentinel を実装しました。

さらに、Sentinel コミュニティはトラフィック管理関連の標準を OpenSergo 標準に抽出しており、Sentinel はトラフィック管理標準として実装されています。 Sentinel フロー制御の劣化とフォールトトレランス仕様の最新の開発については、opensergo-specification を参照してください。

ただし、Sentinel はフォールトトレランスに重点を置いており、ルーティング機能がありません。

したがって、OpenSergo がこの機能をどのように実現するかに引き続き注目するしかありません。