はじめに：
過去には、それが通過するのは簡単です：ベアメタルサーバーを削除し、必要なすべてのソフトウェアをインストールし、すべてのアプリケーションのコードを追加し、データは、単一のアプリケーション（モノリシック・アプリケーション）を展開するための一連の手順をアップロードします。すべてのコンポーネントが単一のサーバーに集中しているので、ので、このアプリケーションは、唯一の大きな流れを処理することができ、管理および展開するのは非常に容易ではないだろう。
しかし、このタイプのアプリケーションとの大きな問題は、非効率的です。たとえば、ピーク負荷の第1の推定値は、サーバーに十分な性能と相まってなければなりません。しかし、そのようなリソースを持つことは、サーバが通常の負荷の下でのアイドルであり、さらに小さな負荷での廃棄物の多くを引き起こし設定します。
また、当社は、手動でサーバーのリソースに拡張する痛みが必要な場合があります。コンポーネントは、サーバー自体よりも多くのリソースを必要とする場合、他のすべてのコンポーネントに影響を与えるにバインドされ、機械全体のアップグレードを、シャットダウンするように強制する必要があります。したがって、ユニークなベアメタルサーバーのアプリケーションシナリオがまだあることは事実であるが、彼らは徐々に新しいマイクロサービスアーキテクチャによって置き換えられました。
マイクロサービスアーキテクチャとは何ですか？
マイクロ・サービス・アーキテクチャは、疎結合にアプリケーションサービスのセットを構築する、ソフトウェア開発技術です。これらのサービスは、アプリケーションのモジュール性を向上させ、かつ簡単に、理解を開発およびテストするだけでなく、軽量プロトコルの特性を洗練しています。彼らは独立することにより並行開発、展開を使用して、そのサービスを展開することができ、チームの小さな自治。また、マイクロアーキテクチャ・ベースのサービスも継続的デリバリーと展開（：ウィキペディア、ソースサポートすることができます https://en.wikipedia.org/wiki/Microservicesを ）。
したがって、私たちはもはや、すべてのコードとデータ資産のデータベースを展開するために、1台のサーバに限定されていないが、各タグは、異なるグループに分割し、それぞれ独立して動作します。したがって、我々は特定の記憶領域を設定することで、画像の保存、アップロード、オペレーションを担当するコードの一部のみを許可することができるだけでなく、また、特定のデータベースを作成することができ、コードの一部は、チェックのためにのみ責任があることを確認し、セッションを作成します。さらに、新しいユーザーの投稿を処理するコードの特定のブロックを使用するか、あなたは不適切な発言があったかどうかを確認するために、別のコードのブロック（またはサービス）を使用することができます。データベースには、コメントのすべての種類を格納するために使用することができ、他のライブラリには、キーワードで検索することができます。
だから、実用的な何のメリット、それはマイクロサービスを提供していますか？
・まず、各マイクロサービスは、貴重なリソースとサービスを節約するために比例して容量を調整するためにストレッチ、使用状況に基づくことができます。
・第二に、私たちはより良いデータベース、バックエンドのコードライターを担当している開発者を持つ人々を接続することができ、およびUI / UXの担当者はに残して十分位。
サービスのそれぞれは互いに独立して動作することが可能であるので・また、負荷が別のコンポーネントにコンポーネントのサイズに影響を与えないであろう。同様に、コンポーネントのアップグレードは、他のコンポーネントの分割が関与する必要はありません。
目に見える、さまざまなコンポーネントは、高い稼働時間を達成することができます。
マイクロサービスアーキテクチャの制限事項
すべての長所と短所、マイクロサービスアーキテクチャの主な欠点の一つは次のようになります。通常のアプリケーションの実行時間の全体的なセキュリティ。我々は、個々のコンポーネントの信頼性が増加したものの、様々なマイクロサービスにアプリケーション全体に分散が、アプリケーションの全体的な信頼性のコストで不確実性をもたらします。されますので、
単一ベアメタルアプリケーションでは、関係なく、ネットワーク、ハードドライブ、メモリ、または問題の他の側面の、アプリケーションは、サービス全体を中断します。そのため、あなたにサプライヤーのコミットメント99.5％の稼働時間あれば、あなただけが99.5％を基準にどのように改善できるかを心配する必要があります。あなたはマイクロサービスアーキテクチャを使用している場合は、各コンポーネントは、その稼働時間のベースラインを持っています。例えば、アプリケーションが、10のサービスを使用しながら、99.5％、10 = 95.0％の電力の99.5％の全体的な割合の正常な動作の各サービスの稼働時間の全体的な割合。
これはマイクロサービスのアーキテクチャが良くないということでしょうか。必ずしもそうではありません。これは単に外もたらしたマイクロサービスの利点から利益を得るだけでなく、開発者がアプリケーションを保護するために、他の措置を講じて、ダウンタイムの可能性を減らす必要があることを意味します。非常に興味深いここで、我々は別のマイクロサービスを導入できるということである-アリクラウドメッセージングサービス（アリババクラウドのメッセージサービスは、参照 https://www.alibabacloud.com/product/message-serviceを ）。
アリクラウドメッセージングサービスは何ですか？
アリクラウドメッセージングサービスは、分散メッセージキューイングおよび通知サービスです。これは、アプリケーションとデカップリングシステム間の輸送メッセージを助け、同時動作をサポートしています。アリクラウドメッセージサービスは、分散アプリケーション間のさまざまな複雑なタスクを実装するために、データを転送するためにユーザを可能にし、さらにアプリケーションの耐障害性とデカップリングで構成します。
どのようにメッセージサービスの稼働時間？
より優れたメッセージングサービスの信頼性を向上させる方法を理解するためにある、のが一般的なグループチャットアプリケーションを議論しましょう。チェルシー、バルセロナ、レアルマドリード、バイエルン・ミュンヘン、マンチェスター・ユナイテッドと他の人気のサッカークラブ：あなたはなど、様々なチャットグループを含むグループチャットアプリケーション-Sportsアプリケーション、などのファンを構築したとしましょう。
誰もが、メッセージ内の任意のグループに公開することができ、そして公開されたニュースの通知を他のファンに知らせるために、自分の好きなクラブチームに加入することができます。明らかに、あなたは、このようなアプリケーションを開発する必要があり、その拡張性に十分配慮し。継続的な成長を監視することで、あなたは不適切な音声と画像のメッセージのすべての種類をフィルタリング、およびニュースの検索機能を提供することができます。したがって、これらの要件を満たすためには、各機能のためのクラウドサービスの範囲を提供しています。以下に示すように、最終的なシステムアーキテクチャ：
ユーザーがグループに新しいメッセージを公開する設定の場合には、スポーツのAppの後端部には、要求を受信し、マイクロサービスに渡し、そして最終的にはユーザーの転送の成功を知らせます領収書。具体的な手順：
- まず、非標準のHTMLタグ、または他のハザードの入力パラメータをフィルタリングしながら、ユーザーは、特定のグループにメッセージをパブリッシュするの後端に権利があるかどうかを確認してください。
- その後、コンプライアンスのメッセージを確認するために、関連するサービスの数による人工知能のアプリケーションは、渡されたかどうかをチェックする、クラウドデータベースへのメッセージを保存していきます。
- 次に、プログラムは好きElasticsearch最適化検索ベースのデータ・ストレージ・サービスにメッセージを渡します。スポーツのAppは、クラブや他の機能の名称でより頻繁に言及された分析するために別のサービスデータ分析を追加することもできます。
- また、開発者は、要求の実現のため、モニタに添加することによって適用することができます。
- 最後に、スポーツのAppは、すべてのメンバーを思い出させます、このニュースは、ターゲットグループに投稿されました。
私たちが見てきたように、全体のプロセスは、彼らが数ミリ秒以内に完了している場合でも、少し長くすることができ、全体のメッセージ伝達チェーンは、まだ失敗の多くの潜在的なポイントが含まれています。チェーンの特定のサービスに障害が発生した後、さらに、その後、転送要求の全体のプロセスは間違っているだろう。
让我们再重新回顾一下上述对于请求检查的业务逻辑。其实，对于发布消息的用户来说，他既不会关心后台所执行的身份验证，又不太会注意消息的合规性，更不必知道消息是如何存储的，以及后台是如何保证每个组成员都能够收到新的消息。他只需关心自己的消息最终能否发布到目标组中。
因此，让我们来通过使用消息服务(Message Service)，来调整技术栈，以满足此类需求。新的技术栈所对应的系统架构如下图所示：
在上述架构中，当用户发布新的消息时，我们需要做的只是将其传递给消息服务。如果顺利完成，该消息会返回给用户成功的回执。全程只需几毫秒，这对应用方和用户端来说都是非常好的使用体验。
而在单独的请求中，应用服务会代替用户将对应的信任凭据和参数回传到Sports的后端服务器上。在此过程中，如果发生任何错误的话，我们只需事先设置好标准的错误响应代码，如“503：服务不可用”便可。同时，消息服务还会反复地重试该请求，直至它被成功传递、或7天后默认超时。
当然，您完全不必止步于此。通过使用消息服务，您可以更进一步地解决诸如：授权检查、或消息合规性检查等方面的问题。籍此，您可以逐步提高自己的应用所使用到的各项微服务的可靠性。
获取资料：
本次给大家分享一些学习资料，里面包括：（高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty，Redis，Kafka，Mysql，Zookeeper，Tomcat，Docker，Dubbo，Nginx等多个知识点的架构资料）以及Java进阶学习路线图。
领取方式，加微信号 weixing99ting 验证消息备注：资料 ，即可获取。
最后，祝大家早日学有所成！