分散型からマイクロサービスへのアーキテクチャの復号化：マイクロサービスアーキテクチャとは正確には何ですか？
マイクロサービスアーキテクチャ
マイクロサービスアーキテクチャは現在非常に人気のある概念であり、技術開発の必然的な結果です。マイクロサービスアーキテクチャは曖昧で空の用語ではありません。そのコアコンセプトとアーキテクチャの原則は現実的です。マイクロサービスアーキテクチャの技術標準とドラフト仕様は認められていませんが、業界にはすでに影響力のあるオープンソースマイクロサービスがいくつかあります。サービスアーキテクチャプラットフォーム、アーキテクト会社の技術力に応じて、プロジェクトの特性と組み合わせて適切なマイクロサービスアーキテクチャプラットフォームを選択し、プロジェクトのマイクロサービスの変換または開発プロセスを着実に実装できます。
マイクロサービスアーキテクチャの概要
マイクロサービスアーキテクチャは、過去2年間で最も人気のあるアーキテクチャ用語の1つです。有名なマーティンフラワーはかつて次のように説明していました。
「マイクロサービス」は、街頭に溢れるソフトウェアアーキテクチャの新しい用語です。私たちはそのような用語を非常に軽蔑していますが、それらが説明するソフトウェアスタイルはますます私たちの注目を集めています。過去数年間で、ますます多くのプロジェクトがこのスタイルを使用し始めていることがわかりました。そのため、同僚は、これがエンタープライズレベルのアプリケーションを構築する際のデフォルトの開発フォームであることを当然のことと考えています。残念ながら、マイクロサービススタイルとは何か、そしてそれをどのように開発すべきかについての理論的な説明を見つけることは困難です。
インターネット時代では、極端な状況下で毎日開発され、立ち上げられるべき新しい要件があります。コードとチームメンバーの数が増えるにつれ、従来のモノリシックアーキテクチャの欠点がますます顕著になり、ビジネスの迅速なイノベーションとアジャイルデリバリーが大幅に制限され、「高速であるがインターネットによって追求された「壊れた」。これが、マイクロサービスアーキテクチャの台頭の時代の背景です。
マイクロサービスアーキテクチャの台頭の理由
マイクロサービスアーキテクチャが急速に普及しているのはなぜですか？マイクロサービスアーキテクチャがデフォルトの開発形式であると考える人が増えているのはなぜですか？
上記の2つの質問を理解するには、最初に他の2つの基本的な質問を理解する必要があります。つまり、私たちが通常話しているモノリシックアーキテクチャとはどのようなアーキテクチャですか？マイクロサービスアーキテクチャとはどのようなアーキテクチャですか？次の図は2つを示しています。人々の間の違い。
従来のアプリケーションアーキテクチャはモノリシックアーキテクチャとも呼ばれ、ビジネスシステムのさまざまなモジュールが緊密に結合されていることを示します。各モジュールはプロセスで実行されます。基本的に、システムをアップグレードするたびにアプリケーションプロセス全体を再起動する必要があります。特定のモジュールに問題がある場合、システム全体が正常に起動しない可能性があります。マイクロサービスアーキテクチャは、ビジネスシステム内のさまざまなモジュールをマイクロサービスの形式で分割することです。これにより、各マイクロサービスは独立したプロジェクトになり、独立したプロセスとしてコンパイルおよび展開されます。各マイクロサービスサービスは、複数の独立したプロセスとして展開され、外部に提供されます。外部インターフェイスは通常、RESTまたはRPCです。さまざまなマイクロサービスプロセスを複数のサーバーにデプロイすることもできます。
比較すると、マイクロサービスアーキテクチャは、巨大な単一プロセスを複数の独立したマイクロプロセスに分解し、分散型のアイデアを使用して、インターネット時代の従来の単一アーキテクチャが直面するさまざまな問題を巧みに解決することがわかります。したがって、マイクロサービスアーキテクチャの新しい概念がすぐにすべての人に受け入れられ、すぐに普及したのには大きな理由があります。
従来のモノリシックアーキテクチャが直面する課題を解決するために、ソフトウェアアーキテクチャは、SOAアーキテクチャ、RPCアーキテクチャ、分散サービスアーキテクチャ、そして最後にマイクロサービスアーキテクチャに進化しました。ただし、ソフトウェア開発に特効薬があったことは一度もないことを覚えておく必要があります。したがって、マイクロサービスアーキテクチャは特効薬ではなく、アーキテクチャの考え方と開発モードの変化であり、まだ多くのことがあります。問題とチームの問題を適切に解決する必要があります。
マイクロサービスアーキテクチャの実装で直面する最大の技術的問題の1つは、開発、運用、および保守プロセスの自動化です。元の中規模システムアーキテクチャをマイクロサービスアーキテクチャに変換する場合、少なくとも12個のマイクロサービスを分割できるため、非常に多くのマイクロサービスプロセスのコンパイル、展開、試運転、およびアップグレードが次のように進化します。自動化された手段はなく、マイクロサービスを促進することはできません。自動化に関しては、マイクロサービスアーキテクチャの開発の重要な推進力であり、マイクロサービスアーキテクチャの急速な人気の重要な理由であるコンテナテクノロジについて言及する必要があります。
コンテナ技術について言及する必要があります
実際、コンテナテクノロジーは、一部のインターネット企業で長い間広く使用されてきました。Dockerが登場する10年以上前から、Googleはコンテナテクノロジーを使用して世界最大の分散クラスターをサポートしてきましたが、秘密を守ってきました。マイクロサービスアーキテクチャツールKubernetsまで外の世界に。コンテナテクノロジーはIT業界で最も重要なプラットフォームレベルのテクノロジーとして業界で認識されているため、Googleはこのテクノロジーをオープンソース化しました。機会を捉えて発言権を制御できない場合、テクノロジーによってもたらされる市場シェアは徐々に失われます。リーダーシップ。
まず、Dockerの開発の歴史を振り返ってみましょう。Dockerは2014年にバージョン1.0のみをリリースし、2014年に最もホットなテクノロジーの1つになりました。2004年初頭のBラウンドの資金調達から、年末のDockerCon Europe会議まで、Dockerは今年順調に稼働しており、Microsoft、Google、AWSでも好まれていました。当時、マイクロサービスアーキテクチャは、クラウドコンピューティング、DevOpsなどの技術的概念が本格化しており、Dockerはこれらの概念の実装を技術的に完全に推進しています。2015年、CoreOSは独自のコンテナエンジンRocketをリリースし、コンテナテクノロジーの分割と統合について大きな議論を引き起こしました。その後、Linux Foundationの介入の下、DockerとCoreOSは握手を交わし、0CI（Open Container Initiative）を設立しました。当時のJavaのJCP組織に似た標準委員会には、GoogleやRedHatなどの巨人が参加し、OCI組織はコンテナの技術標準と仕様を策定する責任があります。2016年にリリースされたDocker1.11は、OCI標準に準拠する最初のコンテナエンジンになりました。2014年から2016年にかけて、DockerHubのダウンロード数は1億から60億に増加しました。2017年、Docker社はDockerバージョンをエンタープライズバージョンとコミュニティバージョンに分割し、エンタープライズの課金を開始し、Dockerオープンソースプロジェクトのコードを新しいMobyプロジェクトに移行しました。このプロジェクトは、メンテナンスのためにコミュニティにプッシュされました。 。Docker社は2つの製品を提供しており、そのうちDocker-ceはMobyプロジェクトに基づく無料のコンテナー製品であり、Docker-eeはその商用製品です。ソフトウェア開発プロセスには、環境のセットアップ、インストールパッケージの公開（FTPサーバーへのインストールパッケージの公開またはUSBフラッシュドライブでのコピー）、アプリケーションの展開など、手作業に依存する多くのステップがあることを私たちは知っています。 、システムのアップグレードなど。どちらも時間と労力がかかり、タスクの品質と完了時間を保証することは困難です。分散システムでは、クラスターをスケールアップすると、上記の手動操作が非常に簡単になり、多くの反復作業のためにトラブルシューティングが困難なさまざまなエラーが発生します。Dockerは、革新的な標準化されたイメージ（Docker Image）のパッケージ化とアプリケーションテクノロジーの公開を画期的なものとして使用し、従来のソフトウェア開発における上記の問題点を痛感し、「ソフトウェアライフサイクルにおける標準化と自動化」の新しい標準を定義することに成功しました。 。次の図は、Dockerの標準化されたイメージの概略図を示しています。
Dockerイメージは、ターゲットプログラムのすべての依存ファイルを含む「オールインワン」階層圧縮パッケージです。Linuxカーネルはなく、Linuxファイルシステムと基本コマンドを備えた最も合理化された仮想マシンと考えることができます。この仮想マシンには、インストールおよび構成されたターゲットアプリケーションのバイナリコードと、実行中のターゲットプログラム内の他のすべての依存パッケージが含まれます。たとえば、Torncatで実行されている完全なアプリケーションのDockerイメージは次のように構成されます。
イメージを開始するプロセスは、イメージのパッケージ化および作成時に指定されたターゲットプログラムを開始することです。たとえば、Tomcatの場合、tomcat.shコマンドを実行します。さらに、イメージ自体がインストールプロセスと構成パラメーターを固めたため、Dockerイメージを使用してコンテナーを作成および開始することは、非常にシンプルでエラーのないコマンドになりました。
docker. run xxximage操作中に指定する必要のあるパラメーターは、環境変数と起動コマンドパラメーターを介してコンテナーに渡すことができます。異なるコンテナーは互いに分離され、異なるイメージバージョンのコンテナーを同じホストで同時に開始できます。情報をテストできます。さらに、Dockerはイメージを構築し、コンテナーを作成し、コンテナーのすべての機能を開始、停止、一時停止、再開、破棄してRESTAPIにするため、プログラミングによる自動制御を実現できます。後述するように、KubernetesはDockerのAPIを使用して実装します。完全に自動化されたマイクロサービスアーキテクチャプラットフォーム。
パッケージ化されたDockerイメージをソースコードのようにバージョン管理し、一元的にホストし、ダウンロードして世界中のネットワークマシンで実行できますか？Dockerの2番目のアイデアは、GitHubのアプローチを模倣し、世界で唯一のオープンなDockerウェアハウスを作成しました。アカウントを登録し、独自のパッケージ化されたDockerイメージを共有します。これで、考えられるほとんどすべてのミドルウェアまたは基本的なアプリケーションがDocker Hubにミラーリングされます。たとえば、次のコマンドは、DockerHub（MySQLミラー）から自動的にプルダウンし、MySQLサーバーを起動します。このマシンでは、リモートマシンからアクセスできます。DockerHubの存在は、Dockerテクノロジーの普及と開発を大幅に加速させました。
docker run -it -e MYSQL_ ROOT PASSWORD=123456
mysql/mysql-serverプライベートミラーリポジトリはDockerレジストリと呼ばれます。通常、Dockerを使用するすべての企業は、Docker Hubから取得した標準の基本イメージとこれらの基本イメージに基づいてパッケージ化されたプライベートイメージを格納するために、プライベートDockerRegitryを確立する必要があります。次の図は、Dockerイメージのパッケージ化および実行中のDockerレジストリとの対話プロセスを示しています。
要約すると、Dockerテクノロジーを通じて、ソースコードのコンパイル、イメージパッケージング、テスト環境のデプロイ、バージョンリリース、システムのアップグレードから本番環境のリリースなど、ソフトウェア開発のライフサイクルにおけるすべての重要なリンクを簡単に自動化できます。これはマイクロを加速するためです。サービスアーキテクチャの実装に関する重要な技術的保証。次の図は、このプロセスの簡単な概略図です。
マイクロサービスアーキテクチャを完全に理解する方法
マイクロサービスアーキテクチャは、SOAアーキテクチャ、RPCアーキテクチャ、分散サービスアーキテクチャから進化したもので、次のような特徴もあります。
まず第一に、マイクロサービスアーキテクチャは分散システムアーキテクチャです。つまり、分散システム設計の原則と経験、および一般的に使用される分散インフラストラクチャとミドルウェアは、依然としてマイクロサービスアーキテクチャの重要な部分です。分散アーキテクチャのこれらのテクノロジが脇にある場合は、マイクロサービスアーキテクチャについて説明してください。 、それは空の城のようなものです。
第二に、SOAアーキテクチャと同様に、マイクロサービスアーキテクチャは開発言語とは関係がなく、認識されている技術標準の仕様と実装計画がありません。一般的に受け入れられている新しい設計概念と指針となるイデオロギーをより反映し、要約しています。以下の点。
●軽量サービス：各サービスインスタンスは、1つまたは複数の密接に関連するサービスのみを提供し、粒度が小さく軽量であるため、マイクロチームの迅速な開発、展開、テスト、およびアップグレードが容易になります。
●疎結合システム：マイクロサービス間の呼び出しもクライアントの呼び出し方法であり、インターフェース層の結合に限定され、サービス実現層の深い結合を回避するため、サービス間の依存関係が最小限に抑えられ、システムの全体的な安定性とバランスのアップグレード（ローリングアップグレード）機能が効果的に保証されます。
●スムーズな拡張機能：特定のマイクロサービス負荷分散メカニズムがマイクロサービスアーキテクチャプラットフォームでネイティブに提供されるため、ステートレスマイクロサービスの場合、複数のサービスプロセスインスタンスを個別にデプロイすることで全体的なスループットを向上させることができます。各マイクロサービスは個別に拡張できるため、マイクロサービスアーキテクチャには強力なランタイムパフォーマンスチューニング機能があります。
ビルディングブロックシステム：各マイクロサービスは通常、複雑なビジネスプロセスで最小の粒度を持つ論理ユニット（ビルディングブロック）として設計されます。完全なビジネスプロセスは、これらのマイクロサービスを合理的に配置（ビルディングブロック）することによって形成されるワークフローです。 -新しいビジネスプロセスの開発は単純なビルディングブロックゲームになりました。マイクロサービスの増加に伴い、ビジネスユニット（マイクロサービス）の再利用価値が高まっているため、新しいビジネスが迅速に開始されます。需要は正確に評価できる計画されたタスクになり、予測。
最後に、マイクロサービスアーキテクチャには、事実上認識されているフレームワークとツールもいくつかあります。現在最も古典的なのは、次の3つのマイクロサービスアーキテクチャのオープンソースプラットフォームです。
- IceGridマイクロサービスアーキテクチャプラットフォームは、RPCアーキテクチャから進化しました。
- Spring Cloudマイクロサービスアーキテクチャプラットフォームは、RESTインターフェースに基づいて進化しました。
- コンテナテクノロジーに基づくKubernetesマイクロサービスアーキテクチャプラットフォーム。
上記の3つの古典的なマイクロサービスアーキテクチャプラットフォームは、完全なマイクロサービスアーキテクチャと管理ツールを提供でき、それぞれにテクノロジーの利点があります。全体として、GoogleのKubermetesは優れたマイクロサービスアーキテクチャであり、この章の焦点でもあります。マイクロサービスアーキテクチャ。
次に、マイクロサービスアーキテクチャプロジェクトを実装するプロセスで発生する可能性のある問題と対処戦略を見てみましょう。
まず、アーキテクトはプロジェクトチームのすべてのメンバーをトレーニングして、マイクロサービスアーキテクチャのアイデアと利点を全員に理解させる必要があります。トレーニングの重要な目標は、マイクロサービスアーキテクチャがプロジェクトに多くのことをもたらすことを全員に理解させることです。開発者であれ、運用および保守テスターであれ、明らかなスキルアップグレードのニーズは、新しいテクノロジーを学び、自己スキルを向上させる貴重な機会です。プロジェクトを完了するというプレッシャーに誰もが耐えられることを願っています。
次に、自分で調査して開発するのではなく、適切なマイクロサービスアーキテクチャプラットフォームを正しく選択する必要があります。このような大規模な基本プラットフォームは、研究開発コストが高く、開発サイクルが長く、持続可能なプラットフォームアップグレードの可能性があるため、強力で経験豊富なオープンソースであっても、現在、独自に研究開発を行っている企業はほとんどありません。 RedHatなどのソースソフトウェアサービスタイプ同社はまた、独自のマイクロサービスアーキテクチャを放棄し、Kubernetesに切り替えました。では、会社やプロジェクトチームに適したマイクロサービスアーキテクチャプラットフォームをどのように選択しますか？このセクションで説明した3つの典型的なマイクロサービスアーキテクチャプラットフォームを例にとると、次の条件を参照して選択できます。
●チーム全体でコンテナテクノロジーの経験がない場合は、Kubermnetesを除外します。それ以外の場合は、最初に選択します。
●システムのパフォーマンス要件が非常に高く、同時に多くの高頻度プロセスで多数のマイクロサービスコールがあり、マイクロサービス間でも多数のコールがある場合は、まず、次のようなマイクロサービスプラットフォームを検討します。 RPCバイナリモードで通信します。最初にIceを検討し、次にItをKubernetes、最後にSpringCloudを検討します。
●システムが社内で開発されたさまざまなサービス間のリモート呼び出しであり、ミドルウェアが使用されることはめったになく、高性能通信と水平拡張機能のみが必要な場合は、Iceが最適であり、Spring Cloud、最後にKubernetesがそれに続きます。KubernetesはRPCアーキテクチャを提供しないため、この場合、システムの複雑さが増します。
●プロジェクトが複数の言語で共同開発されている場合、この場合、KubernetesアーキテクチャとIceを優先できます。
さらに、マイクロサービスアーキテクチャプロジェクトの実装では、次のタスクがよく考慮されます。
（1）自動化ツールと一元化された運用および保守管理ツールを導入します。自動化されたツールは、プログラムのコンパイルとパッケージ化、自動化された展開とアップグレードのプロセスで使用されます。一元化された運用保守監視ツールには、主に、さまざまなノードに分散されたシステムログとアプリケーションログを収集するために使用されるログ収集とクエリ表示システム、およびリソースの使用状況とアプリケーションを表示するために使用されるリソース監視と障害システムが含まれます。アラーム。
（2）多数の関連するオープンソース製品（およびツール）を調査および評価し、それらをマイクロサービスアーキテクチャに導入します。マイクロサービスアーキテクチャは本質的に分散アーキテクチャであるため、モノリシックアーキテクチャの開発で記述された一般的なコードの一部は、最も一般的な構成モジュール、タイミングタスク、同期ロジックなど、マイクロサービスアーキテクチャシステムに適用できません。しばらくお待ちください。さらに、多くのミドルウェアでは、元々シングルノード方式しか使用できませんが、マイクロサービスアーキテクチャでは、クラスターモードに切り替える必要があることがよくあります。この場合、これらのミドルウェアのより詳細な調査とテストが必要です。 。、そして他の同様のミドルウェアに切り替えることさえあります。
（3）チームの再編成。マイクロサービスモードでは、アーキテクチャ層の観点から、システム全体が基本的にプレゼンテーション層とマイクロサービス層に分けられます。
システム全体でのマイクロサービスの重要性を考慮すると、チームのバックボーン技術者がマイクロサービスレイヤーの開発の主力になることをお勧めします。全体として、彼らはすべてのマイクロサービスコードを担当し、各マイクロサービスインターフェイスを一緒に設計します。 。すべてのマイクロサービスコードを確認します。特定の開発プロセスでは、類似性の高い複数のマイクロサービスモジュールを、研究開発のために同じ人に渡すことができます。このモデルは基本的に第28法則に準拠しています。
（4）高品質のドキュメント。マイクロサービスアーキテクチャでは、ドキュメント、特に各マイクロサービスのインターフェイスドキュメントの重要性がますます高まっています。これは、マイクロサービスを使用するすべての人が、現在呼び出されているマイクロサービス、どのインターフェイスとパラメータを呼び出す必要があるかを知っている必要があるためです。および戻り値の意味。したがって、詳細で正確なマイクロサービスインターフェイスドキュメントが必要です。また、ドキュメントとコードを同期的に更新する必要があります。
次に、システムでマイクロサービスを設計する方法を見てみましょう。当初、マイクロサービスとして設計する必要のある機能とサービス、マイクロサービスに含める必要のあるインターフェイスの数、および各インターフェイスの設計方法については、実際にはあまり明確ではありませんでした。著者の提案は、マイクロサービスを大まかに分割することです。各マイクロサービスには、マイクロサービスの数を減らすためのより多くのインターフェイスが含まれています。これにより、開発、プログラムのパッケージ化、テスト、および展開の作業負荷を軽減でき、プロジェクトを迅速に進めることができます。
システム内のマイクロサービスは、次の図に示すように、プロセス制御、インターフェイス、および基本的なコアクラスの3つのタイプに分類できます。
一般的に、これら3つの異なるマイクロサービスのインターフェイス設計も異なります。
プロセス制御マイクロサービスは主にUI呼び出しを対象としているため、そのインターフェイスデザインでは、ページ表示の利便性を最初の目標として使用する必要があります。つまり、ほとんどの場合、JSONまたはTEXTテキストを使用してパラメーターと戻り値を渡し、ロジックInの呼び出しを検討します。エラーが発生した場合は、クライアントにエラーコードと理由を伝えます。そのため、このタイプのマイクロサービスの戻り値は通常、次の構造になります。
public class CallResult
int resultCode; //返回代码， 0为成功，其他为调用错误
String resultData;//调用结果， 通常为JSON的字符串
String errmsg; //调用错误的时候，展示给用户的可读错误信息インターフェイスマイクロサービスは主にサードパーティシステムを対象としているため、セキュリティの問題に特別な注意を払う必要があります。したがって、インターフェイスの設計ではセキュリティ対策を講じる必要があります。一般的な解決策は、呼び出しパラメータにトークンを追加し、パラメータの暗号化の問題を検討することです。 。同時に、インターフェイスクラスをお勧めします。マイクロサービスは、実装プロセスでのログ出力の問題に注意を払い、インターフェイスジョイントのデバッグを容易にし、操作中のインターフェイスのトラブルシューティングを容易にします。エントリパラメータ、キーロジックブランチ、戻り結果などの重要な情報は、ログに記録されます。
基本的なコアマイクロサービスは、主にUIと他の2種類のマイクロサービスによって呼び出されます。この種のマイクロサービスのインターフェイス設計では、呼び出しの効率と利便性が主に考慮されます。多くの複雑なBeanオブジェクトをパラメーターおよび戻り値として使用しないように、通常のJavaクラスのインターフェースと同じように見えるように設計することをお勧めします。これにより、呼び出し元の負担が増えるだけでなく、インターフェースのパフォーマンスも低下します。
マイクロサービスの設計では、次のマイクロサービスインターフェイスの設計など、インターフェイスの互換性の問題も考慮する必要があります。
public void doBusiness (paraml, param2, param3)パラメータの数を増やす可能性がある場合は、古いバージョンとの互換性を保つために、次の設計に変更することをお勧めします。
public class XXXBean
{
private String paraml;
private String param2;
private String param3;
private String param4;
}
public void doBusiness (XXXBean thebean)このように、古いインターフェースを再コンパイルする必要はありません。XXXBeanが配置されているJARファイルをアップグレードして、古いバージョンと互換性を持たせるだけです。