HCIP 学習ノート - クラウド ネイティブ アプリケーション アーキテクチャ - 8

1. クラウドネイティブ アプリケーションとマイクロサービスの概要

1.1 アーキテクチャの進化

• アーキテクチャの進化と選択において、企業は迅速なビジネス開発と「美しい」アプリケーション アーキテクチャのどちらかを選択する必要があります。マイクロサービスは将来のトレンドであり、その特徴には耐障害性、迅速なオンライン機能、機能の複雑さの増加、高可用性が含まれます。 、要求への応答性、管理性、モジュールの独立したリリースなど。
• モノリシックアーキテクチャの特徴: すべての機能が 1 つのプロジェクトに集中されています。単一の構造がシンプルで、初期開発コストが低く、サイクルが短く、小規模プロジェクトの最初の選択肢です。しかし、すべての機能が 1 つのプロジェクトに集中しているため、プロジェクトが大きくなるにつれて、開発、拡張、保守が困難になります。
• モノリシックアーキテクチャの特徴：モノリシックアーキテクチャ規模のプロジェクトを基準にプロジェクトが縦割りに分割され、プロジェクトのアーキテクチャがシンプルで、初期開発コストが低く、サイクルが短く、小規模プロジェクトの第一選択肢です。垂直分割することで、元の単一プロジェクトが無限に拡張することはありません。
• SOA（Service-Oriented Architecture）の特徴：SOAアーキテクチャの考え方に基づき、繰り返し共通する機能をコンポーネントとして抽出し、サービスという形で各システムにサービスを提供します。さまざまなプロジェクト（システム）やサービスは、WebサービスやRPCなどを利用して通信を行っています。開発効率を向上させ、システムの再利用性と保守性を向上させることができます。クラスタリングと最適化スキームは、さまざまなサービスの特性に従って定式化できます。
• SOA アーキテクチャの欠点: システムとサービスの間の境界があいまいになるため、開発や保守には役立ちません。抽出されたサービスの粒度が大きすぎて、システムとサービスの結合度が高くなっています。
• マイクロサービス アーキテクチャの特徴: マイクロサービス アーキテクチャ スタイルの開発手法は、小さなサービスの集合を開発することで、独立したアプリケーション システムを開発します。これらの小規模なサービスはそれぞれ独自のプロセスで実行され、多くの場合、HTTP リソース API の軽量メカニズムを使用して相互に通信します。サービス分割の粒度が細かくなるため、リソースの再利用が容易になり、開発効率が向上します。サービスごとの最適化スキームをより正確に策定でき、システムの保守性が向上します。インターネット時代に適応すると、製品のイテレーションサイクルが短くなります。

1.2 モノリシックアーキテクチャ

• 複雑性が高い: 単体システムであるため、システム全体のモジュールが結合しており、モジュールの境界があいまいで、依存関係が複雑であるため、機能の調整により、未知の影響や潜在的なバグリスクが生じる可能性が高い。
• サービスのパフォーマンスの問題: モノリシック システムはパフォーマンスのボトルネックに遭遇するため、水平方向に拡張し、サービス インスタンスを増やし、負荷分散を実行して圧力を分散することしかできません。垂直方向に拡張することはできないため、モジュールに分割する必要があります。
• 拡張および縮小機能が制限されている: 1 つのアプリケーションは全体としてしか拡張できず、影響範囲が大きく、ビジネス モジュールのニーズに応じて個々のモジュールを拡張することができません。
• 障害切り分けができない：すべての業務機能モジュールが一つのアセンブリに集まっている場合、小さな機能モジュールに問題（リクエストブロックなど）があると、システム全体がクラッシュする可能性があり、影響範囲が比較的大きいです。 8がリリースされるたびにシステム全体がリリースされる リリースに伴うシステム全体の再起動は、大規模な総合システムにとっては比較的大きな課題である 各モジュールが分割されている場合、どの部分が変更され、どの部分だけが変更されるのかリリースされたモジュール。
• デプロイメントは徐々に遅くなり、コードが大きくなるにつれてビルドとデプロイにかかる時間も長くなります。
• それは技術革新とモノリシックなアプリケーションを妨げます。すべての問題を解決するために、統一された技術プラットフォームまたはソリューションがよく使用されます。チームのメンバー全員が同じ開発言語とアーキテクチャを使用する必要があります。新しいフレームワークまたは技術プラットフォームを導入することは非常に困難です。
• 名前が示すように、モノリシック アーキテクチャは、rar パッケージや iar パッケージなどのすべての機能アプリケーションを含むアーカイブ パッケージであり、比較的伝統的なアーキテクチャ スタイルです。ソフトウェア開発の初期には、展開が簡単で、単一のテクノロジがあり、人件費が低いため、基本的に誰もがこのアーキテクチャ モデルを採用しました。しかし、インターネット時代の到来により、ビジネス要件がますます複雑になり、配信頻度が継続的に加速することにより、従来のモノリシック アーキテクチャでは、次のような欠点があるため、開発者の要件を満たすことがますます困難になってきました。

1.3 SOA アーキテクチャ

• SOA 構造は、ソリューションを適用してモジュール化し、各機能を独立したユニットに構築してサービスを提供します。
• SOA アーキテクチャには複数のサービスがあり、サービスは相互依存性や通信メカニズムを通じて相互に通信し、最終的に一連の機能を提供することがわかります。通常、サービスはオペレーティング システム プロセスとは独立した形式で存在します。各サービスはネットワーク経由で呼び出されます。
• SOA は主に以下の問題を解決します
  • システム統合: システムの観点から、エンタープライズ システム間の通信問題を解決し、もともと分散していて計画外だったシステム間のネットワーク構造を規則的で管理可能なシステム間スター構造に整理します。このステップでは、多くの場合、いくつかの製品を導入する必要があります。 ESB、技術仕様、サービス管理仕様など。
  • システムのサービス化: 機能の観点から見ると、ビジネス ロジックは再利用可能で組み立て可能なサービスに抽象化され、サービス オーケストレーションを通じて迅速なビジネスの再生を実現します。目的: 本来の固有のビジネス機能を一般的なビジネス サービスに変換し、ビジネス ロジックの迅速な再利用を実現します。
  • ビジネスのサービス化: 企業の観点から、企業の機能を再利用可能で組み立て可能なサービスに抽象化し、元の機能的な企業構造をサービス指向の企業構造に変換し、企業の外部サービス機能をさらに強化します。最初のステップは、システム コールとシステム関数の再利用の問題を技術レベルから解決することです。

1.4 ESBエンタープライズサービスバス

• バスという用語は、コンピュータ内のさまざまなデバイス間でビットを転送する物理バスを指します。ESB は、より高い抽象レベルで同様の機能を提供します。ESB を使用したエンタープライズ アーキテクチャでは、アプリケーションはバスを介して対話し、バスはアプリケーション間の情報ディスパッチの役割を果たします。このアプローチの主な利点は、アプリケーション間の対話に必要なポイントツーポイント接続の数が削減されることです。一方、これにより、ソフトウェアの主要な変更の影響の分析がよりシンプルかつ直感的になります。アプリケーション システム内の接続ポイントの数を減らすことにより、システム内のコンポーネントを改造するプロセスが簡素化されます。
• エンタープライズ サービス バスは、信頼性の高いメッセージ送信、サービス アクセス、プロトコル変換、データ形式変換、コンテンツベースのルーティングなどの機能を提供し、サービスの物理的な場所、プロトコル、およびデータ形式を保護します。
• 将来のエンタープライズ統合アーキテクチャの進化は、エンタープライズ統合の境界を打ち破り、統合アプリケーション API、メッセージ、デバイス データ、クロスクラウドなどの複数のシナリオの統合を実現し、すべてのエンタープライズ アプリケーション、ビッグ データの接続を構築します。 9 つのクラウド サービス、デバイス、パートナー。IT チームが管理する従来の「インテグレーション ファクトリー」モデルは、事業部門、子会社、アプリケーション開発チーム、エンド ビジネス ユーザーがサポートするセルフサービス統合モデル、つまり「統合ハイブリッド統合プラットフォーム」と呼ばれるものに変わります。

