クラウド ネイティブ アプリケーションについてどれくらいご存知ですか?

1) 機能からサービスへ

1. 関数から始めましょう

私は1993年からコンピューターの勉強を始めました。学ぶべき開発言語は、アセンブリ、C、DbaseIIIの3つです。

そのため、勉強していたときは、オブジェクト指向のコードアーキテクチャ設計やコードプログラミングの実装を理解していませんでした。したがって、関数間の関係を文字通り区別するには、主に関数の命名、同じコード ファイルへの配置、同じコード ディレクトリ フォルダーへの配置によって関連性を区別します。

当時の関数時代には、例外保護、例外処理、例外ログなどの関数記述の基本原則がなかったため、命名に加えて、関数の入力データパラメータと形式、出力データパラメータと形式に主に重点が置かれていました。

2. オブジェクト指向

私は Object Pascal でオブジェクト指向プログラミングを学び始めましたが、1996 年に Delphi を使用してオブジェクト指向のコードを大量に書き始めました。

クラスが存在するため、関数をグループ化することができます。一部の関数はこのクラス内でのみ呼び出すことができるプライベート関数であり、一部の関数は外部から呼び出すことができるパブリック関数です。

しかし、当時はクラスの使い方がまだ非常に初歩的で、ソース コード ファイルで定義されるクラスは通常 1 つだけでした。さらに、クラスは継承を使用しません。つまり、すべてのクラスは並列であり、クラス間の関係は Public 型のパブリック関数呼び出しを通じて確立されます。

3. インターフェース指向

Delphi は定義ステートメントと詳細な実装が分離されている美しい開発言語です。

ビジネス機能はより複雑になりました。以前は密接な関係がなかった事業同士が、ますます密接な関係になり、一部の階層間での通話が多すぎるという状況が発生しています。このコードを書き直して、これら 2 つのクラスをマージすることを考えました。しかし、書き直すと、変更しなければならない点が多すぎます。

継承や多重継承を使うのは面倒すぎる。実装では常に空の関数を記述する必要があります (つまり、コンパイラが構文を渡すことができるように、コードはなく関数のスケルトンのみ)。その後、インターフェースについて学んだとき、空の関数の代わりにインターフェース定義を使用しました。実装せずに定義するだけでも、コンパイラは成功します。

4. コンポーネント指向

私はコンポーネント指向の時代を十分に経験し、コンポーネント指向のテクノロジーを使用して、完全な ERP リファレンス スイートの世代全体を作成しました。私は、CORBA から COM/DCOM/COM+ まで、幅広いテクノロジを学習し、使用してきました。また、スタンドアロン バージョンから C/S クライアント サーバー LAN バージョン、そして C/S/S 3 層アーキテクチャまでの完全なプロセスも実行しました。

最初は、DBaseIII を使用してアプリケーションを作成しました。 UI 開発、ビジネス ロジック開発、データベース開発はすべて 1 つの開発言語で行われました。

その後、Delphi を使用して C/S アプリケーションを記述する際に、SQLServer の大規模なリレーショナル データベースを使用し、データベース レイヤーで多数のストアド プロシージャとスケジュールされた JOB タスクを記述しました。しかし当時は、ビジネス ロジック コードと UI コードの両方がクライアント上で実行されていたため、2 つのレイヤーの分離は明確ではありませんでした。

次に、C/S/S の 3 層アーキテクチャを記述し、ビジネス ロジック層を分離して、物理的に独立して展開します。このように、クライアント コードとビジネス ロジック層コードは完全に分離する必要があり、混在させることはできません。その頃から、私は慎重なインターフェース設計とオブジェクト設計を多用し始めました。

独立したビジネス ロジック レイヤーがあるため、これらのコード (インターフェイス/クラス) がオブジェクト インスタンスを作成するタイミング、それらがリリースされるタイミング、およびこれらのオブジェクト インスタンスが実行されるプロセス コンテナーに関する要件があります。こうして、コンポーネント コンテナーとコンポーネントが誕生しました。コンポーネント コンテナーは、コンポーネントのライフ サイクル全体 (セキュリティ、作成、同時アクセス制御、スリープ、アクティブ化とウェイクアップ、カウント、破棄、メモリの解放) を管理し、コンポーネント マネージャーは、コンポーネントの登録と検出を管理します。

