Spring CloudAlibabaオープンソースの裏話|オープンソース中国インタビュー
投稿日：2018-11-28 | Author Miss Middleware | Spring CloudAlibabaのカテゴリー |
この記事は、オープンソースチャイナによるSpring CloudAlibabaプロジェクトチームへの独占インタビューです。オープンソースチャイナで最初に公開され、AlibabaMiddlewareの許可を得て転載されました。インタビューを受けたゲストは、Spring CloudAlibabaプロジェクトチームの責任者であるJiWangでした。
最近、Javaの世界で大きなイベントが発生しました。SpringCloudは、AliがSpring Cloud Alibabaをオープンソース化し、最初のプレビューバージョンをリリースしたことを正式に発表しました。
最近、Javaの世界で大きなイベントが発生しました。SpringCloudは、AliがSpring Cloud Alibabaをオープンソース化し、最初のプレビューバージョンをリリースしたことを正式に発表しました。
報告によると、Spring Cloud Alibabaは、AliオープンソースコンポーネントとAliyun製品コンポーネントの2つの部分で構成されており、マイクロサービスのワンストップソリューションの提供に取り組んでおり、開発者はSpringCloudプログラミングモデルを通じてマイクロサービスアプリケーションを簡単に開発できます。
オープンソースのニュースは大きな反響を呼びました。SpringCloudAlibabaの登場は、Java開発者の注目を集めただけでなく、プロジェクトの背後にある最もホットなマイクロサービスアーキテクチャ分野にも人々の注目を集めました。
現在、SpringCloudを使用するための最初の選択肢はSpringCloud Netflixであり、その主導的地位は揺るぎないものです。今回、Aliがオープンソース化した「ネイティブ国内」環境でのこのプロジェクトは変化をもたらすでしょうか。着陸慣行が増えるにつれ、マイクロサービスアーキテクチャの欠点が徐々に明らかになりましたが、現時点で、この分野でのアリの主要な動きの背後にある考慮事項は何ですか？
さらに、開発者が注目しているプロジェクトのポストメンテナンスや、Dubboが再び放棄されたかどうかなどの問題もあります... AlibabaミドルウェアのシニアテクニカルエキスパートであるJiWangに初めてインタビューしました。皆さんがSpringCloudAlibabaに興味を持ってくれることを願っています。 、関連分野の発展と動向をより深く理解する。
この記事の内容は長くなっています。ここにいくつかの重要なポイントがあります。
- 中国のJava開発者の福音
- マイクロサービスアーキテクチャの分野における新しい選択肢
- DubboとSpringCloudは競合していません
- 次世代アーキテクチャはストリーミングアーキテクチャではなく、サーバーレスです
- クラウドコンピューティングは、最終的にサーバーアーキテクチャ全体を支配します
- 来年2月GA
オープンソース中国：
春？春のブーツ？春のフレームワーク？春の雲？春の雲アリババ？Spring Family BucketはJava開発で言及する必要があります。これはよく知られており、よく使用されていますが、多くの人はフレームワークを使用しているだけで、SpringCloudが何であるかさえ知りません。上記の用語についてはばかげています。わからない。この場をお借りして、詳しいご紹介をさせていただきます。
Ji Wang：
国内のJavaerの世界では、Springという言葉だけでは実際には何も指していません。それは単なるコードです。具体的な意味はコンテキストによって異なります。たとえば、Springが大きな神であると言うとき、Springはこの時点でSpring Companyを指します。たとえば、通常、Springを開発に使用しますか？この時点で、Springは一般にSpring IOCを指し、ほとんどの場合、SpringはSpringを指します。すべてSpringIOCです。
ここではSpringIOCについてあまり説明しません。誰もがそれをよく知っていると思います。これは、最もホットなインタビューの質問の1つになるはずです。SpringFrameworkはSpringIOCとコアSpringAOP機能を中心に展開し、多くのJ2EE開発フレームワークとの統合を実現します。これにより、エンタープライズレベルのアプリケーション開発の難しさが大幅に軽減され、効率が向上します。
数年前に人気のあったSSHフレームワークは、HibernateとStruts2を統合したSpringFrameworkの典型的な例です。当時、SSH統合を学ぶことは巧妙でした。複雑な構成ファイルと無限のJarパッケージは、間違いなくあなたを驚かせる可能性があります。したがって、Spring Bootがこの問題を解決するため、現在のJavaerは満足しています。
Spring Bootを使用すると、POM依存関係を導入して、すべてのJarパッケージの管理を実現できます。また、構成ファイルと数行の単純な構成で、すべての複雑な構成の問題を解決できます。Spring Bootの目的は、ユーザーがSpring Frameworkに基づいて構築されたアプリケーションを開発しやすくすることであり、SpringBootはその目的を完全に果たしていると言わなければなりません。
Spring Cloudに関しては、Spring Bootに基づいて一連のマイクロサービス関連の仕様を追加し、アプリケーションコンテキスト（アプリケーションコンテキスト）を強化します。
Spring Cloudは仕様であるため、実装する必要があります。SpringCloudAlibabaは、SpringCloudマイクロサービス仕様の一連の実装です。
要約すれば：
春は通常、春のIOCを指します。
SpringFrameworkにはSpringIOCとSpringAOPが含まれており、他のJ2EEフレームワークと統合されています。
SpringBootはSpringFrameworkの補足であり、フレームワークの統合を容易にし、独立したSpringアプリケーションの迅速な開発に取り組んでいます。
Spring Cloudは、Spring Bootに基づいて設計された一連のマイクロサービス仕様であり、アプリケーションコンテキストを強化します。
Spring Cloud Alibabaは、SpringCloudのマイクロサービス仕様を実装するための原材料としてAliミドルウェアを使用しています。
オープンソース中国：
現在、SpringCloud仕様はSpringCloud Netflixなどによって実装されています。Alibabaの主な違いと利点は何ですか？
ジ・ワン：
Spring Cloud Alibabaのコンポーネントは、Alibaba独自の内部ミドルウェア製品からインキュベートされています。これらのミドルウェアは、Double 11のテストを経験しており（Double 11は現在、世界最大かつ最も複雑なeコマーストランザクションシナリオです）、圧力に対して非常に耐性があります。能力に疑いの余地はありません。さらに、Spring Cloud Alibabaの完全なネイティブ中国語ドキュメントとローカライズされたオープンソースサービスにより、開発者の学習コストが大幅に削減され、アクセスレートが向上し、その後の運用と保守の難しさが軽減されます。
各コンポーネントに固有：
ナコス
Nacosは、Aliの内部構成管理およびサービス検出コンポーネントのオープンソースに基づいており、多くのダブル11テストを受けており、超大規模クラスターをサポートしています。安定性とパフォーマンスの点で信頼できます。将来的には、この成熟したビジネスモデルに基づいて、グレースケールリリース、環境分離、フルリンクストレステストなどのより高度な機能を構築し、マイクロサービスの実践でアリの大きな殺人者をより多く出力します。
ナコスディスカバリー
Nacos Discovery、Spring Cloud Netflix Eureka、ZooKeeper、およびConsulはすべて、Spring Cloudサービス検出の標準実装に従い、Ribbonによく適合しています。対照的に、NacosDiscoveryには次の特徴があります。
リアルタイムプッシュをサポートし、第2レベルのサービス検出に到達します。
多層災害耐性メカニズム。サービス検出センターのダウンタイムがアプリケーション呼び出しに影響を与えないようにしてください。
Nacos Config
Spring CloudConfigやZooKeeperandConsulなどのNacosConfigは、Spring Cloud構成の標準実装に従いますが、依存コンポーネントが少なく、使いやすく、より強力な機能を備えています。
たとえば、Spring Cloud BusやMQを必要とせず、構成をリアルタイムで直接プッシュでき、プッシュステータスを確認できます。データのロールバックをサポートし、複数のデータ形式をサポートし、中国語を完全にサポートし、最後に複数の耐災害性メカニズムに依存して、構成サーバーの障害がアプリケーション自体に影響を与えないようにします。
RocketMQ
SpringCloudの公式SpringCloud Streamフレームワークは、基盤となるメッセージミドルウェアの処理を保護し、プログラミングに統一されたプログラミングモデルを使用します。現在、KafkaとRabbitMQのバインダーのみが正式に実装されています。アリババのRocketMQメッセージングミドルウェアはApacheのトップレベルのプロジェクトになりました。コミュニティには、RocketMQのバインダーをいつリリースできるかを尋ねる人がたくさんいます。これも非常に必要だと考えています。
センチネル
SpringCloudが公式に推奨しているサーキットブレーカーはHystrixです。Sentinelは、Aliミドルウェアチームによる分散サービスアーキテクチャ用のオープンソースで軽量で可用性の高いフロー制御コンポーネントです。主にフローをエントリポイントとして使用して、フロー制御、ヒューズの劣化、システム負荷保護などの複数の側面からサービスを保護します。安定性。SentinelとHystrixにはいくつかの共通の機能がありますが、基盤となる実装には一貫性がありません。
対照的に、Sentinelには次の特徴があります。
- 軽量、高性能
- 多様なフロー制御戦略
- システム負荷保護
SchedulerX
SchedulerXは、信頼性の高い分散タスクスケジューリングシステムであり、大量のタスクを数秒でスケジューリングし、Java、スクリプト、httpなどの複数のタスクタイプをサポートし、ビッグデータでバッチを実行して使いやすい分散プログラミングモデルを提供します。
ARMS
ARMSはAPM監視製品です。ユーザーは、ARMSフロントエンド監視、アプリケーション監視、またはカスタム監視に基づいて、リアルタイムのアプリケーションパフォーマンスおよびビジネス監視機能をすばやく構築できます。
我ら
OSSは、Alibaba Cloudが提供するクラウドストレージサービスです。プラットフォームに依存しないRESTful APIインターフェイスを備えており、99.999999999％（11 9秒）のデータ信頼性と99.99％のサービス可用性を提供できます。
Spring CloudAlibabaがSpringCloudインキュベーターに参入しました。このニュースは比較的突然と言えますが、インキュベーターに参入する最初から今日までのプロセス全体と、その背後にある考え方を紹介していただけますか？
昨年末、SpringCloudサブプロジェクトにspring-cloud-awsコンポーネントとspring-cloud-gcpコンポーネントが含まれていました。これにより、SpringBootプログラミングを使用する際のAWSおよびGCPユーザーの効率を向上させることができます。
当時、AlibabaCloudの製品もSpringCloudエコシステムに統合されれば、Alibaba CloudのJavaユーザーの幸せが確実に高まると考え、関連作業を開始しました。最初のプロジェクトはspring-cloud-alibabacloudと呼ばれていました。
しかしその後、Aliミドルウェアがオープンソースを完全に採用するにつれて、サービス検出や構成管理コンポーネントのNacosやトラフィック保護Sentinelなどのヘビーウェイトミドルウェアが次々とオープンソース化されました。同時に、SpringCloudの使用時に遭遇したオープンソースコミュニティがすでに実装されていることもわかりました。そのようなそしてそのような問題。現時点では、Double11でテストされたこれらの本番レベルのミドルウェアをSpringCloudエコシステムに接続する方がクールだと感じています。そこで、Spring CloudAlibabaを別のアイテムとして入れてSpringCloudの公式に提出しました。
現在、NacosとSentinel、Alibaba CloudのOSS、ACM、ANSを含む最初のバージョンをリリースしました。Aliはオープンソースの取り組みを増やし続けているため、将来的にはさらに多くのコンポーネントが追加される予定です。
オープンソースの中国：
Spring CloudAlibabaはSpringCloud仕様の新しいセットの正式に認定された実装になりました。これは多くの点でどういう意味ですか？
Ji Wang：
以下の観点からお話させていただきます。
1つは、大規模なクラスターシナリオでのSpringCloudのネイティブ実装の制限を補うことです。Spring Cloud仕様には多くの実装があります。たとえば、Netflixには独自のシステムセットがあり、Consulはサービス登録と構成管理をサポートし、ZKはサービス登録をサポートします。それぞれの実装には、多かれ少なかれ独自の長所と短所があります。おそらく、ほとんどのSpring Cloudユーザーは、ネイティブ実装の制限を理解するのが難しいと感じています。サービスの検出、分散構成、サービスの呼び出しと回路の切断など、大規模な実装には適していません。たとえば、クラスターシナリオでは、Eurekaのパフォーマンスの問題も内部で発生します。したがって、Aliは、独自の超大規模クラスターエクスペリエンスを強力なSpring Cloudエコシステムと統合して、業界に前向きな化学変化をもたらすと考えられる強力な提携を実現します。
もう1つの影響は、これが中国のJavaerに利益をもたらす可能性があると考えていることです。現在、SpringCloudの最初の選択肢であるSpringCloud Netflixは中国では特に熟練しておらず、ドキュメントはすべて英語であり、問題が発生した後のトラブルシューティングは困難であることがわかりました。
Spring Cloud Alibabaは、国内のオープンソース製品のセットです。フォローアップでは、中国のリファレンスといくつかの主要な分析記事を提供します。これは、国内の開発者にとって非常に良いことです。
アリババの使命は「世界に困難なビジネスを持たせない」ことです。実際、アリババのジャワの多くは常に「中国のジャワに利益をもたらす」という1つの使命を持っていました。以前のDubboであろうとJava開発マニュアルであろうと、それらはすべて私たちの目的を反映しています。今、私たちはSpring Cloud Alibabaを取り出し、私たちの目的を実行し続けています。
もう1つの側面は、マイクロサービスアーキテクチャの分野です。マイクロサービスアーキテクチャの人気が高まるにつれ、この分野の知識の蓄えはますます重要かつ緊急になっています。SpringCloudAlibabaの登場は適切な時期であると言えます。マイクロサービスの分野では、Spring CloudAlibabaの登場もこのサークルで多くの化学反応を引き起こします。
オープンソース中国：
アリがそうするなら、マイクロサービスの分野にも深く関わっているダボとは何であるかを尋ねなければならない人もいます。少し前に、カムバックを応援しましたが、捨てましたか？
Ji Wang：
実際、多くの人は、DubboとSpring Cloudが代替であるか、あるいは反対であると誤解しています。ここでは、明確化に焦点を当てる必要があります。
前述のコンテンツに連絡すると、Spring Cloudは、Spring Cloud NetflixのRibbon、Feign、Eureka、およびHystrixコンポーネントと同等ではありません。代わりに、一連の一般的な開発モデルを抽象化します。その目的は、この一般的なモデルを抽象化することにより、開発者がビジネスをより迅速かつ適切に開発できるようにすることです。
ただし、この開発モデルランタイムの実際のキャリアは、RPC、ゲートウェイ、サービスディスカバリ、構成管理、電流制限ヒューズ、分散リンクトラッキングなどのコンポーネントの特定の実装に依存します。
DubboとSpringCloudは競合していません。成熟したRPCフレームワークとして、Dubboはその使いやすさ、拡張性、堅牢性で業界から認められています。将来的には、DubboはSpring Cloud AlibabaのRPCコンポーネントとして使用され、Spring CloudのネイティブFeignおよびRestTemplateとシームレスに統合されて、「ゼロ」コストの移行を実現します。
アリババのマイクロサービスソリューションでは、Dubbo、Nacos、Sentinel、および将来オープンソースとなるマイクロサービスコンポーネントはすべてDubboEcoSystemの一部です。また、DubboEcoSystemをSpringCloudエコシステムに統合します。
要約すると、Spring Cloudはマイクロサービスプログラミングの一般的なパターンを抽象化し、DubboEcoSystemはマイクロサービスのベストプラクティスです。
オープンソース中国：
マイクロサービスアーキテクチャは特に人気がありますが、実際にはいくつかの問題もあります。最近、マイクロサービスアーキテクチャが完成することを指摘し、「次世代のマイクロサービスアーキテクチャとしてのサービスメッシュ」の見方を否定し、Flinkのようなものだと述べた人もいます。ストリーミングアーキテクチャが新しい主流になります。Spring Cloudを介したAlibabaのマイクロサービスの追加Alibabaは、マイクロサービスアーキテクチャが間もなく終了するという見解におそらく同意しません。モノリシック、SOA、サーバーレス、その他のアーキテクチャとの類似性から、マイクロサービスアーキテクチャはどの段階で開発されたと思いますか？詳細を共有してください。記事の詳細については、https：//zhuanlan.zhihu.com/p/48036811を参照して
ください。
Ji Wang：
マイクロサービスは現在活発な開発段階にあると思います。サービスメッシュとサーバーレスは実際にはマイクロサービスアーキテクチャのカテゴリにあります。Service Meshは、マイクロサービスを提供するための多言語で依存関係のないソリューションです。サーバーレスは、開発、自動化された運用と保守、およびリソースの時間共有と多重化を簡素化してマイクロサービスを提供するためのソリューションです。
サービスメッシュとストリーミングプログラミングアーキテクチャはどちらも良い方向性であり、AlibabaGroupにはこれを行っている他のチームがあります。
しかし、私たちのチームの観点からは、これらは大規模な実稼働クラスターによってまだ検証されていないアーキテクチャであり、Spring CloudAlibabaに統合されたコンポーネントは長年のDouble11の後にAlibaba内でテストされています。
結局のところ、テクノロジーは依然としてビジネスに役立つ必要があるため、この一連のテクノロジーをSpring Cloudエコシステムに統合して、開発者がビジネスをより良く、より速く開発できるようにします。ビジネスは常に最も重要です。これが私たちの考えです。
その記事の観点に固有に、私はそれを次のように見ています：
- マイクロサービスはSOAの実装です
SOAはサービス指向のアーキテクチャであり、マイクロサービスもサービス指向のアーキテクチャの実装です。マイクロサービスの分野のパイオニアであるMartinFowlerを引用すると、「SOAをマイクロサービスのスーパーセットと見なす必要があります」。マイクロサービスはSOAの俊敏な実装です。ESBがIBMのSOAの不完全な実装になる前は、マイクロサービスの概念がMartin Fowlerによって作成される前は、AlibabaはDubboとHSFを使用して独自のマイクロサービスシステムを実装していました。実際、これはSOAの実装でもあります。
- マイクロサービスによって解決される本質的な問題は、分業です
SOAであろうとマイクロサービスであろうと、解決すべき根本的な問題は分業です。詳細については、コンウェイの法則を参照してください。これは大規模なソフトウェアの必然的な開発であり、人々の好みによって変わることはありません。コンウェイの法則を理解すると、「サービス分割の細かさを正確に把握することは難しい」ということは、本質的な問題ではないことがわかります。
2つのピザチームが複数ある場合は、それらをいくつかのマイクロサービスに分割するのが最善です。現実的な例を挙げると、開発者が1人だけの場合は、できるだけ1つのアプリケーションを作成するようにしてください。イライラするために10個のマイクロサービスに分割しないでください。最終的に、開発者は彼を1つに統合します。マイクロサービスには、垂直2ピザチーム（開発、テスト、運用、保守を含む無数の小さなチーム）が必要です。もちろん、従来の大企業もいくつか実装していますが、チームは依然として水平構造（開発、運用、保守、テスト）にあります。それぞれがチームです）、マイクロサービスを分割すると、特に運用および保守チームは非常に苦痛になります。
- マイクロサービスによってもたらされる課題は、分散条件下での開発、テスト、運用および保守の複雑さです。
特効薬はありませんが、歴史のトレンドを受け入れ、それに適応する必要があります。マイクロサービスの出現は、チームの分業の問題を解決すると同時に、新たな問題をもたらしますが、それは「大規模で複雑なインフラストラクチャ」ではありません。
EDASは実際にはすでにほとんどの「インフラストラクチャ」を提供しています。マイクロサービスは運転と同じです。車を作る必要はありませんが（インフラストラクチャ）、運転を学ぶこと（マイクロサービスの概念）は、単一のアプリケーションの開発、テスト、および運用における最大の課題です。例：単一のアプリケーション開発者は、失敗、再試行、および同一性のあるメソッド呼び出しについて考えることはありません。単一のアプリケーションテスターは、数十のアプリケーションを統合およびテストする方法について考えません。単一の運用および保守担当者は考えません。ダウンストリームアプリケーションが私に与える影響について考えます。分散条件下での開発、テスト、運用および保守の複雑さを認識し、これらの複雑な問題を解決する方法を習得することがより重要です。
- マイクロサービスは少なくとも18年間存続できます
もちろん、マイクロサービスに問題があるからといって死ぬとは言えません。多くの人がJavaはもうすぐ死ぬと言っています。2000年からこの議論を聞いています。18年経った今でもJavaは生き続けており、最近非常に人気があります。
マイクロサービスの終焉と言えば、ここにJavaへのリンクがあります。マイクロサービスは少なくとも18年は存続し、私の生涯の価値もあると思います。完全なインフラストラクチャ（車）を提供し、完全なベストプラクティスを提供します（コーチ）開発者がマイクロサービス（運転）のメリットを享受できるように支援します。
- 次世代アーキテクチャはサーバーレスです
Serverless =ここで説明するFaaS、Serverlessには、基盤となるミドルウェアのServerlessとサービス自体のServerlessが含まれ、FaaSはより単純な実装の1つにすぎません。その記事で言及されているFlinkとFaaSは実際には本質的に違いはありませんが、それらの商品化はFaaSよりもはるかに劣っています。
この記事の「ストリーミングアーキテクチャの利点」の各議論の具体的な分析は次のとおりです。
オリジナル：サーバー側の開発者は、システムパフォーマンスに注意を払う必要がなくなりました。Slinkクラスターはコンテナーを使用して動的に拡張でき、Slinkクラスターは特定のビジネスのノード数を動的に調整することもできます。
パフォーマンスは、開発者が注意を払う必要がある指標です。開発者は、ノードの拡張と縮小に注意を払う必要はありません。FaaSの方が優れている可能性があり、トラフィックがない場合はノードでさえも滞在できません。
オリジナル：サーバー側の開発者は、システムの信頼性に注意を払う必要がなくなりました。Slinkクラスターは、スケジューリング、再起動、状態管理など、各ノードを管理します。
FaaSノードの自動フェイルオーバー。
オリジナル：サーバー側の開発者は、システムが単一のビジネスの細かさに分割されているため、システムの分割を考慮する必要がなくなりました。ビジネスの開発と変更によってアーキテクチャが変更されることはなく、ビジネス処理フロー図を調整するだけで済みます。
理想は完全で、現実は非常に細いです。アリのチームがFaaSを試した後、すぐに戻ってきました。複雑なビジネスロジックは、ドラッグアンドドロップほど単純ではありません。理論的には、1つのアプリケーションのコードをドラッグアンドドロップするだけで、数え切れないほどの小さなメソッドに書き込むことができます。現在、銀行システムのごく一部がこのように実装されていますが、なぜ大規模に宣伝できないのでしょうか。これはビジネスの複雑さや変動性が原因であるため、FaaSも成功するのは困難です。FaaSのいわゆるメソッドレベルの分割は、基本的にマイクロサービスインターフェイスAPIの定義と同じです。いわゆるオーケストレーションは、現在、単純なビジネスロジックの制御にのみ適しています。
オリジナル：Slinkは複数の事業運営をサポートでき、リソースを最大限に共有できます。
FaaSは、Flink（Slink）では不可能な、非運用ロジックのロードと時分割多重化を防ぐことができます。
オリジナル：メッセージキュー、フルリンクトラッキング、構成センター、ダウングレードシステムなど、ほとんどのミドルウェアを削除でき、Slinkプラットフォームにこれらの機能を組み込むことができます。
AWS FaaSは下部にさまざまなサーバーレスサービスを提供してきましたが、Flinkは現在それらを提供していません。
オリジナル：運用と保守は基本的にSlinkプラットフォームを保守する必要があり、ビジネスは運用と保守を必要としません。
AWSFaaSはメンテナンスを必要としません。AWSがメンテナンスを支援します。
オリジナル：Slinkは複数の言語をサポートでき、サーバーが統合テクノロジースタックを開発する必要がなくなりました。
FaaSはどの言語でもかまいませんが、商品化されています。
実際、サーバーレスが解決する本質的な問題は次の側面です。
- 運用と保守の複雑さ
- 開発の複雑さ
- リソースの時間再利用
サーバーレスは開発とテストの複雑さを完全に解決するわけではありませんが、次世代のアーキテクチャになるには十分です。サーバーレス開発はマイクロサービスに基づいており、Java開発者は引き続きSpring Cloudを使用します。サーバーレスは、マイクロサービスの便利な補足と見なすことができます。
一方、どのようなアーキテクチャであっても、最終的にはクラウドコンピューティングがサーバー側のアーキテクチャ全体を支配すると思います。
クラウドコンピューティングがこの段階でIaaSレイヤーの問題を解決したことがわかります。今では、スタートアップが開始すると、キャビネットを借りるためのコンピュータールームを見つける従来の形式を選択するのではなく、クラウド上で直接マシンを購入することに慣れています。多くのトラブル、効率の大幅な向上、経済的コストの削減。
たとえば、上位レベルをデータベースレベルで見ると、人々はクラウドでRDSを購入することに慣れています。RDSバックエンドはサブデータベースとテーブルを自動的に処理するため、開発者はサブデータベースとテーブルを気にする必要はなく、データベースの操作と保守のために専門のDBAも必要ありません。そしてレベルの拡大、そして運用と保守を支援し、SLAを保証する専門のデータベース担当者がいて、使用量に応じて支払うだけで済みます。
ただし、PaaSレイヤーとSaaSレイヤーではうまくいきませんでした。近い将来、ミドルウェア機能をクラウドに直接エクスポートできるようになることを願っています。その時点で、マイクロサービス開発者は運用および保守サービスレジストリの展開方法を気にする必要がなくなりました。 、構成センター、メッセージキューサービスは、標準のプログラミングモデルをそのまま使用するだけで、開発効率を最大化し、ビジネスの変化と進歩を迅速に実現できます。
オープンソース中国：
開発者が一般的に心配しているオープンソースプロジェクトのフォローアップメンテナンスの計画は何ですか？
Ji Wang：
最初からSpring Cloudインキュベーターに入れることで、オープンソースに対する姿勢が示されました。コミュニティエコロジーは初期の段階ではAlibabaによって支配されていますが、より多くの人々がこのプロジェクトに参加し、より良い共同で構築することを歓迎します。大きな機能であれ、小さなバグであれ、ドキュメントの修正や改善であれ、このオープンソースプロジェクトに大いに役立つ可能性があります。
次に、オープンソースのDubbo、RocketMQ、ARMS、SchedulerX、SMS、VMS、SLS、およびその他のコンポーネントをAlibabaCloudに統合します。Aliがオープンソースの取り組みを強化し続けるにつれて、分散トランザクションを含む、より多くのオープンソースコンポーネントにもアクセスできるようになります。
Spring Cloud Alibabaは、来年2月に最初のGAバージョンをリリースし、Spring CloudHバージョンでインキュベーターを卒業します。
ゲスト
は、Alibabaミドルウェアのシニアテクニカルエキスパートであり、Microclass Networkの元CTOであり、保健省の検査システムの元チーフアーキテクトであるJi Wang（Peng Wenjie）を紹介しました。マイクロサービスの分野に焦点を当て、以前はEDAS製品開発TLを務め、現在はSpring CloudAlibabaオープンソースを担当しています。 。