私は長い間、マイクロサービス アーキテクチャのトピックについて記事を書きたいと思っていましたが、XNUMX つのことが妨げになり続けていました。トピックに突っ込むほど、自分が知っていることは明らかで、何が分かっていないように思えてきました。勉強して勉強する必要があるかどうかはわかりません。 一方で、幅広い聴衆の間で議論すべきことはすでにあると思います。 したがって、別の意見も歓迎します。
コンウェイの法則とビジネス、組織、情報システムの関係
もう一度引用させていただきます。
「（広義の）システムを設計する組織は、その組織内のチームの構造を再現した設計を受け取ることになります。」
— メルビン・コンウェイ、1967年
私の意見では、この法律は情報システムに直接関係するというよりは、むしろ事業組織化の実現可能性に関係する可能性が高いと思います。 例を挙げて説明しましょう。 企業を組織するのが理にかなうほど長いライフサイクルを持つ、かなり安定したビジネスチャンスがあるとします (これはタイプミスではありませんが、私が盗んだこの用語がとても気に入っています)。は組織的かつプロセス的にこのビジネスに対応します。
情報システムのビジネス指向
例を挙げて説明しましょう。 ピザを販売するビジネスを組織するビジネスチャンスがあるとします。 V1 バージョン (事前情報と呼びます) では、会社はピザ屋、レジ、配達サービスでした。 このバージョンは、環境変動が少ない条件下で長寿命でした。 その後、バージョン 2 がそれに置き換わるようになりました。より高度で、モノリシック アーキテクチャでビジネスの中核となる情報システムを使用できるようになりました。 そして、私の意見では、ここにはモノリスに関してひどい不公平があるだけです - モノリシックアーキテクチャはドメインのビジネスモデルに対応していないと言われている。 はい、もしそうなら、同じコンウェイの法則と常識に反して、システムはまったく機能しなくなるでしょう。 いいえ、モノリシック アーキテクチャは、ビジネス開発のこの段階のビジネス モデルと完全に一致しています。もちろん、システムがすでに作成され運用されている段階のことを指します。 アーキテクチャのアプローチに関係なく、サービス指向アーキテクチャ バージョン 3 とマイクロサービス アーキテクチャ バージョン N の両方が同等に機能するということは、まったく素晴らしい事実です。 何が問題ですか?
すべては流れ、すべては変化しますか、それともマイクロサービスは複雑さに対抗する手段なのでしょうか?
先に進む前に、マイクロサービス アーキテクチャに関するいくつかの誤解を見てみましょう。
マイクロサービス アプローチの使用の支持者は、モノリスをマイクロサービスに分割すると、個々のサービスのコード ベースが削減され、開発アプローチが簡素化されるとよく主張します。 私の意見では、この発言は完全にナンセンスです。 真剣に考えてみると、モノリスで同種のコード内での明白な相互作用は複雑に思えますか? これが実際に当てはまる場合、すべてのプロジェクトは最初はマイクロサービスとして構築されるでしょうが、実際には、モノリスからマイクロサービスへの移行がはるかに一般的であることが示されています。 複雑さは消えるのではなく、個々のモジュールからインターフェイス (データ バス、RPC、API、その他のプロトコル) やオーケストレーション システムへと移行するだけです。 そしてこれが難しい！
異種スタックを使用する利点にも疑問があります。 これも可能であるとは主張しませんが、実際にはめったに起こりません（将来を見据えると、これは起こるはずですが、利点ではなく結果としてです）。
製品ライフサイクルとサービスライフサイクル
上の図をもう一度見てください。 ビジネスの別のバージョンのライフサイクルが減少していることに私が注目したのは偶然ではありません。現代の状況では、ビジネスのバージョン間の移行を加速することが成功の決め手となります。 製品の成功は、製品内のビジネス仮説をテストするスピードによって決まります。 私の意見では、ここにマイクロサービス アーキテクチャの重要な利点があります。 でも、順番に行きましょう。
情報システムの進化の次の段階、つまり SOA のサービス指向アーキテクチャに進みましょう。 そこで、ある時点で私たちは製品で強調しました 息の長いサービス - 製品のバージョン間を移行するときに、サービスのライフ サイクルが製品の次のバージョンのライフ サイクルよりも長くなる可能性があるという意味で長寿命です。 それらをまったく変更しないのは論理的です - 私たちは 重要なのは次のバージョンへの移行速度です。 しかし、悲しいことに、私たちはサービスに継続的な変更を加える必要があります。ここでは、DevOps プラクティス、コンテナ化など、思いつくすべてが私たちにとってうまく機能しています。 しかし、これらはまだマイクロサービスではありません。
複雑さと戦うための手段としてのマイクロサービス...構成管理
そしてここで、ようやくマイクロサービスの役割の定義に進むことができます。これは、製品構成管理を簡素化するアプローチです。 さらに詳しく言うと、各マイクロサービスの機能は、ドメイン モデルに従って製品内のビジネス機能を正確に記述します。これらは、短命のバージョンではなく、長期のビジネス チャンスに存在します。 そして、製品の次のバージョンへの移行は文字通り気づかれずに行われます。マイクロサービスを XNUMX つ変更/追加し、おそらくそれらのやり取りのスキームだけを変更すると、突然未来に戻ってしまい、バージョン間を飛び回り続ける泣く泣く競合他社を置き去りにします。彼らのモノリス。 ここで、事前定義されたインターフェイスとビジネス機能を備えたかなり大量のマイクロサービスがあると想像してください。 そして、たとえば図を描くだけで、既製のマイクロサービスから製品の構造を構築できます。 おめでとうございます - あなたはプラットフォームを持っています - そして今、あなたは自分自身でビジネスを誘致することができます。 夢夢。
所見
- システムのアーキテクチャは、コンポーネントのライフサイクルによって決定される必要があります。 コンポーネントが製品バージョン内に存在する場合、マイクロサービス アプローチを使用してシステムの複雑さを増大しても意味がありません。
- マイクロサービス アーキテクチャはドメイン モデルに基づく必要があります。ビジネス チャンスは最も長く存続するドメインであるためです。
- 配信プラクティス (DevOps プラクティス) とオーケストレーションは、マイクロサービス アーキテクチャにとって最も重要な要素の XNUMX つです。コンポーネントの変更率の増加により、配信の速度と品質に対する要求が高まるためです。
出所： habr.com