そのため、「The Essence of COM」の著者である Don Box が、.NET はより優れた COM であると述べたとき、私は突然理解しました。そうです、Microsoft が言いたいのは、スタンドアロン アプリケーション、C/S アプリケーション、または C/S/S アプリケーションのいずれであるかに関係なく、将来的にはすべてのアプリケーションがコンポーネント コンテナーで実行されるべきだということです。各アプリケーションはコンポーネント コンテナー内で実行する必要があり、コンポーネント コンテナーはメモリの作成とリサイクルを保護および管理します。メモリの作成と解放は開発者に直接公開されるべきではありません。そうでないと、開発者の技術力にばらつきがあり、下手なプログラマーの中にはメモリをうまく管理できない人もいて、メモリが簡単にいっぱいになり、オペレーティングシステムがクラッシュする可能性があります。

5. Webサービス

ハハハ、どうやら WebService 指向について聞いたことはなく、サービス指向についてしか聞いたことがないようです。

Web の台頭により、HTML (UI 要素の定義) + CSS (UI 要素のスタイルの定義) + JavaScript (UI 要素の操作) がフロントエンド技術を構成するようになりました。人々は XML をフロントエンドから分離し、それをデータ コンテナーにしました。プレーンテキストの XML データは、HTTP+80 ポート、または UDP、TCP/IP などのさまざまな転送プロトコルを使用して転送できます。もちろん、XML は圧縮してサイズを小さくし、インターネット経由で転送することもできます (特にインターネットの速度が非常に遅かった過去)。また、傍受や閲覧を防ぐために暗号化することもできます。これらは WebService のテクノロジー ファミリを構成します。

C/SS/ 3 層テクノロジー アーキテクチャの LAN バージョンを Web/S/S 3 層テクノロジー アーキテクチャにアップグレードしたいのですが、どうすればよいですか?

したがって、クライアントの AJAX テクノロジを簡単に呼び出せるように、コンポーネントに基づいて Web サービスの別のレイヤーをラップする必要があります。そのため、当時は、.NET コンポーネント テクノロジ、EJB テクノロジ、.NET コンポーネント コンテナー、EJB コンポーネント コンテナー ミドルウェアのすべてに、WebService テクノロジ ファミリのネイティブ組み込みサポートがあり、開発から運用、呼び出しまで、WebService テクノロジを直接使用できました。これは SOA (サービス指向アーキテクチャ) です。

（２）マイクロサービス

1. すべては極限に達すると反対の方向へ転じる

当時は、完全な J2EE システム、WebService + EJB の完全なコンポーネント モデル + WebLogic SOA コンポーネント コンテナ/ESB コンポーネント マネージャ ミドルウェア、テクニカル アーキテクトなど、非常に理想的なものでした。当時はなんと巨大な市場だったのでしょう。

しかし、プログラマーは実用主義者であり、物事を可能な限りシンプルに保ちます。インターネット起業の第 2 波 (2004 年) の台頭により、進むべき道は一生懸命かつ迅速に働くこととなり、資金がない場合はオープン ソースを使用することになりました。

そのため、WebService は REST に置き換えられ、XML は JSON に置き換えられ、EJB は通常の JAVA クラスに置き換えられ、WebLogic はオープンソースの Spring に置き換えられました。特に 2004 年から 2006 年にかけて、SSH トロイカ (Structs フロントエンド、Spring 中間層、Hibernate データ層) が世界を席巻しました。

特に、Google が台頭しつつあった 2004 年から 2006 年にかけて、Google は独自の Open API を非常に簡単に公開しました。これはすでにマイクロサービスの人気の始まりです。しかし、現時点ではマイクロサービスと呼ぶことはできず、簡易サービス (WebSerivce) と呼ぶことができます。

アマゾンの法則

ベゾスは 2002 年に Amazon の分散システム アーキテクチャの 6 つの原則を個人的に策定しました。