1.5 マイクロサービスの概要

• マイクロサービスの起源は、2005 年の Cloud Computing Expo で Peter Rodgers 博士が提案した Micro-Web-Service から始まりました。Juval Lowy も彼と同様のアイデアを持ち、カテゴリをきめ細かいサービス (Granular Services) に変えました。 Unix パイプラインと同様のアクセス方法でサービスを利用できるようにするというもので、2014 年に Martin Fowler と James Lewis が共同でマイクロサービスの概念を提案し、マイクロサービスを単一のアプリケーションから構成される小規模なサービスとして定義し、独自のプロセスと軽量な処理を実現しました。 、サービスはビジネス機能に従って設計され、完全に自動で展開され、HTTP API を使用して他のサービスと通信します。同時に、このサービスは最小規模の集中管理 (Docker など) 機能を使用し、さまざまなプログラミング言語やデータベースなどのコンポーネントを使用してサービスを実装できます。
• マイクロサービスは、明確に定義された API を介して通信する小さな独立したサービスで構成されるソフトウェアを開発するためのアーキテクチャ的および組織的なアプローチです。
• マイクロサービス アーキテクチャの登場は、単一のアーキテクチャ (モノリシック) の小さな変更が他のモジュールに影響を与えるためです。特にクラウド上で公開する場合は、小さな変更をすべてコンパイルして均一にリリースする必要があります。特定のモジュールを拡張するには、全体の拡張も必要です。したがって、アプリケーションは一連のマイクロサービスを通じて構築され、各マイクロサービスは個別に展開、拡張でき、モジュール境界を提供し、さまざまな言語で開発することもできます。

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

• マイクロサービスの英語名は Microservice で、マイクロサービス アーキテクチャ パターンは、Web アプリケーション全体を一連の小さな Web サービスに編成することです。これらの小さな Web サービスは、独立してコンパイルおよびデプロイでき、公開された API インターフェイスを通じて相互に通信できます。これらは相互に連携して全体としての機能をユーザーに提供しますが、個別に拡張することもできます。
• マイクロサービス (Microservices) はソフトウェア アーキテクチャ スタイルであり、単一の責任と機能に焦点を当てた小さな機能ブロック (Small Building Blocks) に基づいており、モジュラー アプローチを使用して複雑な大規模アプリケーションを結合し、各機能領域のブロックが通信します。言語に依存しない一連の API を使用して相互に連携します。
• マイクロサービスはビジネス機能という設計概念を採用しており、アプリケーションを設計する際に、まずビジネス機能やプロセス設計ごとに分割し、各ビジネス機能を独立して実行できる個別のサービスとして実装し、同じプロトコルを使用することができます。アプリケーションに必要なすべてのサービスを組み合わせてアプリケーションを形成します。特定のビジネス機能を拡張する必要がある場合、ビジネス機能のサービスを拡張するだけでよく、アプリケーション プログラム全体を拡張する必要はありません。干渉、マイクロサービス管理者は、干渉に応じて、異なるコンピューティング リソースにマイクロサービスを構成できます。コンピューティング リソースのニーズ、または新しいコンピューティング リソースを展開して構成する
• API ゲートウェイは通常、各 API リクエストの実行パス上に配置され、データ プレーン センターに属し、クライアントからリクエストを受信し、基礎となる API へのリクエストをリバース プロキシします。そして、その前にトラフィック制御とユーザー ポリシーを適用します。
• リクエストを元のクライアントにプロキシする前に、基になる API の命令に応答して、対応する戦略を再度実行することもできます。RESTful API は REST スタイルの API であり、RESTFUL は Web アプリケーションの設計スタイルおよび開発手法であり、 XML 形式または JSON 形式で定義できます。

1.7 マイクロサービスの特徴

• 複雑さは、モノリシック アプリケーションを複数のサービス メソッドに分解することで解決されます。アプリケーションは、機能が変わらないという条件で管理可能な複数のブランチまたはサービスに分解され、各サービスは API を通じて定義されます。
• マイクロサービス アーキテクチャ パターンは、モノリシック コーディングでは実装が難しい機能に対するモジュール型のソリューションを提供するため、個々のサービスの開発、理解、保守が容易になります。
• マイクロサービスは独立して実装およびデプロイされる、つまり別のプロセスで実行されるため、独立して監視およびスケーリングできます。
• マイクロサービス アーキテクチャ パターンは、各マイクロサービスの独立したデプロイメントです。開発者は、このサービスに対する他のサービスのデプロイメントの影響を調整する必要がなくなりました。
• マイクロサービス アーキテクチャにより、各サービスを専任の開発チームが開発できるようになります。開発者は開発技術を自由に選択し、APIサービスを提供できます。

2. クラウド ネイティブ アプリケーションの主流のクレイジー ストリート

2.1 アーキテクチャ開発の進化の概要

• 初期の段階で 2 台以上のコンピュータが相互に通信する場合、その通信は、バイトコードと電子信号を送信できる基礎となる物理層によって完了する必要がありました。TCP プロトコルが登場する前は、サービスはパケット損失や障害を処理する必要がありました。 、リトライなどの問題が単独で発生するため、サービスはビジネス ロジックの処理に加えて、ネットワーク送信などの問題にも対処する必要があります。
• 1980 年代に TCP プロトコルが登場すると、ネットワーク伝送における一般的なフロー制御の問題が解決され、テクノロジー スタックが下位に移動され、サービスの実現から分離され、オペレーティング システムのネットワーク層の一部になりました。
• 1990年代、TCPの登場によりマシン間のネットワーク通信はもはや問題ではなくなり、GFS/BigTable/MapReduceに代表される分散システムが隆盛を極めました。このとき、サーキットブレーカー戦略、ロードバランシング、サービスディスカバリ、認証と認可、クォータ制限、監視など、分散システムの固有の通信セマンティクスが再び現れるため、サービスは必要な通信セマンティクスの一部を要件に従って実装します。ビジネス要件。
• 分散システム通信のための一連のセマンティック関数をサービスごとに実装する必要性を回避するために、Twitter の Finagle、Facebook の Proxygen、SpringCloud など、分散システム通信を実装するマイクロサービス アーキテクチャの開発フレームワークがいくつか登場し始めています。必要とされるさまざまな一般的なセマンティック機能。
• フレームワーク自体は分散システム通信の一部の一般的な機能実装の詳細を保護しますが、開発者は複雑なフレームワーク自体を習得して管理するためにより多くのエネルギーを費やす必要があり、フレームワーク内の問題を追跡して解決するのは簡単ではありません。 1 つまたはいくつかの特定の言語がサポートされているため、フレームワーク サポートのない言語でサービスが記述され、マイクロサービス指向のアーキテクチャ システムに統合することが困難です。プロジェクトの複雑な依存関係により、バージョンの互換性が非常に困難になり、フレームワークのアップグレードが困難になります。図書館はサービスを提供できません。そこで登場したのが、LinkerdやEnvoyに代表されるプロキシモード(サイドカーモード)であり、これがService Meshの第一世代となります。
• 第 1 世代の Service Mesh は、独立して実行される一連のスタンドアロン エージェント サービスで構成されています。統合された上位レベルの運用および保守の入口を提供するために、集中コントロール パネルが進化しました。すべてのスタンドアロン エージェント コンポーネントは、コントロール パネルを使用してネットワーク トポロジ戦略を更新し、スタンドアロン データ レポートを作成します。このモデルでは、各サービスに SideCar プロキシがあり、サービスは SideCar プロキシを介してのみ通信します。istioに代表される第2世代のService Meshです（IstioはGoogle、IBM、Lyftなどの企業が立ち上げています）。

2.2 Spring Cloud の概要

