著者紹介
序文マイクロサービスはこれまでしばらく話題になってきましたが、まったく謎めいたものではなく、多くの企業がこの道を追求しています。 Twitter の投稿にマイクロサービスに関する興味深い説明がありましたので、引用します。
マイクロサービスの観点から見ると、Dockerとは何を意味するのでしょうか？これら2つのテクノロジーの関係はどうあるべきでしょうか？ Dockerとマイクロサービスの関係は、親友のような関係であるべきだと私は考えています :-)。なぜそう思うのか、その理由を以下に説明します。この記事の目次はこちらです。ぜひご覧ください。
はい！始めましょう。 1. マイクロサービスとモノリシックアーキテクチャマイクロサービスの鍵となるのは「マイクロ」であり、いわゆるモノリシックアーキテクチャとは対照的です。チームでの実践において、これら2つのアプローチはそれぞれ異なる側面で長所と短所を発揮します。
実際、マイクロサービスアーキテクチャには、単一責任原則への準拠やインターフェース依存関係の容易化といった利点もありますが、これらはDockerとは全く関係ありません。これらは設計段階において重要な利点であるため、ここでは触れません。 簡単に言えば、マイクロサービスとモノリシック アーキテクチャの違いは、「分割統治」、つまりサービスを分割してモジュールまたは機能の境界を定義することにあります。 しかし、単に「分離」するだけでは不十分です。ソフトウェアシステムは一つの全体であり、多くの機能は複数のサービスモジュールの連携によって実現されます。したがって、「統合」の手段が必要です。この矛盾は様々な側面に現れますが、それぞれについて個別に説明します。 2. アプリケーション開発以前、言語技術スタックの多様化のトレンドについて議論しました。しかし、モノリシックアプリケーションの場合、技術スタックの多様化は、言語の混在やソフトウェア構成の互換性の欠如を招くため、推奨される方法ではありません。 実際には、一部のチームが多様なテクノロジースタックを採用できない理由は、システムが1つまたは複数の「モノリシック」なアプリケーションで構成されていることにあります。開発者は既に既存のIDEや関連開発ツールに慣れており、新しいテクノロジーを導入することによるメリットは、それによって生じる問題を上回るからです。 マイクロサービスはこうした状況をうまく回避できます。システムを分割することで、異なる機能モジュールに明確な境界を定義します。これらの境界間の通信は特定の技術スタックから独立して実行できるため、他の技術を組み込む余地が生まれます。
分離があれば、統合もある。異なる技術スタックを持つマイクロサービスでは、通信メカニズムを考慮するだけでなく、これらの技術を（低コストで）システムに統合できることも保証する必要がある。異なるサービスは異なる言語フレームワークを使用できるが、オンラインではそれらが一体となる必要がある。 そのため、リリースプロセス中の「統合」において困難に直面することになりますが、これはまさにDockerが解決できる問題です。この点については既に詳しく議論しましたが、ここでは結論を強調したいと思います。Dockerはすべてのアプリケーションを管理しやすく、テストしやすく、移行しやすいイメージ/コンテナに標準化することで、異なるテクノロジースタックを統合・管理する手段を提供します。 このシナリオでは、開発者はマイクロサービスの分割による過度の学習コストを負担することなく、好みのツールを自由に選択または保持できます。 #p# 3. 組織構造チームや組織について議論するときに避けて通れないトピックの 1 つが「コンウェイの法則」です。
この観点から見ると、マイクロサービスの細分化はチームの拡大に役立ちます。これは理解しやすいことです。システムを複数のマイクロサービスに分割することで、マイクロサービス間の境界が明確になるためです。境界が明確であれば、境界間の連携に必要な情報が少なくなることは周知の事実です。チームをマイクロサービスごとに分割すれば、チーム間の連携コストは比較的低くなります。 しかし、境界間での共同作業に関する情報共有の欠如には、代償が伴います。それは、チームの各メンバーがシステム全体を把握し、制御できなくなることです。この点において、モノリシックアーキテクチャは明らかにはるかに優れています。各開発者の開発環境には完全なシステムビルドが存在するため、システム全体の印象や理解を得るのが容易です。 これはマイクロサービスの弱点ですが、この問題は次の 2 つのシナリオで考慮する必要があります。
問題が異なれば、解決策も異なります。
明らかに、方法1は代替的なアプローチであり、限られたシナリオに適しています。一方、方法2は直接的な攻撃であり、ほとんどの状況に対応できます。この2番目の方法こそが、Dockerの強みを発揮できる点です。 以前、社内の継続的インテグレーションプラットフォームに携わり、多くの研究開発チームをサポートしてきました。マイクロサービスという概念を提唱していないチームもありましたが、「サービス指向のシステム機能を構築し、それを統合する」という手法は既に広く普及していました。そのため、自動化された統合・テストの仕組みも構築しています。
残念ながら、Docker のようなテクノロジーがなければ、「統一された」ビルド プロセスを実現することは困難です。
マイクロサービスアーキテクチャでは、多くの場合、実行時に複数のシステムが稼働しています。しかし、複数のシステムの統合は通常、時間と労力がかかります。これは、コンパイル時間が長くなるだけでなく、複数のシステムの構築プロセスが異なり、サービス間の依存関係が単純ではないことが多いため、自動化のコストが非常に高くなるためです。 しかし、各システムをまずDocker化しておけば、統一されたDockerビルドを通じて一貫したビルドサービスを容易に構築でき、その後、Composeなどのサービス依存関係を管理するインフラストラクチャと組み合わせることができます。こうした取り組みにより、最終的にはマイクロサービスによって分割されたシステム全体を（自動的に）再構築できるプラットフォームが実現できます（マイクロサービスを使用することで、ビルド速度は理論上並列化が可能になり、モノリシックアーキテクチャよりもアジャイル性が高くなる可能性があります）。 このアプローチの最も興味深い点は、次の点です。
このプラットフォームはPaaSに非常に似ていると考える人もいるかもしれません。実際、このまま発展を続ければ、独立したPaaSプラットフォームへと進化する可能性があります。しかし、このプラットフォームは従来のPaaSのような技術的な制限がなく、はるかに多くの機能を備えています。これは非常に魅力的な方向性であり、多くのDockerスタートアップが実現できるものです。 4. システム変更の断片化理論的には、マイクロサービス アーキテクチャは、分解により、根本的な変更を加えたり、ゼロから始めたりすることなく、システムの改善にさらに役立つはずです。 しかし、現実には必ずしもそうなるとは限りません。 マイクロサービスアーキテクチャは概念であり、その適切な適用は依然としてチームメンバーに依存します。システムがモノリシックアプリケーションから進化した場合、チームメンバーは逆の経験をする可能性があり、システムのアップグレードはより複雑で困難になります。 たとえば、次の変更を検討してください (例として
モノリシックアプリケーションの場合、開発プロセスはIDEの マイクロサービスの開発プロセスは次のようになります。
リリースプロセスは次のとおりです。
この運用は非常に脆弱です。サービスが稼働しない場合、ジレンマに陥り、開発者がオンラインで問題を解決せざるを得なくなることもあり、さらなるリスクが生じます。 もちろん、この問題には標準的な解決策があります。それは後方互換性です。これは、各サービスのアップグレードが少なくとも1つの以前のバージョンと互換性があることを意味します。これにより、展開を大掛かりなものにすることなく、依存するすべてのサービスのアップグレードを柔軟に実行できます。 ただし、そうすると下位互換性に対する圧力が増大します。
#p# 5. 運転保守関連施設運用・保守段階の状況は、研究開発段階の状況と似ていますが、異なる点もあります。 アプリケーションの依存関係共通点は、研究開発と同様に、マイクロサービスの導入によって運用・保守フェーズの作業が「断片化」し、全体像を見失いやすくなることです。サービス間の連携は、経営にとってグレーゾーンとなる可能性があり、これは組織体制の議論で既に触れられています。 違いは、サービス間の関係性に関する情報が実際には開発フェーズから得られるという点にあります。この情報を運用保守フェーズに完全かつ正確に伝達できれば、サービスガバナンスははるかに容易になります。そのため、マイクロサービスの運用保守管理は、実質的に「楽」になるのです。
継続的インテグレーションプラットフォームでは、マルチサービス連携の問題を解決する必要があります。解決策は、各サービスが独自の依存関係を宣言し、プラットフォーム上で全体像を把握することです。このプラットフォームが拡張されたり、デリバリーステージに接続されたりすると、以前の全体像情報が活用されます。そのガイダンスの下、システム拡張や自動障害縮退といった一連のタスクをより「インテリジェント」に実行できます。 例えば、開発者がサービスAを作成する場合、そのサービスが依存するサービス（仮にBと呼ぶ）は当然分かっています。そのため、
上記の例は、依存サービスの自動アップグレードとダウングレードにも適用され、アプローチも同様です。 パッケージビルド運用と保守に関して、特に言及する価値のあるトピックがもう一つあります。それはビルドパッケージングです。インフラストラクチャコンポーネントの一つであるビルドシステムは、マイクロサービス化の潮流の中でどのような変化を遂げる必要があるのでしょうか。 この点を説明するために、ソフトウェアパッケージングについて論じた記事を書きました。記事の最後で、ソフトウェアパッケージングにおけるDockerの価値について触れました。ここでは、マイクロサービスの文脈で、記事の要点を簡単にまとめます。
マイクロサービス・アーキテクチャの特徴は、分散性がますます複雑化し、一部のサービスが大規模なクラスターへと拡張される可能性があることです。これはGoogleやFacebookなどの企業が直面している問題と同種であり、解決策も同様です。つまり、システムから出力されるソフトウェア成果物をより完全なもの、いわゆる「自己完結的なもの」にすることです。 要約拡大する未来を見据え、マイクロサービスは分解アプローチを採用してきましたが、ビジネスを完全に実現するには、特定の状況において相互に自由に統合・連携できることも必要です。Dockerはまさにそのような便利な扉を開きます。 運用コストを削減するためにさまざまな言語テクノロジ スタックを調整する場合でも、分散システムの自動テストと継続的な配信をサポートする場合でも、モノリシック アーキテクチャからマイクロサービスへの段階的な進化の場合でも、Docker 関連のテクノロジはマイクロサービスに強力な支援を提供できます。 共に幸せに成長する方法高効率O&M WeChatグループは、中国のO&M業界におけるハイエンドO&Mサークルと垂直型ソーシャルネットワーキングのモデルです。現在、1,000名を超えるメンバーが登録されており、そのうち300名以上はO&Mディレクター以上の役職者です。 「効率的な運用と保守」WeChat公式アカウントはフォローする価値があります。WeChatグループ「効率的な運用と保守」シリーズの唯一の公式アカウントとして、毎週、各グループの議論のエッセンス、運用保守フォーラムのオンライン/オフラインイベントの刺激的な共有、グループメンバーによる独自の記事など、貴重な情報満載のオリジナル記事を多数公開しています。また、「効率的な運用と保守」は、インターネットコラム「効率的な運用と保守のベストプラクティス」と「運用保守2.0」の公式WeChatアカウントでもあります。 注：現在、効率的な運用とメンテナンスのため、2つの主要WeChatグループに貴重な席がわずかしか空いていません。ご希望の場合は、Xiao Tianguoの個人WeChatアカウント（xiaotianguo）を友達追加してご応募いただくか、技術交流グループ（主に技術的な議論を目的としており、主要グループよりもルールが少なく、より活発な交流が行われています）への参加を申請してください。 重要：事前に許可がない限り、この記事を転載する前に、この公式アカウントで公開されてから2日間お待ちください。知的財産権の尊重は最優先事項です。この行と下記のQRコードを含む記事全体を転載してください。 |