1. すべてのチームのプログラムモジュールは、WebServiceインターフェースを通じてデータと機能を開く必要があります。
2. 異なるチームのプログラム モジュール間の情報通信は、これらのインターフェイスを通じてのみ実行できます。その他の形式は許可されません。ダイナミック リンク ライブラリは使用できません。他のチームのデータベースを読み取ることはできません。共有メモリを試すことはできません。他の人のモジュールのバックドアを試すこともできません。許可される通信方法は WebService の呼び出しのみです。
3. すべての Web サービスは、例外なく、外部に公開されるように内部から設計する必要があります。言い換えれば、チームは将来的に例外なく世界中のプログラマーにインターフェースを公開できるように、適切に計画し、設計する必要があります。
4. これをしない人は解雇されます。
5. サービスは小規模なチーム（ピザ 2 枚で賄えるほど）によって管理され、フロントエンドからデータ、需要分散からオンライン運用および保守まで、あらゆることに全面的に責任を負います。
6. 逆算して考える: まず将来を定義し、次にプレスリリースを発行して顧客を調査し、対話し、そしてそれを実行します。

これら 6 つの原則を見て、Amazon がパブリック クラウド コンピューティングのリーダーになった理由がわかりました。クラウドが普及しているにもかかわらず、Amazon が AWS ブランド (Amazon Web Service) の使用にこだわる理由も理解できました。

私は個人的に、Amazon が小規模で完全に機能するチームと内部および外部の統合の原則で WebSevice をオープンして以来、サービスは本当に小さくなり、マイクロサービスになったと信じています。 100 人規模のチームで、専門機能ごとに分かれたチームで、年に 2 回リリースするチームで、社内コールと社外コールを区別するチームであれば、真のマイクロサービス プロバイダーにはなれないと思います。せいぜい、マイクロサービス技術を使用しているが、マイクロサービスを実装していないチームであると言えるだけです。

これは理解しやすいですね。多くのプログラマーは生涯にわたってオブジェクト指向開発言語を使用してきましたが、実際のクラスを自分で定義したことはありませんでした。ここは中国です。

（３）クラウド時代

1. モバイル時代の到来

1990 年代には、C/S、C/S/S Corba、DCOM/COM+ が使用されていました。 2000 年以降は .NET、EJB/WebLogic を使用し、その後は REST、JSON、Spring を使用するようになりました。これはビジネスロジック層技術の進化の変化履歴です。

クライアント側では、インターネット アクセス速度はますます高速化し、コストはますます低下し、画面はますます大きくなり、パフォーマンスはますます向上し、メモリは増大し、顧客に提供される機能はますます増え、UI インターフェイスはますます複雑になっています。現時点でマイクロサービスをやろうと思ったら、実はかなり難しいです。誘惑に抵抗できず、常に機能を追加したくなります。とにかくクライアントは高性能で画面も大きく持ち運びもできるので、損はしない。

しかし、中国では2011年にモバイル時代が始まりました。携帯電話はインターネット速度が遅く、料金が高く、パフォーマンスが遅く、メモリが少なく、画面が小さく、キーボードやマウスがなく、指で画面をスワイプすることによってのみ移動できるため、WeChatはテキストメッセージではなく音声メッセージから生まれました（入力は本当に難しいです）。

画面が小さく、キーボードやマウスがないため、入出力が難しく、機能を何度も簡素化する必要があります。これにより、ビジネス ロジック層が複雑になりすぎないようになります。したがって、Amazon が従業員を解雇する際に使用する 6 つの主要なルールがなくても、マイクロサービスはモバイル時代に大規模に普及するようになりました。現在、ミニプログラム テクノロジーは WeChat プラットフォーム (統合された顧客、IM、支払い) に依存しており、開発、展開、リリースがさらに簡素化されています。

誰もがいつでもどこでもアクセスできるスマート デバイスを持っているため、企業はこれまで以上に簡単に最終消費者とつながり、接触し、対話することができます。そのため、エンタープライズ アプリケーションの重点は、企業内部の管理と制御から、消費者との接続、消費者との対話、消費者が直接注文や取引を行えるようにすることへと移行し始めました。ソフトウェア アプリケーションの主なユーザーは、解雇された従業員を管理する立場から、事業に資金を提供する稼ぎ手へと移行しました。

食料や衣服を提供してくれる人々を怒らせると、販売実績に影響が出るので、この機会を捉えて迅速に改善する必要があります。そのため、スピードを上げるために、専門機能部門間で連携するのではなく、各R＆Dチームも再編し、専門機能部門組織からAmazonスタイルのフル機能の小規模チームへと変革し、マイクロサービスの実質的な実装をさらに推進しました。

そのため、移動の制限や衣食住を提供する親からのプレッシャーにより、大規模な何でも屋プログラマーがマイクロチーム、マイクロプロジェクト、マイクロ機能、マイクロサービスの実装方法を学ぶことができるようになったのは、モバイル時代のおかげです。