• Spring Cloud は、分散マイクロサービス システムを構築するための「ファミリー バケット」として知られており、特定のテクノロジーではなく、一連のマイクロサービス ソリューションまたはフレームワークを順序立てて集めたものです。市場で成熟し実績のあるマイクロサービス フレームワークを統合し、Spring Boot を通じて再パッケージ化して、複雑な構成と実装の原則を保護し、開発者にシンプルで理解しやすく、デプロイしやすく、使いやすい一連のサービスを提供します。 - フレームワークの維持 分散システム開発ツールキット。
• Spring Cloud のサブプロジェクトは大きく 2 つのカテゴリに分けられ、1 つは既存の成熟したフレームワーク「Spring Boot」のカプセル化と抽象化であり、プロジェクト数も最も多く、2 つ目はインフラストラクチャの実装です。 Spring Cloud Stream などの分散システムの一部は、kafka/ActiveMQ の役割を果たします。
• Spring Boot は、Pivo​​tal チームが提供する新しいフレームワークで、新しい Spring アプリケーションの初期構築と開発プロセスを簡素化するように設計されています。このフレームワークは構成に特定のアプローチを使用するため、開発者は定型的な構成を定義する必要がなくなりました。このようにして、Spring Boot は、急速なアプリケーション開発の急成長分野でリーダーになることを目指しています。
• Spring Cloudの特徴:
  • 強力な Spring コミュニティ、Netflix およびその他の企業のサポート、およびオープンソース コミュニティの貢献が非常に活発なため、成熟した製品とマイクロサービスのフレームワークの標準化された組み合わせである Spring Cloud は、低開発コストで、完全なマイクロサービス ソリューションのセットを提供します。リスクが低い
  • Spring Boot に基づいており、シンプルな構成、迅速な開発、簡単な展開、便利なテストという特徴があります。
  • RPC よりも軽量かつ柔軟な REST サービス呼び出しをサポートします (サービスは紙の契約にのみ依存し、コード レベルでの強い依存関係はありません)。これは、言語を超えたサービスの実現とリリースと展開に役立ちます。サービスの。
  • Docker および Kubernetes マイクロサービス オーケストレーション サポートを提供します

2.3 サービスメッシュの特徴

• Service Mesh (中国語翻訳サービス グリッド) の概念は、Buoyant によって最初に提案されました。2016 年に初めて公に使用されました。2017 年に、同社は最初のサービス メッシュ製品 Linkerd をリリースしました。同時に公開された記事「サービス メッシュとは何ですか? そしてなぜ必要ですか?」も業界で認知されています。 Service Mesh の信頼できる定義。
• サービス メッシュ層がない場合、ロジック管理の通信はサービスごとにコーディングできますが、通信が複雑になるにつれて、マイクロサービス間の通信はますます複雑になり、ロジック管理の通信はますます複雑になります。複雑なサービス グリッドを介して、多数の個別のサービスを統合できる時代が来ており、サービス グリッドは、複雑なサービス通信の問題を機能的なアプリケーションとして処理することに特化しています。
• Service Mesh とは何かを一文で説明すると、サービス間のネットワーク呼び出し、電流制限、融合、監視を担当する、アプリケーションまたはマイクロサービス間の TCP/IP にたとえることができます。一般に、アプリケーションを開発するときに TCP/IP 層を意識する必要はありません。また、Spring Cloud などの Service Mesh を使用する場合、サービス間のサービス フレームワークを通じて元々実装されているものを気にする必要はありません。 Netflix Oss およびその他のミドルウェアは、Service Mesh に引き渡す限り、可能です。
• サービス グリッドがないと、サービス間通信を管理するために各マイクロサービスを論理的にコーディングする必要があるため、ビジネス開発に集中できなくなります。また、サービス間通信を管理するロジックが各サービスに隠蔽されているため、通信障害の診断が困難になります。
• サービス メッシュは通常、アプリケーションを構成するマイクロサービスのネットワークとアプリケーション間の対話を記述するために使用されます。その要件には、サービス ディスカバリ、ロード バランシング、障害回復、インジケータの収集と監視が含まれます。また、一般に、Blue-Green リリース、カナリア リリース、トラフィック制限、アクセス コントロール、エンドツーエンド認証などのより複雑な運用とメンテナンスの要件が含まれます。

2.4 サービスメッシュアーキテクチャ

• 各アプリケーション マイクロサービス間の通信では、サービス ポイント A からポイント B に到達する方法を説明するルールを指定する必要があります。これらのルールは各サービスの論理管理層で定義され、サービス グリッドは各サービスの論理管理ルールを抽出します。サービス間通信をインフラストラクチャ層に抽象化すると、サービス メッシュによって各マイクロサービス ランタイム環境に新しい機能が追加されなくなります。各マイクロサービスが通信する際、リクエストはサービス グリッドのプロキシを介してマイクロサービス間でルーティングされます。サービス Web サイトを構成する各プロキシは、SideCar が各サービスと並行して実行され、各サービスから分離されているため、SideCar とも呼ばれます。独立して動作します。 、これらのsideCarプロキシはメッシュネットワークを形成します。サイドカー プロキシはマイクロサービスと並行して動作し、リクエストを他のプロキシにルーティングするために使用されます。
• SideCar は、アプリケーションの機能をアプリケーション自体から別のプロセスとして分離する設計パターンです。これにより、アプリケーションへの機能の非侵入的な追加が可能になり、サードパーティの要件を満たすためにコードを追加する必要がなくなります。ソフトウェア アーキテクチャでは、SideCar はメイン アプリケーション (親アプリケーションと呼ばれます) に接続されて機能を拡張および強化しますが、SideCar はメイン アプリケーションと疎結合されています。
• サービス メッシュでは、サービス インスタンスとそのサイドカー プロキシが呼び出され、データ プレーンを構成します。これには、データ管理だけでなく、リクエストの処理と応答も含まれます。サービス メッシュには、サイドカー プロキシによって調整されるサービス間の対話を管理するためのコントロール プレーンも含まれています。
• サービス グリッドのワークフロー: コントロール プレーンは、グリッド全体のサービス構成をすべてのノードの SideCar エージェントにプッシュします。ルーティング情報は、グローバルに、または特定のサービスに対して個別に動的に構成できます。SideCar が宛先アドレスを確認した後、w は対応するサービス検出エンドポイント (Kubernetes のサービス) にトラフィックを送信し、サービスはそのサービスをバックエンド インスタンスに転送します。SideCar は、最近のリクエストについて観察したレイテンシーに基づいて、すべてのアプリケーション インスタンスの中から最も応答の速いインスタンスを選択します。SideCar はこのインスタンスにリクエストを送信し、応答タイプと待機時間データを記録します。インスタンスがハングするか、プロセスが機能しない場合、SideCar はリクエストを別のインスタンスに送信して再試行します。インスタンスがエラーを返し続ける場合、SideCar は負荷分散プールからインスタンスを削除し、後で定期的に再試行します。リクエストの期限が過ぎた場合、SideCar は再度負荷を追加しようとするのではなく、リクエストを積極的に失敗させます。SideCar は、上記の動作のさまざまな側面を metrrc および分散トレースの形式でキャプチャし、集中メトリック システムに送信します。

2.5 サービスコム

• ServiceComb プロジェクトは、Huawei Microservice Engine (CSE) から生まれました。CSE は、これらのフレームワークの利点を活用および継承し、マイクロサービスが直面する問題を次の側面から解決することに重点を置いています。
  • マイクロサービスの通信パフォーマンス
  • マイクロサービスの運用とガバナンス。パフォーマンス監視、フロー制御、分離フォールトトレランス、グレーリリースなど
  • レガシーシステムの改修
  • 開発フレームワークを中心にDevOpsをサポートし、ライフサイクル全体にわたるDevOpsツールセットを完成させます。サービスインターフェースの互換性管理、受託テスト、開発パイプライン、統合運用保守などを含みます。
• ServiceComb は、2017 年 11 月に Huawei 社から Apache に寄贈され、インキュベーションを開始し、その後、Apache メンターの指導の下、インキュベーター管理委員会のメンバーがビジネス インキュベーションを実施しました。これは、Apache でインキュベートされ、トップで卒業した業界初のマイクロサービス プロジェクトでもあります。レベルのプロジェクト。

