非常に古い学校のアプローチに戻って、マイクロサービスの完全な輪になっていますか？
ソフトウェアのアーキテクチャと設計の観点から、マイクロサービスはミドルウェアに対してどのように「積み上げ」られるか（意図的ではない）？私はJavaから来ています。APIとしてRESTから離れ、少なくともJavaでさまざまなレイヤーと接続パラメーターを抽象化するように、あなたはほとんど来ています。いくつかの非常に古い学校の考えに完全に戻ります。仮想化に戻りました... JVMがすでに仮想であるかどうか。
不可知論的な方法で、RESTful APIをCORBAに抽象化することができ、その利点を主張します。または、よりJava中心の方法で、JMSまたはMDB。
かつて、EJBはJavaで大きな問題でしたが、それはクラスター効果の一部として認識されていましたが、今、最初に戻りましたか？
または、マイクロサービスは、CORBA、またはさらに優れたMDBにはないものを提供していますか？マイクロサービスについて説明している（TLDR）Martin Fowlerを読んだとき、もしそうなら、悪い問題の良い解決策として私を驚かせます。むしろ、問題を押し広げるだけの複雑さのレベルを導入するクローズドマインドアプローチ。サービスが本当にマイクロで数が多い場合、それぞれを実行して維持するために1ドルのコストがかかります。
さらに、多くの中で1つのmicro serviceがそのAPIを変更すると、そのサービスに依存するすべてが壊れます。 seem疎結合ではありませんseemsアジャイルの反対です。それとも私はそれらの言葉を誤用していますか？
もちろん、これらの両極端の間には不確定な量の選択肢があります。
サメ対ゴリラ...行く！ （知識を深めるために、それは皮肉なことを意図しており、私の意図ではありません。質問は額面どおりに受け取られることを意図しています。質問を改善できる場合は、そうしてください、またはコメントを入力して修正します。）
Dockerで実行されている多数のマイクロサービスがすべて1台のマシンで実行され、互いに対話していることを想像してください...狂気。維持や管理が困難であり、変更を重ねると予期せぬエラーが発生するため、変更は不可能です。これらのサービスが複数のマシンに分散していることはどういうわけか優れていますか？そして、それらが分散されている場合、確かにいくつかの非常に古い学校の技術が、少なくともある程度、分散コンピューティングを解決しました。
なぜ水平スケーリングがそれほど普及しているか、少なくとも望ましいのですか？
TL; DR。私はマイクロサーバー風のクールエイドをたくさん飲むことができたので、その背後にある理由について少し話すことができます。
長所：
- サービスは、依存関係が安定していて、焼き込む時間があったことを知っています
- 新しいバージョンのローリングデプロイメントを許可する
- 上位層に影響を与えずにコンポーネントを元に戻すことができます。
短所：
- 依存関係の新機能や光沢のある機能は使用できません。
- APIの下位互換性を壊すことは決してできません（または、少なくとも多くの開発サイクルでは）。
マイクロサービスアーキテクチャの仕組みを根本的に誤解していると思います。それが実行されることになっている方法は、すべてのマイクロサービス（以降、MSと呼ばれます）は、すべてのクライアントが同意する厳密なAPIを持つことです。 MSは、APIが保持されている限り、必要な変更を加えることができます。 APIが保持されている限り、MSを破棄して最初から書き直すことができます。
疎結合を支援するために、すべてのMSはその依存関係のバージョンn-1に依存しています。これにより、現在のバージョンのサービスの安定性が低下し、リスクが少し高くなります。また、バージョンを波状に出すこともできます。最初の1つのサーバーがアップグレードされ、次に半分、最後に残りのサーバーがアップグレードされます。現在のバージョンで重大な問題が発生した場合は、他のレイヤーの機能を失うことなく、MSを以前のバージョンにロールバックできます。
APIを変更する必要がある場合は、下位互換性のある方法で変更する必要があります。
私たちがこれまでに発明したすべてのソフトウェア開発手法は、どういうわけか複雑さを管理することに関するものでした。それらの大部分は、抽象化、カプセル化、疎結合に関するものであり続けています。マイクロサービスは、これらのことを実行するもう1つの方法です。これが、おそらく高い理論レベルで多くの古い手法に似ている理由ですが、それによって有用性や関連性が低くなることはありません。
疎結合に関しては、目標を少し誤解していると思います。タスクAがタスクBを呼び出す必要がある場合、AとBを100％分離する方法はありません。決して起こらない。あなたができることは、タスクBがタスクCを呼び出す場合、タスクCがAへの変更について心配する必要がないことを確認することです。これらの3つのタスクがすべて1つの大きなblobでリンクされ、互いに構造体を渡す場合、それらのいずれかが変更した場合、それらはすべて変更しなければならない大きなチャンスです。しかし、3つすべてがマイクロサービスである場合、基本的には、Aへの変更がBの更新を強制するだけであることが保証されます（Aのコア機能への大きな変更であり、おそらくそれをまったく新しいサービスにする必要がある場合を除く）。これは、すべてのマイクロサービスの更新が下位互換性のある方法で行われる場合に特に当てはまります。
アジャイルコメントに関しては、私たちのマイクロサービスyコードは、「大きなblobにリンクされた」コードよりもアジャイルではるかにうまく機能するという個人的な経験からわかります。後者の場合、誰かが低レベルの機能のバグを修正するときはいつでも、彼は文字通りR＆D部門全体に「タスクを再リンクしてください、またはすべて金曜日にクラッシュします」という電子メールを送信しなければなりません。私たちはこれらをいくつか取得します毎週。彼のコードがマイクロサービス内にあった場合、彼が新しいバージョンをデプロイするとすぐに、私たちは皆、修正から自動的に恩恵を受けます。
CobraとMDBについてのコメントは完全には理解できません。これらはソフトウェアアーキテクチャではなく、コンポーネントのコンポーネントのようです。私の理解では、これらはマイクロサービスのメッセージングプロトコルを定義したり、マイクロサービスを実装したりするための潜在的な方法であり、マイクロサービス自体の代替方法ではありません。
これらのサービスが複数のマシンに分散していることはどういうわけか優れていますか？
クラウドのため。
もう笑った？真剣にしかし-多くの企業にとって、ソフトウェアの最大のコストはもはやソフトウェアではありません。それは、帯域幅、ハードウェア、CDNコストなどです。すべての人がモバイルデバイスを使用できるようになったので、トラフィックはそれだけ多くなります。そして、それはあなたのトースターが独自のインターネット接続を取得するときにのみ悪化します。
したがって、企業はこれらのコストの管理を検討しています。具体的には、「この問題が解決した場合、ソフトウェアを取得または使用する何百万人もの人々にサービスを提供するにはどうすればよいですか？ ？」.
なぜ水平スケーリングがそれほど普及しているか、少なくとも望ましいのですか？
それはこの（巨大で増大する）ビジネス問題に答えるためです。
12人のユーザーがいる場合、すべてのサービスを1つのボックスにまとめることができます。あなたは1箱だけを支払いたいので、これは良いことです。また、ビジネスの拡大に伴い、さまざまなサービスを分割するためのアプリの変更に料金を支払う必要もありません。最近では、顧客の群れがサーバーに火を点ける前にそれを行う時間はありません。
また、サーバーの割り当てを調整して次のことができるので、優れています。
- 持っているほとんどのサーバーを使用して、「無駄」をほとんど残さないようにします。
- ソフトウェアの個々の要素のパフォーマンスを測定します。
- リリースによる展開/ダウンタイムを削減します。
非常にきめ細かい展開を行うことで、これら2つのことをより簡単に/より良くすることができます（問題の分離を強化するのに役立つことに加えて）。