タグ付けされた質問 「middleware」

1
なぜキューとしてのデータベースがそんなに悪いのか?[閉まっている]
私はこの記事を読んだばかりで、混乱しています。 1つのwebappと1つの別個のアプリケーションが「ワーカー」として動作し、両方が同じデータベースを共有しているとしましょう。 ああ、私は「共有」と言いました。しかし、この記事は何について警告していますか?: 第4に、アプリケーション(またはサービス)間でデータベースを共有することは悪いことです。そこに無定形の共有状態を置くのはあまりにも魅力的であり、それを知る前に、巨大に結合したモンスターができます。 =>反対。別個のアプリケーションが依然として同じユニットの一部である場合があります。したがって、この場合、「カップリングの問題」という概念は意味がありません。 続けましょう:webappはクライアントHTTPリクエストを処理し、いつでもいくつかの集約(DDD用語)を更新して、対応するドメインイベントを生成します。 ワーカーの目標は、必要なジョブを処理することにより、これらのドメインイベントを処理することです。 ポイントは: イベントデータをワーカーに渡す方法 読んだ記事が推進する最初の解決策は、優れたメッセージ指向ミドルウェアであるRabbitMQを使用することです。 ワークフローは簡単です: Web dynoがイベントを生成するときはいつでも、RabbitMQを介してイベントを発行し、ワーカーにフィードします。 欠点は、潜在的な送信エラーやハードウェアの問題に対処せずに、集約更新のコミットとイベントの発行の間の即時の一貫性を保証するものがないことです。それは別の主な問題です。 例:集約の更新が成功せずにイベントが発行された可能性があり、その結果、ドメインモデルの誤った表現を表すイベントが発生しました。 グローバルXA(2フェーズコミット)が存在すると主張できますが、すべてのデータベースまたはミドルウェアに適合するソリューションではありません。 それでは、この即時の一貫性を確保するための優れたソリューションは何でしょうか?: IMO、集計更新と同じローカルトランザクションでデータベースにイベントを保存します。 シンプルな非同期スケジューラが作成され、データベースから現在の未公開イベントをクエリし、それらをRabbitMQに送信します。RabbitMQはワーカーにデータを入力します。 しかし、なぜwebapp側で余分なスケジューラーが必要なのか、そしてところで:この場合RabbitMQが必要なのはなぜですか? このソリューションでは、特にデータベースが共有されているため、RabbitMQは不要である可能性があります。 実際、どのような場合でも、即時一貫性にはデータベースからのポーリングが含まれることがわかりました。 したがって、なぜワーカーはこのポーリングに直接責任を負わないのでしょうか? したがって、なぜWeb上の多くの記事が、データベース指向のキューイングを批判しているのに、メッセージ指向のミドルウェアを宣伝しているのか疑問に思います。 記事の抜粋: シンプルで、仕事に適したツールを使用します。このシナリオは、メッセージングシステムを求めています。上記のすべての問題を解決します。これ以上のポーリング、効率的なメッセージ配信、完了したメッセージをキューからクリアする必要、共有状態はありません。 そして、即時の一貫性は無視されますか? 要約すると、データベースが共有されているかどうかにかかわらず、ケースが何であれ、データベースポーリングが必要なようです。 いくつかの重要な概念を見逃しましたか? ありがとう

1
API GatewayとESBの違いは?[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 私が働いている会社は、Webサービスのガバナンス、計測、およびセキュリティのためのミドルウェアソリューションを評価しています。現在、この目的のためにEnterprise Service Bus(ESB)を使用していますが、経営陣の中には、API管理ミドルウェアをデプロイすることに決めた人もいます。 これらのAPI Management(別名API Gateway)ソリューションについて少し調査しましたが、それらと実際のESBの違いを見つけることができませんでした。Mule、WSO2、Oracleなどのホワイトペーパーを評価しましたが、両方の製品で提供される機能はほとんど同じようです。問題は、ESBができないAPI管理ができること、およびその逆です。API GatewayのESBを置き換えることにより、ITインフラストラクチャにどのような価値を追加できますか?

3
非常に古い学校のアプローチに戻って、マイクロサービスで一周しましたか?
ソフトウェアのアーキテクチャと設計の観点から、マイクロサービスはミドルウェアに対してどのように「積み上げ」られますか(意図されていません)私はJavaから来ています。APIとしてのまっすぐなRESTから離れ、少なくともJavaでさまざまなレイヤーと接続パラメーターを抽象化すると、非常に古い学校のアイデアにほぼ完全に戻ってきたようです。仮想化に戻りました... JVMがすでに仮想化されているかどうか。 不可知論的な方法で、RESTful APIをCORBAに抽象化することができ、その利点を主張します。または、よりJava中心の方法で、JMSまたはMDB。 かつて、EJBはJavaで大きな問題でしたが、それがクラスター効果の一部であると認識されていましたが、今、最初に戻りましたか? または、マイクロサービスは、CORBA、またはさらに優れたMDBにはないものを提供しますか?マイクロサービスの説明(TLDR)Martin Fowlerを読んだとき、もしそうなら、それは悪い問題の良い解決策として私を驚かせます。むしろ、問題を押し広げるだけの複雑さのレベルをもたらすクローズドマインドアプローチ。サービスが本当にマイクロで数が多い場合、それぞれのサービスの実行と維持に1ドルのコストがかかります。 さらに、多くの中で1つのマイクロサービスがそのAPIを変更すると、そのサービスに依存するすべてが壊れます。それはしないように見えるそれは、疎結合思わアジャイルの反対を。それとも私はそれらの言葉を誤用していますか? もちろん、これらの両極端の間には不確定な量の選択肢があります。 サメ対ゴリラ...行く! (知識を深めるために、それは皮肉なことを意味し、私の意図ではありません。質問は額面通りに受け取られることを意味します。質問を改善できる場合は、そうするか、コメントしてください。修正します。 ) Dockerで実行されている多数のマイクロサービスがすべて1台のマシンで実行され、互いに対話していることを想像してください...狂気。保守や管理が難しく、変更を重ねると予期しないエラーが発生するため、何も変更することはほとんど不可能です。これらのサービスが異なるマシンに分散していることはどういうわけですか?そして、それらが分散されている場合、確かに、非常に古くからあるいくつかの手法が、少なくともある程度、分散コンピューティングを解決しています。 なぜ水平スケーリングが普及しているか、少なくとも望ましいのですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.