まず、+問題の難しさを解決します
どのようなビジネス上の問題を解決します
（1）エンドクラウドリアルタイムの報告要件：58高速輸送ドライバーの終わりには、リアルタイムのレポートをGPS
（2）クラウド・ツー・エンドのリアルタイムのプッシュ需要：リアルタイムのプッシュで58高速トランスポートドライバの注文
（3）エンド・ツー・チャットメッセージのニーズを：チャットユーザ間の通信、企業、顧客サービス
難易度：
無線環境における（1）到達可能性メッセージAPP
（2）ユニバーサル、プラットフォームとビジネスを分離しよう
第二に、潜在的な不足と伝統的なソリューション
[終了クラウド：HTTP世論調査ではGPSニュースサービスを報告しました
オプション1：直接業務WebサーバのDBの行で書かれました
オプション2：ユニバーサルWebサーバ層はビジネスサービス層書き込みDBを起動します
潜在的な欠陥：
ハイ（1）のhttp短い接続コスト（繰り返し接続を作成し、破壊します）
（2）特定のWebサーバの下層（毎秒千のレベルの処理要求）
[最後にクラウド：サードパーティ製のプッシュまたはプッシュサービスを通じて]
プログラム：のAPNまたは他のサードパーティのプッシュプッシュMによって
オプション2：自分のサービス構造のMQTTを通じてプッシュします
潜在的な欠陥：
（1）サードパーティのアクセシビリティと適時性は、第三者が制限速度をプッシュされることを保証することはできません
（2）MQTTの可用性が問題です
エンド[：]上記の2つの方法で
伝統的なプログラムは、多くの場合、問題をプッシュするために、リアルタイムのニュースの組み合わせを解決するために、[終了]を[最後に結合することによって、雲] [雲]を終了することができます。
第三に、ユニバーサルインスタントメッセージングプラットフォームの詳細
ビジネス分析と抽象化：ドライバー、ユーザー、ビジネス、顧客サービスは、「オンライン」事業
[終了クラウドの最適化]
潜在的な問題の従来のソリューション：HTTPポーリング非効率的な、限定されたWebサーバのパフォーマンス
TIPSの最適化：TCP長いリンクを使用してインターネットメッセージ（上）
潜在的な問題：アプリケーション・サーバーのメッセージングプラットフォームは、サービスライン、配信されたメッセージを配信するビジネスの新しい行を追加するためのビジネスライン型スイッチケースの必要性と相まっては、RPCコールを（上記の）必要があります
TIPSの最適化：メッセージMSG-キューバスデカップリングを使用した（下記参照）
見ることができ、メッセージ・バス、新しいメッセージの送信者、メッセージのプラットフォームのみメッセージタイプとメッセージバステーマ間のマッピングを設定する必要があるの使用は、新しいアプリケーション・サーバーの消費者は、新しいトピックを購読することができ、およびメッセージサービスプラットフォームを実装しますデカップリング。
[クラウド・ツー・エンドの最適化]
潜在的な問題：サードパーティの制限速度と可用性の問題
最適化のヒント：自分のクラスタを提供するプラットフォームメッセージングRPCインターフェイスを提供し、「クラウド・ツー・エンドの、」ニュースチャンネル
ここで注意すべきであるデカップルビジネスするために、メッセージ・バスを使用して、「エンド・クラウド」。「クラウド・ツー・エンドの」RPCインターフェイスとして使用するだけでなく、デカップルサービス、メッセージのプッシュ新しいパーティのインターネットメッセージにコードを変更せずに。
潜在的な問題：多くのドライバーが受注に返事を押していない、予想より低いシングルレートをつかみます
最適化のヒント：リアルタイムの保管状況の紹介、「オンライン」の状態のみユーザーはメッセージをプッシュ
[終了]の最適化
ビジネス関連の場合は、直接TCPチャネルを通じて配信、トラフィックが関連する場合、送信元プロセスサービスサーバー「クラウド・ツー・エンド」の配信（RPC）への逆転最初（MQを介して）「クラウドエンド」の配信を、その後、受信者。
潜在的な問題：受信者がオンラインでない場合はどのように行うには
最適化のヒント：DB増加ストレージオフラインメッセージ
潜在的な問題：多くの場合、不安定な無線ネットワーク環境は、（例えば、ネットワークオフエレベーターの外に）、メッセージが頻繁に失われます
最適化のヒント：ニュースのデータベースプラットフォームは受信機は、アプリケーション層のACKを受信した後、メッセージ一階を受信し、損失なしていることを確認するために、削除
図（図2ここでは、最も重要なものの一つ）として、全体としてのメッセージ配信プロセス。
（1）メッセージの送信、インターネットにメッセージを送ります
（2）最初のメッセージ着陸プラットフォームメッセージDB
（3）インターネットメッセージ送信成功の応答メッセージの送信者（この場合は関係なく、受信者が受信したかどうかの）
同時に、（3）、（オフライン・ストレージへのオンラインでない場合）、受信者へのメッセージ配信に平行
（4）受信者は、アプリケーション層メッセージからACKを受信しました
（5）メッセージのメッセージングプラットフォームを削除
（6）広告ACKの受信機は、既に正常に処理されています
それは「の問題を解決するために、最大のアプリケーション層のACKメッセージ」を使用して見ることができます
潜在的な問題：メッセージングプラットフォームの第三段階を受けていない送信者どのように行うために返信？
TIPSの最適化：送信（サーバステートレス）からの再送
潜在的な問題：受信者が行う方法の冗長メッセージの再送を受けましたか？
TIPSの最適化：重複排除受信機（完全にステートレスサーバーを行うことができ、配信メッセージは単純であることができます）
階層化アーキテクチャ[解説]
上述したように、図は、（図1の本明細書で、最も重要な2本のビス）システムのアーキテクチャを積層、全体のメッセージングプラットフォームシステムは、から構成されています。
APPプラットフォームメッセージMSG-SDK（1）、ハンサムAPPへのインターフェースを提供
（2）MSG-ゲート、TCPメッセージ全体のアクセスポータルプラットフォーム、長いTCPコネクションを保持し、最初の攻撃と防御、暗号化と復号化、圧縮と解凍
パート（3）MSG-ロジック、メッセージ全体の処理プラットフォームロジック
（4）のRedis、クラスタストレージの可用性は、オンライン、オンライン/オフラインのユーザーをRedisの、そしてMSG-ゲート（オンラインの場合）ユーザアクセス
（5）DB、格納されたメッセージをオフライン
いくつかの非メッセージングプラットフォーム事業セクション：
（1）APP：APPパーティサービスは、メッセージmsg-SDKにアクセスするためにインターネットを介して、複数があるかもしれません
（2）MQ：インターネットメッセージサービスサーバに「エンド・クラウド」のパーティーには、MQ経由でメッセージを送信します
（3）アプリケーションサーバ：ビジネスの後端側に、RPCを介して「クラウド端に」メッセージを送信することにより、「終了クラウド」MQメッセージを複数の受信があってもよいです
[外部に設けられたインターフェイスの説明]
が提供するサービスのためのインタフェースメッセージングプラットフォームいくつかの非常に一般的なインターフェース。
APPのためにMSG-SDKが提供するコアインタフェースです。
（1）ログイン：インターネットアクセスメッセージ
（2）ログアウト：ログアウトメッセージングプラットフォーム
（3）C2S：「クラウドエンド」クライアントをサーバに送信するメッセージ
（4）C2C：クライアント「終了」のメッセージをクライアントに送信します
（5）GET-オフラインメッセージ：メッセージをオフに引っ張っ
（6）上の-MSG-受け取っ：コールバック・メッセージは、コールバックインターフェースを受け
アプリケーション・サーバー・メッセージングプラットフォームを提供するために、コアインタフェースを以下のとおりです。
（1）S2C：クライアントにサーバーを送信する「クラウド・ツー・エンド」のメッセージ
その他の事業側は懸念する必要はありませんされMSG-SDKとメッセージングプラットフォーム間の内部インターフェイスは、次のとおりです。
（1）キープアライブ：メッセージmsg-SDK保持台（透明サービス側）と接続するため
（2）C2C-ACK：アプリケーション層のACK C2Cインターフェイスへのユーザー・インターフェース（透明ビジネスパーティー）
[クロスアカウントのチャットシステムを実装する方法]
それが（欲しい欲しいQQでチャットする方法、である）アカウントシステム全体にメッセージを送信する方法を、一般的なメッセージングプラットフォームですので、？
解決策：システム全体のキーとしてドメイン+ UID、あるいはAPPID + UIDを使用しながら、UIDは、もはや、システム全体を実行するためのキーとして使用されていません
潜在的な結合点：このような場合は、処理ロジックは、プラットフォームインターフェースメッセージング、異なるログイン認証にログインスイッチケース（ドメインまたはのAppID）を必要とし、サービスが特定の結合を有するが、新しいアカウントシステム周波数はより低く、新しいメッセージタイプの低
[拡張プロトコルの設計]
バージョンアウトプットは、回復することは困難になるとAPPは、基本的にCSアーキテクチャである、それは歴史的遺産APPそれにも簡単に適合しながら、どのように、新機能の操作を行い、困難BSのためにはるかに多くの互換性のあるシステムアーキテクチャが必要ですか？
インタフェースの利便性を向上させる方法（1）？
溶液：+プロトコル用途固定長ヘッダ介在物がCMDを拡張する新しいインタフェースのコマンド番号を使用して、長くなる[この変更は、サービス層に透明である、メッセージmsg-SDKインターネットとの間の問題です]
（2）同じインターフェイスについては、APPの古いバージョンに影響を与えることなく、パラメータを増加させる能力？
溶液：例えばprotobuffer、拡張可能シリアル化プロトコルを使用して、[ビジネスのこの事クリアラインをprotobuffer]
（3）ビジネス面では、メッセージタイプの多くの種類があり、多くの複雑なビジネスニーズは、メッセージングプラットフォームの複雑さと、古いバージョンのAPPとの互換性を増加させることなく、その中のビジネスのスケーラビリティを確保する方法がありますか？
例えば、事業ラインは、このような潜在需要があるとします。
a）のプッシュメッセージを操作します
B）プッシュメッセージコンテンツのサポートフォント、フォントサイズ、太字、色
絵プッシュメッセージのためのC）のサポート
d）のビジネスサポート「ウィンドウショック」と「相手がタイピングで......」と他のニーズ
溶液：そのようなXML / JSONスケーラブルな複数のメッセージ・タイプをサポートするように使用する（透明なプラットフォームメッセージングのための）メッセージ本体スケーラブルプロトコル、および旧バージョンとの互換性APP
<MSG>
<タイプ> 1 </タイプ>
<フォンド>斜体</ FONT>
<内容>こんにちは、世界！</コンテンツ>
<PIC> http://pic.daojia.com/hello.jpg </ PIC>
</ MSG>
契約のこのニュースでは、それを確認するために：古いバージョン、メッセージングのための透明なプラットフォームとの互換性、スケーラビリティ、および他の多くの利点を、それを強くお勧めします
第四に、分散アーキテクチャの詳細
申し訳ありませんが、ホストリマインダ時間がそれを分散アーキテクチャ図を入れて、ライン時および共有に分散アーキテクチャのスケーラビリティ、ロードバランシング、可用性、整合性の問題のために来ています：
<広告>
メッセージはプラットフォームにはほとんど関心がまだあることを示し、ここまで読めば、プラットフォーム58ホームニュースチームが一つだけの学生、崇高な理想を持つ人々の不足が参加することを歓迎します。
いくつかの説明：ベース北京、コアチーム、技術指向、Javaの方向、および58シェンジェンのチーム
方法参加：（2）下記の記事で（1）ダイレクトメッセージの公開鍵番号取得に参加する「リクルート」を返信
</広告が完了しています>
V.の概要
（1）「エンド・クラウド」メッセージ配信：TCPメッセージチャネル、メッセージバストラフィックのデカップリング
（2）メッセージ配送「クラウドの末尾に」 RPCインターフェースを提供する、状態記憶の導入：
（3）メッセージ配信手順以下「エンドツーエンド」。
（4）「エンドツーエンド」のメッセージ配信能力を
a）の損失に対するオフラインメッセージを事前に既存の
までの保証とb）のACKメカニズム
C）メッセージの送信者の再送
d）のパーティメッセージの重複除外を受けます
（5）拡張プロトコルの設計とすることができます
インタフェースを増加させる任意の時点でそれら）固定長ヘッダ、可変長パケット
B）プロトコル・インターフェースの拡散シーケンスは変更の対象となっています
C）メッセージプロトコルは、種類を増加する準備ができて拡張することができます
（6）クロスシステムチャットアカウント（複数のドメイン）をサポート：使用して、ドメイン（又はAPPID）+ UIDを包括キーとして
（7）は、図1のようなアーキテクチャを層状。