2.6 Istio の概要

• lstio は完全にオープンソースのサービス グリッドであり、既存の分散アプリケーションに透明な層として接続されており、ログ、テレメトリ、およびポリシー システムを統合できる API インターフェイスを備えたプラットフォームでもあります。Istio の多様な機能により、ユーザーは分散マイクロサービス アーキテクチャを適切かつ効率的に実行でき、マイクロサービスの保護、接続、監視に対する統一されたアプローチを提供できます。
• 初期の SideCar モードの ServiceMesh は、通信と通信リンク管理のすべての機能をプロキシ サービスに組み込み、あまりにも多くの機能を搭載しているため、データ プレーン プロキシの更新と変更が特に頻繁になり、プロキシ サービスに影響を与えます。安定。同時に、サービス メッシュ モードでは、データ プレーン プロキシがマイクロサービス通信のすべてのトラフィックを伝送します。これには、非常に高い安定性が必要です。上記の問題を解決するために、戦略と構成決定ロジックをプロキシ サービスから分離して、第 2 世代のサービス メッシュである独立したコントロール プレーンを形成します。
• lstio は、コントロール プレーンとデータ プレーンの 2 つの部分で構成されます。
  • データ プレーンは、サービス間の通信プレーンです。サービス メッシュがなければ、ネットワークはどのようなトラフィックが送信されているかを理解することができず、トラフィックの種類や送信元、送信元に基づいて意思決定を行うことができません。
  • コントロール プレーンは、サービスの必要な構成とビューを取得し、プロキシ サーバーを動的にプログラムして、ルールや状況の変化に応じて更新します。

3. HUAWEI CLOUD ネイティブ アプリケーション向けソリューション

3.1 アプリケーションサービスネットワークASM

• あらゆるアプリケーション形態をカバーし、コンテナ、従来のマイクロサービス、サードパーティサービスなど、さまざまなアプリケーションへのスムーズなアクセスと一元管理をサポートします。マルチクラウドおよびハイブリッド クラウドの複雑なシナリオをサポート さまざまなネットワーク条件下でのサービス クロスクラスタ トラフィックの混合管理、大規模グリッド、インテリジェントな運用とメンテナンス、インテリジェントな拡張と縮小を提供し、ユーザーがアプリケーション アクセスを自動的かつ透過的に管理できるようにします
• 高性能、低損失、軽量のマルチフォーム グリッド データ サーフェスは、ポッドごとおよびノー​​ド 2 ごとのオフロード フォームをサポートし、SideCar 転送効率を高速化します。構成の最適化とグリッド コントロール プレーン リソースの最適化のための柔軟なトポロジー学習。
• HUAWEI CLOUD ASM は、クラウドネイティブのアプリケーション管理、ネットワーク接続、セキュリティ管理などのアプリケーション ネットワーク ガバナンスの問題をうまく解決できます。
• HUAWEI CLOUD ASM 製品は、CCE クラウド コンテナ エンジンと緊密に統合されており、非侵入的な機能を提供します。インテリジェントなトラフィックガバナンスのアプリケーションライフサイクル管理ソリューションは、HUAWEI CLOUD Container Serviceのフルスタック機能を強化し、使いやすさ、信頼性、視覚化の点で一連の機能強化を行い、すぐに使えるエクスペリエンスを顧客に提供します。 。

3.1.1 ASM によって解決される主な問題

3.1.2 ASMサービス製品のアーキテクチャ

• ハイブリッド展開: 将来の仮想マシン アプリケーションとコンテナ アプリケーションのハイブリッド展開をサポートする統合ガバナンス
• 可観測性: Huawei Professional Cloud は、すぐに使用できるエンドツーエンドのインテリジェントなグローバル監視、ログ、トポロジ、コール チェーンを提供します。
• マルチクラウド ハイブリッド クラウド シーンのグローバル統合サービス ガバナンスは、複数のインフラストラクチャ (マルチコンテナ クラスタ/コンテナ - 仮想マシン/仮想マシン - 物理マシン)、グレースケール、トポロジ、およびクラスタ間のコール チェーンの統合サービス ガバナンスをサポートします。
• プロトコル拡張: SpringCloud マイクロサービス SDK との組み合わせソリューションを提供します。
• コミュニティとオープンソース: lstio コミュニティは、コミュニティへの貢献の点で世界 3 位にランクされており、コミュニティ バージョンの問題やニーズを迅速に解決します。大規模な顧客は、バージョンを迅速にリリースし、コミュニティと互換性のあるコミュニティ バックボーンについて言及する必要があります。

3.1.3 ASMに基づくグレースケールリリース

• サポートされているグレースケール公開戦略:
  • リクエスト内容に基づくグレースケールルール: リクエスト内容に基づくグレースケールルールをサポートし、ヘッダーやクッキーなどのさまざまなリクエスト情報を設定できます。
  • トラフィック比率に基づくグレースケール ルール: トラフィック比率に基づくグレースケール ルールをサポートし、重み比率に従ってトラフィックを分散します。
  • カナリア グレースケール プロセス: グレースケール バージョンの起動、グレースケール バージョンの動作の観察、グレースケール ルールの構成、アクセス条件の観察、トラフィックのセグメント化など、カナリア グレースケール プロセスをユーザーにガイドするウィザードを提供します。
  • ブルー グリーン グレースケール プロセス: グレースケール バージョンのオンライン観察、グレースケール バージョンの操作観察、アクセス ステータス、バージョンの切り替えなど、ブルー グリーン グレースケール プロセスを完了するためのユーザーをガイドするウィザードを提供します。

3.1.4 施設の検出とマルチクラスター管理

• O&M フリーのホスティング コントロール プレーンを提供し、マルチクラウドおよびマルチクラスターのグローバルな統合サービス ガバナンス、グレースケール、セキュリティ、サービス運用監視機能を提供し、コンテナや VM などの複数のインフラストラクチャの統合サービス検出と管理をサポートします。
• 複数のクラスターのグリッド共有? ルート証明書を設定し、キーと証明書のペアをデータ プレーン上のサービス インスタンスに配布し、キー証明書を定期的に交換し、必要に応じてキー証明書を取り消します。サービス間でアクセスするときは、グリッド データがサーフェス プロキシとして機能します。ローカル サービスと双方向認証およびチャネル暗号化のピア用の双方向認証サービス パーティは、クラスタ間で透過的なエンドツーエンドの双方向認証を実現するために、2 つの異なるクラスタから来ることができます。
• サービス構成ロード・バランシング、サービス・ルーティング、フォールト・インジェクション、ヒューズ・フォールト・トレランス、およびアプリケーション・トポロジに基づくその他のガバナンス・ルールをサポートし、ワンストップ・ガバナンス・システムと組み合わせて、リアルタイムの視覚化されたマイクロサービス・トラフィック管理、非侵入型インテリジェント・トラフィックを提供します。ガバナンスにより、アプリケーションを変更する必要がなく、動的なインテリジェント ルーティングと柔軟なトラフィック管理を実行できます。
  • アプリケーションの柔軟なグレースケール公開を実現するための重み、コンテンツ、TCP/IP などのルーティング ルール
  • ビジネス処理の継続的な要求を満たすための HTTP セッションの維持
  • 電流制限とヒューズにより、サービス間の安定した信頼性の高いリンクを実現します。
  • ネットワーク永続接続管理によりリソースの損失が軽減され、ネットワークのスループットが向上します。
  • サービスセキュリティ認証：サービスセキュリティ保証の基礎となる認証、認証、監査など

3.1.5 統合制御およびガバナンス戦略、リアルタイムのトラフィック監視

