技術界は新しいバズワードを生み出すことが多く、誤解されやすいのですが、最も恐ろしいのは、一部の技術チームがバズワードを理解せずに、自分たちでやると怖いかのように、ただバズワードを追ったり、近寄ったりすることです。この現象は技術界隈ではあまりにも一般的であり、快く思っていない人もいるような気がするので、私の見解を表明するために記事を書きます。
マイクロサービスというバズワードに関して言えば、私はこれまでマイクロサービスとサービス化の違いを理解していないと認めざるを得ません。 2016 年に行われたサービス指向の変革後に形成された SOA システムは、現在のバズワードと同じですか? さまざまな記事で、マイクロサービスは単にテクノロジーの世界の一部のシーンの救世主として宣伝されていますが、これは直接誤解を招くものです。学生は、入学したらマイクロサービス システムを開発しなければなりません。 (推奨学習: PHP ビデオ チュートリアル )
しかし、それが必要かどうかを慎重に考えたことがある学生がどれだけいるかわかりません。ビジネス開発の課題? 反復が速いインターネット型ビジネスでは、ビジネスの反復効率が最も重要な問題となります。
私自身の理解に基づくと、サービタイゼーションに関する私の見解は常に、この穴に入ることを避けられるのであれば、入らないのが最善であるというものでした。単一のアプリケーションの複雑さは、単一のアプリケーションの複雑さよりもはるかに大きいです。 N 個のアプリケーションで構成されるディストリビューションです。従来のシステムははるかにシンプルで高速ですが、分散ピットに入ると、テクノロジーに比較的多額の投資を行う必要があります。
一部の中小企業にとっては、それはまったく不必要だと思います。Google の Jeff Dean はかつて、Google のサービス指向のアプローチについて次のように意見を述べています:
Google に何千ものサービスを提供できるようにしましょうこの視点に出会う前は、サービス化は水平方向のスケーラビリティの問題の解決に重点が置かれ、次に並行コラボレーションの問題が続くと常々感じていました。
しかし今では、サービス指向の焦点は、企業が 100 名を超える人々による並行共同開発の能力を備えられるようにすることであるということに基本的に同意します。数十人の研究開発学生がいれば、並行共同開発は可能だと思います。大きな問題にはなりませんが、この時点での並行コラボレーションへの投資は、サービス化開始後の投資よりもはるかに少額になります。
ですから、友人が会社をサービス指向に変えるべきかどうか尋ねたとき、私はいつも 2 つの質問をしました:
その会社の研究開発チームには今何人いますか?
現在の水平スケーリングのボトルネックは何ですか?
サービタイゼーションがこれら 2 つの問題の中心的なボトルネックではない場合、または人員やマシンのコストをわずかに抑えるだけで解決できる場合は、サービタイゼーションを行わないことを強くお勧めします。そのため、マイクロサービスを受け入れてください。バズワードに誘惑されて、そのような構造を採用する前によく考えてください。発生するコストや問題を推測するために使用しないようにする戦略をとるべきです。コストや問題がそれほど大きくない場合は、使用しないでください。
やむを得ない場合を除き、真にサービス指向のサービスを実現するために、組織やチームの人員を調整し、結果的に事業展開の妨げにならないようにしてください。
以上がマイクロサービスはphpに必要ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。