2. クラウド時代の到来

エンタープライズ アプリケーションの焦点が少数の企業従業員ユーザーから大規模な外部消費者ユーザーに移行したため、高性能な同時実行性と大量のデータに対する技術要件がすぐに浮上しました。しかし、エンタープライズ アプリケーション開発者は、常に社内のエンタープライズ ユーザーの規模に直面してきました。彼らはインターネット企業ではないので、どう対処するのでしょうか?彼らには経験がない。

ちょうどいいタイミングで、クラウド時代が到来しました。

分散オブジェクト システム、分散データベース、分散ビッグ データ テクノロジ プラットフォーム、分散メッセージ キュー ミドルウェアを提供します。もちろん、Spring は Spring Cloud にアップグレードされ、分散型マイクロサービス ミドルウェアになりました。ああ、ついにこの技術的な限界を超えました。

あまり早く喜ばないで。分散されており、多数の最終消費者に向けられているため、展開が複雑になります。社内の企業管理アプリケーションを扱っていた過去とは異なり、サーバーは最大でも 12 台しかなく、手動でアップグレードでき、従業員は仕事が終わったらすぐに作業を開始できました。これらはすべて消費者向けアプリケーションであり、消費者はそれぞれ異なる行動習慣を持っており、24時間365日稼働する必要があります。さらに、これらはトランザクション アプリケーションであるため、接続を切断したり、トランザクション エラーが発生することを恐れて一度にすべてをアップグレードしたりすることはできず、補償する余裕がないため、グレースケール リリースが必要になります。

これにはツールが必要です。

そのため、DevOps はインターネット時代、クラウド コンピューティング時代に本格的に普及しました。その理由は、膨大なユーザー、24時間365日のオンラインリアルタイム操作、トランザクションベースの大規模サーバー、迅速な反復開発とリリースなど、統合された運用を開発および運用する必要があるからです。従来、運用・保守担当者に対する技術要件は高くありませんでしたが、現在では開発技術力も求められています。

パッケージ化、配布、展開、アップグレード、保守をより迅速に行うために、Docker と K8S が発明されました。 Docker はイメージ ファイルにパッケージ化でき、マイクロサービスのバージョン環境を分離し、開発中および運用中にマイクロサービスの一貫性を保つため、配布、インストール、展開、アップグレード、運用および保守の変更が大幅に簡素化されます。

（4）クラウドネイティブアプリケーション

1. マイクロサービスはなぜマイクロではないのか?

マイクロサービスはマイクロではないため、多くの人が混乱します。

完全に機能するマイクロチーム (ピザ 2 枚)、マイクロ UI (モバイル アプリとミニ プログラム テクノロジー)、マイクロ プロジェクト (2 週間ごとの反復リリース) がありますが、マイクロサービスはまだマイクロではありません。

大規模ユーザーの高い同時実行性に対応できる Spring Cloud 分散マイクロサービス ミドルウェアや、分散デプロイメントと運用保守に対応できる DevOps (Jakins/Docker/k8s) がありますが、マイクロサービスはまだマイクロではありません。

何が問題ですか？

開発プロセスをもう一度見てみましょう。

当社はソフトウェア会社であるため、ソフトウェア コードは当社の中核資産です。そのため、当社には独自のプライベート Git ソース コード リポジトリがあり、これは社内の IDC コンピュータ ルームに展開されており、多層のセキュリティ保護とコード バックアップ メカニズムを備えています。

開発を行う場合、ローカル開発やローカルデバッグを行う前に、ローカルに必要なさまざまなフレームワークをインストールして展開する必要があります。しかし、高同時実行分散ミドルウェア、大規模なビッグデータストレージとコンピューティング、人工知能トレーニング、モノのインターネットアクセスに対応するには、現在、40 を超える依存技術フレームワークをインストールする必要があります。これらのフレームワークを展開してデバッグするだけでも疲れてしまいます。また、これらのフレームワーク間でパラメータの変更やバージョンの非互換性の問題が発生すると、致命的になる可能性があります。

さて、これらすべてのフレームワークを調整し、特定のビジネス アプリケーションを開発した後、パッケージ化、配布、および展開に DevOps ツールと Docker を使い始めます。依存フレームワークが非常に多い場合、マイクロサービスは十分にマイクロ化できますか?