• アプリケーション トポロジに基づくサービスのロード バランシング、サービス ルーティング、フォールト インジェクション、フォールト トレランスなどのガバナンス ルールをサポートし、ワンストップ ガバナンス システムと組み合わせて、リアルタイムで視覚化されたマイクロサービス トラフィック管理、非侵入型インテリジェント トラフィック ガバナンスを提供します。変換後、動的インテリジェント ルーティングと柔軟なトラフィック管理を実行できます。また、アプリケーションは何も必要としません。
  • アプリケーションの柔軟なグレースケール リリースを実現するための、重み、コンテンツ、TCP/IP などのルーティング ルール。
  • ビジネス処理の継続的な要求を満たすための HTTP セッションの維持
  • 電流制限とヒューズにより、サービス間の安定した信頼性の高いリンクを実現します。
  • ネットワーク永続接続管理によりリソースの損失が軽減され、ネットワークのスループットが向上します。
  • サービスセキュリティ認証：サービスセキュリティ保証の基礎となる認証、認証、監査など
• リクエスト内容/ブラウザ/OSに応じた配信に対応
• トラフィック比率に基づいたサポート分散

3.1.6 トラフィックガバナンス

• アプリケーション サービス グリッド ASM は現在、再試行、タイムアウト、接続プール、サーキット ブレーカー、ロード バランシング、HTTP ヘッダー フィールド、フォールト インジェクションなどのトラフィック管理機能をサポートしており、ほとんどのビジネス シナリオの管理ニーズを満たすことができます。
• トラフィック管理:
  • ウェイト、コンテンツ、TCP/IP などのルーティング ルールをサポートし、アプリケーションの柔軟なグレースケール パブリッシュを実現します。
  • ビジネス処理の継続的な要求を満たすために、HTTP セッションの永続性をサポートします。
  • 電流制限とヒューズをサポートし、サービス間の安定した信頼性の高いリンクを実現します。
  • ネットワーク長時間接続管理をサポートして、リソースの損失を軽減し、ネットワークのスループットを向上させます。
  • サービスセキュリティ認証のサポート：認証、認証、監査など、サービスセキュリティ保証の基礎を提供します

3.1.7 適用可能なシナリオ

• コンテナ化されたインフラストラクチャを運用すると、新たな課題が生じます。コンテナを強化し、API エンドポイントのパフォーマンスを評価し、インフラストラクチャの有害な部分を特定する必要があります。lstio サービス メッシュを使用すると、コードの変更やサービスの遅延を発生させずに API を拡張できます。
• 通常、製品最適化の反復的な方法は、特定のバージョンをオンラインですべてのユーザーに直接リリースすることですが、オンラインでの事故 (またはバグ) が発生すると、ユーザーに大きな影響を与え、問題解決のサイクルが長くなります。あるバージョンはユーザー エクスペリエンスに重大な影響を及ぼしました。グレースケール リリースは、バージョン アップグレードをスムーズに移行する方法です。バージョンがアップグレードされると、一部のユーザーは上位バージョンを使用し、他のユーザーは引き続き下位バージョンを使用します。上位バージョンが安定した後、徐々に範囲を拡大して移行します。すべてのユーザー トラフィックを上位バージョンに移行します。

3.2 アプリケーションミドルウェアの紹介

3.2.1 分散型メッセージサービス

• 主な特徴：
  • 使いやすさ: すぐに使用できる、視覚的な操作、オンデマンドのセルフサービス作成、自動デプロイメント、数分でのインスタンス作成、即時使用、メッセージ インスタンスのリアルタイム表示と管理。
  • 安定性と信頼性、安心の運用とメンテナンス: クロス AZ 展開をサポートし、オープンソースの可用性の問題 (Kafka スプリットブレイン マルチコントローラーなど) を解決し、障害発生時のアラームと切り替えを自動的に検出し、ユーザーの信頼性の高い操作を保証します。 ' 主要事業
  • 実践検証: Huawei VMALL double 11 およびその他の大規模テストは、世界中の顧客のクラウド ビジネス システムに広く導入および実行されており、コミュニティの主流に密接に準拠しており、このサービスはクラウドに対する顧客の完全な信頼を獲得しています。

3.2.1.1 分散メッセージサービス Kafka

• Zookeeper: Kafka メタデータを保存する分散調整アプリケーション
• クライアント：
  • プロデューサー (Producen2o2) は、トピックにメッセージをパブリッシュし、複数のトピックにメッセージを継続的に送信できるクライアント アプリケーションです。
  • Consumer ( Consumer ): これらのトピックをサブスクライブするクライアントは、同時に複数のトピックをサブスクライブできます。
• サーバー: ブローカーと呼ばれるサービス プロセスで構成され、Kafka クラスターは複数のブローカーで構成されます。
• Kafka: 分散メッセージ ストリーム処理ミドルウェア
• ブローカー: クライアントから送信されたリクエストの受信と処理、およびメッセージの保持を担当します。
• トピック: Kafka でのパブリッシュとサブスクライブの対象となる、ビジネスごと、アプリケーションごと、さらにはデータの種類ごとに専用のトピックを作成できます。
• トピックはパーティションごとに保存されます。
• Kafka の高可用性メカニズム:
  • ブローカーは異なるマシン上で実行され、1 つのブローカーに障害が発生した場合でも、他のブローカーが外部サービスを提供できます。
  • バックアップ機構 (レプリケーション) は、同じデータをコピーとして複数のマシンにコピーします。

3.2.1.2 分散メッセージサービス RabbitMQ

• すぐに使える: 分散メッセージ サービスの RabbitMQ バージョンは、豊富なメモリ仕様を備えたスタンドアロン メッセージ インスタンスとクラスター メッセージ インスタンスを提供し、サーバー リソースを別途準備することなく、コンソールから直接購入および作成できます。
• 豊富なメッセージ機能: AMOP プロトコルのサポート、共通メッセージ、ブロードキャスト メッセージ、配信不能メッセージ、遅延メッセージおよびその他の機能のサポート
• 柔軟なルーティング: RabbitMQ では、プロデューサーがメッセージを交換機に送信し、交換機がメッセージをキューにルーティングします。このスイッチは、ダイレクト、トピック、ヘッダー、ファンアウトの 4 つのルーティング方法をサポートしており、スイッチの組み合わせとカスタマイズもサポートしています。
• 高可用性: RabbitMQ クラスターは、ミラーリングを通じて他のノード上のデータを同期できるミラー キューを提供し、単一ノードがダウンしても、データを損失することなく、一意のアクセス アドレスを通じてサービスを外部に提供できます。
• 監視とアラーム: RabbitMQ インスタンスのステータスの監視をサポートし、クラスター内の各エージェントのメモリ、CPU、ネットワーク トラフィックなどの監視をサポートします。クラスターまたはノードのステータスが異常な場合、アラームがトリガーされます。
• AMQP (Advanced Message Queuing Protocol) は、ユニファイド メッセージング サービスを提供するアプリケーション層標準の高度なメッセージ キューイング プロトコルです。アプリケーション層プロトコルのオープン標準であり、メッセージ指向ミドルウェア向けに設計されています。このプロトコルに基づくクライアントおよびメッセージミドルウェアはメッセージを転送することができ、クライアント/ミドルウェアの製品の違いや企業の開発言語などの条件に制限されません。

3.2.1.3 分散メッセージ サービス RocketMQ

• サポートされているメッセージの種類
  • 通常のメッセージ: 遅延メッセージ、逐次メッセージ、トランザクション メッセージとは異なり、特別な機能を持たないメッセージ 1
  • 遅延メッセージ/タイミング メッセージ: プロデューサが RocketMO バージョンへのメッセージを生成した後、メッセージはすぐには消費されませんが、消費のためにコンシューマに送信される前に、一定の時間まで遅延されます。
  • 連続メッセージ: コンシューマは送信された順序でメッセージを消費します。
  • トランザクションメッセージ：X/Open XAと同様の分散トランザクション機能を提供し、トランザクションメッセージを通じて分散トランザクションの最終整合性を実現できます。
• プロデューサー: メッセージ プロデューサーは、メッセージを配信するプログラムです。
• コンシューマ: メッセージ コンシューマは、メッセージを受信するプログラムです。
• Namesrv: トピック ルーティング情報の保存 クライアントは、作成および使用するトピック ルーティング情報を取得するには、namesrv にアクセスする必要があります。
• マスター: クライアントの生産および消費リクエストを受け取ります。
• スレーブ: レプリカ ノードに相当し、マスターから複製されたデータを受信します。
• Raft コンセンサス アルゴリズムはマスターとスレーブの間で使用され、データの一貫性と、マスターとスレーブの同じグループ間の自動フェイルオーバーを保証します。
• ブローカー: クライアントから送信されたリクエストの受信と処理、およびメッセージの永続化を担当します。ブローカー内の 3 つのノードは相互にアクティブおよびスタンバイになります。

3.2.1.4 分散メッセージサービスの機能の比較

• 備考: Firehose または Rabbitmq_tracing プラグインを RabbitMQ で使用して永続性を実現できますが、rabbitmq_tracing プラグインを有効にするとパフォーマンスに影響するため、問題を特定するプロセスでのみ有効にすることをお勧めします。
• Kafka と RabbitMQ の性能差: メッセージミドルウェアの性能は主にスループットを測定します Kafka のスループットは RabbitMQ より 1 ～ 2 桁高くなります RabbitMQ のスタンドアロン QPS は 10,000 レベルであり、Kafka のスタンド-QPS だけで 100 万レベルに達する可能性があります。Kafka が冪等性やトランザクションなどの機能を有効にすると、パフォーマンスも低下します。

3.2.1.5 ケース: Kafka を使用したリアルタイム トランザクション分析プラットフォームの構築

3.2.2 マイクロサービス エンジン CSE

• マイクロサービス アーキテクチャ パターンには通常、次の内容が含まれます: マイクロサービス間の RPC 通信、分散マイクロサービス インスタンスとサービス検出、外部および動的な構成、集中構成管理、複数の提供 (融合、分離、電流制限、負荷分散など) マイクロサービス ガバナンス機能、分散トランザクション管理機能、コール チェーン、集中ログの収集と取得。
• マイクロサービス アーキテクチャ パターンには通常、次のものが含まれます。
  • マイクロサービス間の RPC 通信。マイクロサービス アーキテクチャ パターンでは、マイクロサービスが共有メモリやパイプラインなどの他の従来の通信方法ではなく、RPC を介して通信する必要があります。一般的な RPC 通信プロトコルには、REST、gRPC などが含まれます。RPC 通信を使用すると、マイクロサービス間の結合が軽減され、システムのオープン性が向上し、テクノロジ選択の制限が軽減されます。
  • 分散マイクロサービス インスタンスとサービス ディスカバリ。マイクロサービス アーキテクチャは特にアーキテクチャの柔軟性を重視しており、マイクロサービスの設計は一般にステートレス設計原則に従っており、この原則に準拠したマイクロサービス拡張インスタンスは処理パフォーマンスの直線的な向上をもたらします。インスタンスの数が多い場合、マイクロサービス間の呼び出しアドレス指定には、サービスの登録と検出をサポートするミドルウェアが必要になります。
  • 外部の動的な集中構成管理を構成します。マイクロサービスとインスタンスの数が増加するにつれて、マイクロサービスの構成管理はますます複雑になります。構成管理ミドルウェアは、すべてのマイクロサービスに対して統合された構成管理ビューを提供し、構成管理の複雑さを効果的に軽減します。マイクロサービス アーキテクチャにはいくつかの一般的な障害モードがあり、ガバナンスによりビジネス全体に対する障害の影響を軽減できます。
  • 分散トランザクション管理機能。一般的な分散トランザクション処理モードには、Saga、TCC、非侵入型などが含まれます。分散トランザクション管理により、分散トランザクションの一貫性の問題に対処する難しさを軽減できます。
  • コールチェーン、一元化されたログの収集と取得。ログの表示は依然としてシステム障害を分析する最も一般的な手段であり、コール チェーン情報は障害を定義し、パフォーマンスのボトルネックを分析するのに役立ちます。

3.2.3 適用可能なシナリオ

• 開発環境を計画する目的は、開発者が効率よく並行して作業できるようにし、依存関係を減らし、環境設定の作業負荷を軽減し、実稼働環境でオンラインになるリスクを軽減することです。
  • イントラネット上にローカル開発環境を構築します。ローカル開発環境のメリットは、各企業・開発者が自社のニーズに合わせた最小限の機能まとめ環境を構築できることで、ログの閲覧やコードのデバッグに便利です。ローカル開発環境により、コード開発効率が大幅に向上し、展開とデバッグの時間が短縮されます。ローカル開発環境の欠点は、統合レベルが高くなく、統合や共同デバッグが必要な場合に安定した環境を確保することが難しいことです。
  • クラウド上のテスト環境は比較的安定した統合テスト環境です。ローカルでの開発とテストが完了したら、各企業はこの分野のサービスをクラウドのテスト環境にデプロイし、他の分野のサービスを呼び出して統合テストを行うことができます。ビジネス規模の複雑さに応じて、
  • クラウド上のテスト環境はさらに、（アルファ）テスト環境（Baita）テスト環境、（ウェイト）テスト環境などに分類できます。これらのテスト環境の統合度は、低いものから高いものまであります。一般（ウェイト）テスト環境では、安定した環境を確保するために実稼働環境と同じ管理が必要です。
  • 実稼働環境は正式なビジネス環境です。実稼働環境は、グレースケール アップグレード機能をサポートし、オンラインでの共同デバッグと排水をサポートし、アップグレードの失敗によるサービスへの影響が最小限に抑えられるようにする必要があります。
  • クラウド上のテスト環境では、CSE とミドルウェアのパブリック ネットワーク IP をオープンしたり、ネットワークの相互運用性を実現したりできるため、クラウド上のミドルウェアをローカル環境の代わりに使用でき、各開発者が自分で環境をインストールする時間を短縮できます。 。この状況はイントラネットのローカル開発環境にも属し、マイクロサービスはローカル開発環境のマシン上で実行されます。クラウド上のコンテナーにデプロイされたマイクロサービスと、ローカルの開発環境マシンにデプロイされたマイクロサービスは、相互にアクセスできません。競合を避けるため、クラウド上のテスト環境はローカル開発環境としてのみ使用されます。

3.2.4 ケース: ファーウェイ コンシューマー クラウド サービス マイクロサービス ベース

• マイクロサービスとコンポーネント化は、大規模な共同開発のための技術的基盤を提供し、内部共有機能のための統一されたフレームワークを提供します。2021 年の初めまでに、アプリケーション市場は 300 を超えるマイクロサービスを開発し、ライブ ネットワーク上に 10,000 を超えるインスタンスをデプロイしました。クライアントは 500 を超えるさまざまな動的レイアウト カードを開発し、100 を超えるコンポーネントがコンポーネント化によって分割されました。
• AppGallery Connect: あらゆる端末とシナリオをカバーするモバイル アプリケーション ライフサイクル サービスを開発者に提供し、開発コストを削減し、運用効率を向上させ、ビジネスの成功を支援します。

3.2.5 APIゲートウェイ

• API プロバイダーとして、成熟したビジネス機能 (サービス、データなど) をバックエンド サービスとして使用し、API ゲートウェイで API を開き、オフラインで API 呼び出し元に提供したり、API マーケットに公開したりできます。ビジネスを実現する 実現する能力。
• API 呼び出し側は、API プロバイダーが API ゲートウェイ上で公開した API を取得して呼び出すことができるため、開発時間とコストが削減されます。
• API Gateway は、ユーザーが企業の R&D 投資を削減しながらサービス機能を実現できるように支援し、ユーザーが企業のコア ビジネスに集中できるようにし、運用効率を向上させます。たとえば、企業 A は、電話番号アトリビューション クエリ API を API ゲートウェイで公開し、API マーケットに公開します。企業Ｂは、ＡＰＩマーケットを通じてこのＡＰＩを呼び出し、このＡＰＩの呼び出しによって発生した料金を支払う。このとき、企業Aは自社のビジネス機能を公開することで自社のサービス機能を収益化し、企業Bは企業Aが公開したAPIを直接呼び出すことで開発時間とコストを削減し、最終的には企業間のWin-Winの関係が実現します。