2. クラウドネイティブアプリケーション

正しい開け方は何ですか？説明してみましょう。

ステップ 1:社内で非公開にデプロイされた Git プラットフォームではなく、Cloud Code プラットフォームにコードを配置します。これが、Microsoft が Git の買収に多額の資金を費やした理由です。これが最初のステップです。なぜこれを行うのかは以下で説明します。いずれにせよ、クラウド コンピューティング、ビッグ データ、人工知能、IoT に基づいて特定のビジネス アプリケーションを開発する場合は、オープン ソース プラットフォームに大きく依存することになります。特定のビジネス アプリケーションの技術的なハードルはどの程度まで高くなる可能性がありますか?さらに、Microsoft が引き継いだ後、git は、独自の管理者や運用保守テクノロジよりもはるかに優れたセキュリティ保護とエンタープライズ コードのバックアップを提供できるようになりました。

ステップ 2:クラウド開発プラットフォームを使用します。この開発プラットフォームは、Web ブラウザーまたはローカルの VS Code IDE をベースにすることができますが、クラウド開発プラットフォームの本質は、それほど多くの依存フレームワークをローカルにインストールする必要がないことです。 IDE でアプリケーションを作成し、クラウド上の Git プラットフォームでソース コード ファイルを開いてパッケージをインポートし、IDE で直接 API を呼び出します。クラウド開発プラットフォームは API を自動的に完了します。ローカルで行う場合と同様に、コードを保存、コンパイル、デバッグ、実行できますが、アプリケーションは実際にはクラウドで実行され、パッケージ化、インストール、デプロイもクラウドで行われます。

これは、AWS の Cloud9 のような真のクラウド開発プラットフォームです。現在では、20 年以上前の Yaqi MIS と同じゲームプレイを持ち出し、入力フォームを視覚的にすばやく設計し、承認ワークフローをグラフィカルに設定し、レポートやグラフを視覚的にすばやく設計する模倣者が数多く存在します。この種のものの独立した市場は世界に存在したことがなく、これは今日私たちが話しているクラウドネイティブ アプリケーション開発の道筋にあるものではありません。つまり、開発者向けではありません。

ステップ 3:クラウド サービス OpenAPI を使用します。クラウド コンピューティング ベンダーは、すべてのクラウド サービスをオープン API に公開しています (Amazon の 6 つの法則について考えてみてください)。このクラウド開発プラットフォームでは、このクラウド コンピューティング ベンダーのすべてのオープン API プラットフォームの API を直接呼び出すことができます。これらのクラウド サービスは、インストール、展開、アップグレード、監視、バックアップ、移行などを独自に担当します。

3. 究極: サーバーレス

究極の方法は、サーバーレスです。その時代には、IaaS、テクノロジーPaaS、アプリケーションPaaS、特定業務アプリケーションSaaSなど、多種多様なものが存在していました。誰もがオープンAPIを公開しました。 Slack、エンタープライズWeChat、DingTalkなどの統合ポータルプラットフォームや、小規模なプログラムUIフロントエンド技術もありました。 Web IDE を開いて新しい関数を作成し、Open API を直接呼び出すと、アプリケーション関数が連続して接続されました。

パッケージ化、インストール、展開などの詳細について心配する必要はありません。実行する場合、DevOps/Docker ツールの完全なセットがクラウドのバックグラウンドで自動的に有効になり、パッケージ化されます。お客様独自のクラウド コンピューティング リソースに応じてインストールおよび展開されます。どのサーバーに展開するかを心配する必要はありません。アプリケーションのパフォーマンスが向上すると、より高性能なコンピューティング環境に自動的に移行および拡張されます。これらすべてはあなたにとって何の意味もありません。毎月一括で料金をお支払いいただくだけです。

これを行わないと、開発者の効率は向上しません。これを行わないと、ソフトウェア企業はクラウドベンダーのクラウドハードウェアリソースのみを使用し、他のソフトウェアミドルウェアはクラウドミドルウェアを使用せずにオープンソースとして展開されることになります。その場合、クラウドコンピューティングベンダーが大きな利益を上げるのは容易ではないでしょう。結局、ハードウェアは固定的なコストがあり、収益性が高いのはソフトウェアだけであり、特にクラウド上に展開される分散ミドルウェア サービスは大規模で収益性が高いのです。