3.2.6 適用シナリオ：APIフルプロセス研究開発システムの高効率制御

• Swagger は、RESTful スタイルの Web サービスを生成、記述、呼び出し、視覚化するための標準化された完全なフレームワークです。Swagger の目標は、REST API への言語に依存しない標準のインターフェイスを定義し、人やコンピュータがソース コード、ドキュメント、またはネットワーク トラフィックの監視にアクセスせずにサービスを発見して理解できるようにすることです。

3.3 ソフトウェア開発プラットフォーム DevCloud

• ソフトウェア開発プラットフォームは、次の主要なサービスで構成されます。
  • プロジェクト管理: ソフトウェア開発チームは、アジャイルなプロジェクト管理とコラボレーションを提供し、マルチプロジェクト管理、アジャイルな反復管理、マイルストーン管理、要件管理、欠陥追跡、多次元統計レポートなどのサポート機能を提供します。
  • コード ホスティング: ソフトウェア開発者向けの Git ベースのオンライン コード ホスティング サービスで、セキュリティ管理メンバー/権限管理、ブランチ保護/マージ、オンライン編集、統計サービスなどの機能を備えたクラウド コード ウェアハウスです。
  • パイプライン: 視覚的でカスタマイズ可能な配信パイプラインを提供して、配信サイクルを短縮し、配信効率を向上させます。
  • コードインスペクション：クラウド上でコードの品質管理を実現し、ソフトウェア開発者はコーディング完了後に多言語コードの静的検査やセキュリティ検査を実施し、不具合群の閲覧や改善提案を行うことができます。
  • コンパイルと構築: 開発者は、クラウドベースのコンパイルと構築を実現するためのシンプルな構成の混合言語構築プラットフォームを提供し、企業の継続的デリバリーの実現をサポートし、配信効率を向上させます。ワンクリックでのコンパイルおよび構築タスクの作成、構成、実行をサポートし、コードの取得、構築、パッケージ化などのアクティビティの自動化を実現し、構築状況をリアルタイムで監視します。
  • デプロイメント: ビジュアルかつワンクリックのデプロイメントサービスを提供し、仮想マシンまたはコンテナへのデプロイメントをサポートし、Tomcat や SpringBoot などのテンプレートを提供し、またはデプロイメントのためのアトミックなステップを自由に組み立てて配置し、並列デプロイメントとパイプラインのシームレスな統合をサポートし、デプロイメント環境を実現します。標準化と導入プロセスの自動化。
  • クラウド テスト: ソフトウェア開発者にワンストップのクラウド テスト プラットフォームを提供し、機能テストとインターフェイス テストをカバーし、DevOps アジャイル テストの概念を統合して効率的な管理テストを実現し、製品の品質を確保します。
  • リリース: ソフトウェア開発チームにソフトウェア リリース プロセスを管理する機能を提供し、ソフトウェア リリース プロセスの標準化、視覚化、追跡可能性を確保します。
  • CloudIDE: クラウド開発環境。開発者にオンデマンドで開発環境を提供し、環境構成の作成、構築、実行、デバッグなどの操作をサポートし、さまざまなコード ウェアハウスとのドッキングをサポートします。
  • オープンソース ミラー サイト: HUAWEI CLOUD が提供するオープンソース コンポーネント、オープンソース オペレーティング システム、およびオープンソース DevOps ツールのミラー サイトは、包括的、高速、信頼性の高いオープンソース コンポーネント/OS/ツールのダウンロードをユーザーに提供することに尽力しています。サービス。

3.3.1 アプリケーションのライフサイクル管理

• プロセス全体: 1 つのプラットフォームで、ソフトウェア開発の共通機能、ソフトウェア開発のさまざまな機能の組み込み統合、ドッキング管理、運用および保守をカバーします。
• 豊富なプログラミング言語とテクノロジー スタックがサポートされています: 20 を超える主流のプログラミング言語がサポートされています: 開発フレームワークとオペレーティング環境、アプリケーションはクラウドにシームレスに移行されます。
• 安全性と信頼性: 安全性テスト、信頼できる構造、高い安全基準、7000 以上のコード検査ルール

3.3.2 CI/CD全体プロセスの実現

• 初期のウォーターフォール モデルからその後のアジャイル開発、そして今日の DevOps に至るまで、これは現代の開発者が優れた製品を構築するための技術的なルートです。DevOps の台頭により、継続的インテグレーション、継続的デリバリー (CI/CD)、継続的デプロイメントに対する新しいアプローチが登場しましたが、従来のソフトウェア開発とデリバリーの方法は急速に時代遅れになりつつあります。過去のアジャイル時代には、ほとんどの企業のソフトウェア リリース サイクルは月次、四半期、さらには年に一度でしたが、現在の DevOps 時代では、毎週、毎日、さらには 1 日に複数回が標準となっています。これは、SaaS が業界で主流になり、ユーザーに更新されたコンポーネントのダウンロードを強制することなく、アプリケーションを動的に更新することが容易になるにつれて特に当てはまります。多くの場合、ユーザーは変化が起こっていることにさえ気づきません。
• 継続的インテグレーションは、通常は 1 日に数回、さまざまな開発者の作業をコード ウェアハウスに統合することに重点を置いています。主な目的は、チームがより緊密に統合され、より適切に連携できるように、統合エラーをできるだけ早く発見することです。継続的デリバリーの目的は、デプロイメントまたはリリースのプロセス中にチームに内在する摩擦を最小限に抑えることであり、その実装では通常、ビルドのデプロイメントのすべてのステップを自動化できるため、いつでもコードのリリースを安全に完了できます（理想的には）。 ）。継続的デプロイメントは、より高いレベルの自動化です。 358 主要なコード変更があるたびに、自動的にビルド/デプロイします。

3.3.3 プロジェクト管理サービス

• プロジェクトは、特定のプロセスを通じて調整および制御された一連の活動で構成され、プロジェクトの目標は特定のニーズを満たすことであり、時間、コスト、リソースの制約を受けます。プロジェクトマネジメントは、プロジェクトのプロセスと結果を管理することで、プロジェクトの設定された目標を達成します。カンバン プロジェクトは、ユニークなタイプのプロジェクトです。カンバンはプロジェクトに依存します。カンバン プロジェクトは、カンバンを通じて作業項目レベル、作業項目タイプ、および作業項目を視覚的に表示します。
• プロフェッショナルなアジャイル プロジェクト管理: Jigong アジャイル プロジェクト コレクション管理、単一プロジェクト スクラム、リーン カンバン。プロフェッショナルな製品計画: ガント チャート、マインド マップ、製品パノラマ計画。
• 多次元のプロフェッショナル レポート: マルチプロジェクト管理カンバン、ダッシュボード、レポート
• R&D ナレッジマネジメント: 構造化された知識、促進されるイノベーション。
• 信頼できる監査ログ: 1000 以上の監査イベント、包括的なトレーサビリティ、安全で信頼性の高い。
• 典型的な該当するシナリオ
  • 製品、開発、テストの共同作業
  • 需要管理
  • プロジェクトの健全性 (スケジュール、品質、リスク、人材) 管理
  • 欠陥管理

3.3.4 コードホスティングサービス

• アクセス セキュリティ制御: ブランチ保護や IP ホワイトリストなどの認証ツールを提供し、特定の権限と特定の IP を持つアカウントのみがコード ウェアハウスにアクセスできるようにします。
• リモートバックアップのサポート: 承認されたユーザーがワンクリックでウェアハウスをHUAWEI CLOUDの他の領域、他の物理ホスト、クラウドホストにバックアップできるようにサポートします。
• リポジトリのロック: 今後の安定版リリースの破損を防ぐために、変更やコミットが行われないようにリポジトリを手動でロックできます。
• SSH デプロイメント キー: SSH キーを使用してウェアハウスの読み取りおよび書き込み権限を制御し、デプロイメント キーを使用してウェアハウスの読み取り専用権限を開きます 誤操作のトレーサビリティとリカバリ: 誤操作によるコード、ブランチなどの場合削除された場合は、正確なロールバックまたは取得を実行できます。削除されたリポジトリについては、物理ストレージに保存期間のバックアップがあります。
• 操作ログ: すべての操作にはトークンがあり、主要な操作が監査および記録されます。監査ログは永続的であり、正確な 5W1H バックトラッキングを実行するのに十分な期間保持できます。
• ルール設定: サブミットルール設定、マージレビューとアクセス制御設定などを提供し、コード品質を高度に制御できます。
• 通知設定: ウェアハウス内で重要な変更が発生した場合、電子メールやテキスト メッセージなどの通知を事前に設定された役割に送信できます。

3.3.5 コード検査サービスと編集・構築

• 独立した研究開発:
  • 構文ツリーと CFG クロスプロセス検査に基づいた自社開発のコード検査エンジン。C、C++、Java、
  • PythonやGoを含む10言語でのコードインスペクション
• ファーウェイの30年間の研究開発経験に基づいて設定された高品質のコード検査ルール:
  • 3000以上のコードインスペクションルール、プログラミングスタイル/コーディングセキュリティ/メモリ管理/入力検証/安全でない関数/スレッド同期、コード反復率など 20以上のコードインスペクションルールシナリオ
  • CWE/OWASP TOP 10/SANS TOP 25/MISRA/CERT などの 5 つ以上のセキュリティ コーディング標準と互換性があります。
• 自動化された欠陥修正支援:
  • インテリジェントな修復提案を提供します。コード静的検査欠陥インテリジェント再構築テクノロジー、自動/支援開発およびソフトウェア欠陥修復、問題修復効率の向上。
  • Java プログラミング仕様の欠陥修復機能、C/C++ プログラミングの標準欠陥修復機能、Go コードの自動修復機能を提供します。

3.3.6 自動化された展開および公開サービス

3.3.7 該当するシナリオ: ソフトウェアおよびソリューション運用企業

• 推奨される組み合わせ: プロジェクト管理、コード ホスティング、コード インスペクション、コンパイルと構築、デプロイメント、クラウド テスト、リリース。

3.4 アプリケーション管理・運用保守プラットフォーム ServiceStage

• エンタープライズ開発者、テスター、運用保守担当者、またはプロジェクト マネージャーの役​​割に対して、アプリケーションのホスティング、監視、アラーム、ログ分析機能を提供すると同時に、このプラットフォームは非常にオープンであり、主流のアプリケーション テクノロジ スタックと互換性があります。複数の言語、さまざまなマイクロサービス フレームワーク、および複数のオペレーティング環境を含む業界は、企業が従来のアプリケーションと Web アプリケーション マイクロサービス アプリケーションの管理および運用保守の効率を大幅に向上させ、業界指向のアプリケーションのイノベーションに注力することで、企業の競争力を強化するのに役立ちます。
• Spring Cloud: 業界で主流のオープンソース マイクロサービス開発フレームワーク
• Spring-Cloud-huawei: Spring Cloud アプリケーションは、spring-cloud-huawei を使用して Huawei Cloud でホストできます。
• ServiceComb: Huawei が主導する Apache に貢献したオープンソースのマイクロサービス フレームワーク

3.4.1 アプリケーション管理とマイクロサービス アプリケーション アクセス

• ServiceStaqe は、同じ VPC の下にある基本リソース (CCE クラスター、ECS など) とオプションのリソース (ELBRDS、DCS など) を、開発環境、テスト環境、実稼働前環境などの環境に結合します。運用環境ネットワークの相互運用性により、環境の側面に応じてリソースを管理し、サービスを展開できるため、特定のインフラストラクチャの運用と保守管理の複雑さが軽減されます。
• Dubbo は、Alibaba がオープンソース化した、高性能で軽量なオープンソースの Java RPC サービス フレームワークであり、Spring フレームワークとシームレスに統合できます。

3.4.2 アプリケーションのO&M

• CPU使用率、アラーム、ノード例外、動作ログなどのアプリケーション監視指標をリアルタイムにグラフィカルに表示し、主要イベントをリアルタイムに把握します。
• マイクロサービス ガバナンス: マイクロサービス インターフェイス レベルの SLA 指標 (スループット、遅延、成功率) のリアルタイム (第 2 レベル) 監視とガバナンスをサポートし、アプリケーション操作の継続的なサービスを保証します。

3.4.3 ServiceStage ハイブリッド クラウド マイクロサービス ソリューション

• ソリューションと価値:
  • アプリケーション ホスティング: 従来のアプリケーション、Web アプリケーション、マイクロサービス アプリケーションのライフサイクル全体をホスティングし、アプリケーションのグレースケール リリースと自動弾力性を実現します。
  • アプリケーション監視：アプリケーションの稼働状況を監視・監視・制御でき、運用・保守も安心です。
  • アプリケーション アラーム: アラーム情報は複数のチャネルを通じてリアルタイムで配信され、システム障害にタイムリーに対応します。
  • アプリケーション ログ: 大規模なログ ストレージ、第 2 レベルの検索、補助的な問題の特定と動作の分析 分散トランザクション処理: トランザクションの一貫性を確保するための非侵入型および TCC デュアル モードのサポート

3.4.4 ServiceStageと他のクラウドサービスとの関係

• ServiceStageは、ソースコードウェアハウス(DevCloud、GitHub、Gitee、GitLab、Bitbucketなど)との接続を実現し、ソースコードウェアハウスをバインドした後、ソースコードウェアハウスから直接ソースコードをプルして構築することができます。
• ソフトウェア センターは統合されており、完成したソフトウェア パッケージ (またはイメージ パッケージ) を対応する倉庫や組織にアーカイブできます。
• 関連するインフラストラクチャ (VPC、CCE、ECS、EIP、ELB など) を統合し、アプリケーションのデプロイ時に既存または新しく構築された必要なインフラストラクチャを直接使用できます。
• マイクロサービス エンジンが統合されており、ServiceStage コンソールからマイクロサービス ガバナンスに関する操作を実行できます。
• アプリケーションの運用保守管理とアプリケーション性能管理のサービスを統合し、アプリケーションの運用保守や性能監視に関する業務を行うことができます。
• ストレージ、データベース、キャッシュなどのサービスを統合しており、簡単な構成で永続的なデータ保存を実現できます。

3.4.5 適用シナリオ：ServiceStageによるマイクロサービス構築

• ビジネスが成長するにつれて、サービスは、瞬間的な大規模な同時アクセス、サービスエラー、侵入など、さまざまな予期せぬ状況に遭遇することがあります。マイクロサービス アーキテクチャを使用すると、サービスをきめ細かく制御してビジネス ニーズをサポートできます。
• ServiceStage は、次の利点を備えた業界をリードするマイクロサービス アプリケーション ソリューションを提供します。
  • ネイティブの ServiceComb、Spring Cloud、Dubbo、および Service Mesh の複数のマイクロサービス フレームワークをサポート ビジネス コードを変更せずに、クラウドに直接ホストするデュアル スタック モード (SDK とサービス メッシュのインターワーキング) をサポート
  • Swagger ベースの API 管理をサポートします。
  • JAVA、Go、Nodejs、PHP、Python などの多言語マイクロサービスをサポートします。
  • サービス センター、構成センター、ダッシュボード、グレースケール パブリッシングなどの機能を提供します。
  • フォールト トレランス、電流制限、ダウングレード、サーキット ブレーカー、エラー挿入、ブラック リストとホワイト リストなどのマイクロサービス ガバナンス戦略の完全なセットを提供します。ビジネス シナリオに合わせてインターフェイス ベースの操作を実行できるため、サービス ガバナンスの使いやすさが大幅に向上します。

考える質問