さまざまなリアルタイム メッセンジャー アプリのアーキテクチャについて知りたいと思っています。汎用プロトコル/アーキテクチャを使用していますか?
3 に答える
Facebook が 190 億ドルで買収した WhatsApp Architectureでは、whatsapp の設計に関係するアーキテクチャについて説明しています。
これがリンクからの一般的な説明です
WhatsApp サーバーはほぼ完全に Erlang で実装されています。
バックエンド メッセージ ルーティングを行うサーバー システムは、Erlang で行われます。
非常に小さなサーバー フットプリントでアクティブ ユーザーの数が管理されていることは大きな成果です。チームのコンセンサスは、それは主に Erlang によるものだということです。
興味深いことに、Facebook チャットは 2009 年に Erlang で作成されましたが、資格のあるプログラマーを見つけるのが困難だったため、Erlang から離れました。
ejabberd から WhatsApp サーバーが起動しました
Ejabberd は、Erlang で書かれた有名なオープン ソースの Jabber サーバーです。
オープンであること、開発者からの評価が高いこと、開始が容易であること、および大規模な通信システムに対する Erlang の長期的な適合性が約束されていることから、最初に選択されました。
次の数年間は、ejabberd のかなりの部分の書き直しと変更に費やされました。これには、XMPP から内部で開発されたプロトコルへの切り替え、コード ベースの再構築といくつかのコア コンポーネントの再設計、サーバー パフォーマンスを最適化するための Erlang VM への多くの重要な変更が含まれます。 .
1 日に 500 億件のメッセージを処理するには、機能する信頼性の高いシステムを作成することに重点が置かれています。収益化は後で検討するものであり、はるか先のことです。
システムの健全性の主要な指標は、メッセージ キューの長さです。ノード上のすべてのプロセスのメッセージ キューの長さは常に監視され、あらかじめ設定されたしきい値を超えてバックログが蓄積されるとアラートが送信されます。1 つまたは複数のプロセスが遅れると、アラートが発生し、次のボトルネックを攻撃するためのポインターが提供されます。
マルチメディア メッセージは、送信する画像、オーディオ、またはビデオを HTTP サーバーにアップロードし、Base64 でエンコードされたサムネイル (該当する場合) と共にコンテンツへのリンクを送信することによって送信されます。
通常、一部のコードは毎日プッシュされます。多くの場合、1 日に複数回行われますが、一般的にトラフィックのピーク時は避けられます。Erlang は、修正や機能を製品に積極的に取り入れるのに役立ちます。ホットロードとは、再起動やトラフィックのシフトなしで更新をプッシュできることを意味します。通常、間違いはホットロードによって非常に迅速に元に戻すことができます。システムはより疎結合になる傾向があるため、変更を段階的にロールアウトすることが非常に簡単になります。
Whatsapp アプリで使用されるプロトコルは何ですか? WhatsApp サーバー プールへの SSL ソケット。クライアントが再接続してメッセージを取得するまで、すべてのメッセージはサーバーのキューに入れられます。メッセージの正常な取得は、このステータスを元の送信者に転送する whatsapp サーバーに送り返されます (メッセージの横に「チェックマーク」アイコンとして表示されます)。クライアントがメッセージを受け入れるとすぐに、メッセージはサーバーのメモリから消去されます
登録プロセスは、Whatsapp で内部的にどのように機能しますか? WhatsApp は、電話の IMEI 番号に基づいてユーザー名/パスワードを作成していました。これは最近変更されました。WhatsApp は、アプリからの一般的なリクエストを使用して、一意の 5 桁の PIN を送信するようになりました。WhatsApp は指定された電話番号に SMS を送信します (これは、WhatsApp クライアントを同じ電話で実行する必要がなくなったことを意味します)。暗証番号に基づいて、アプリは WhatsApp に一意のキーを要求します。このキーは、今後のすべての呼び出しで「パスワード」として使用されます。(この「永久」キーはデバイスに保存されます)。これは、新しいデバイスを登録すると、古いデバイスのキーが無効になることも意味します。
WhatsApp は、エラーに耐えるように設計されたスケーラブルなアプリケーションを作成するために構築された言語である Erlang を選択しました。Erlang は同時実行性のために Actor モデルと呼ばれる抽象化を使用します - http://en.wikipedia.org/wiki/Actor_(programming_language)従来の共有メモリ アプローチの代わりに、アクターは互いにメッセージを送信することで通信します。スレッドとは異なり、アクターは軽量になるように設計されています。アクターは同じマシンまたは異なるマシンに存在する可能性があり、メッセージ パッシングの抽象化は両方で機能します。WhatsApp の単純な実装は次のようになります。各ユーザー/デバイスはアクターとして表されます。このアクターは、ユーザーの受信トレイ、ディスクへのシリアライズ方法、ユーザーが送信するメッセージ、およびユーザーが受信するメッセージを処理する責任があります。Alice と Bob が WhatsApp の友達だとしましょう。つまり、アリスの俳優とボブの俳優がいます。
前後に流れる一連のメッセージをたどってみましょう。
Alice は Bob にメッセージを送ることにしました。Alice の電話は WhatsApp サーバーへの接続を確立し、この接続が間違いなく Alice の電話からのものであることが確立されます。Alice は TCP 経由で次のメッセージを送信します。WhatsApp フロント エンド サーバーの 1 つがこのメッセージをデシリアライズし、このメッセージを Alice というアクターに配信します。
俳優のアリスは、これをシリアル化し、「アリスの送信済みメッセージ」というファイルに保存することを決定しました。これは、予測不能なモンスターの暴走によるデータ損失を防ぐために、複製されたファイル システムに保存されます。次に、俳優のアリスは、「アリスからのメッセージ 1: 巨大なモンスターがゴールデン ゲート ブリッジを攻撃しています」というメッセージを渡すことで、このメッセージを俳優のボブに転送することにしました。アクターのアリスは、アクターのボブがメッセージの受信を確認するまで、指数バックオフで再試行できます。
アクターのボブは最終的に (2) からメッセージを受け取り、このメッセージを「ボブの受信箱」というファイルに保存することにします。このメッセージを永続的に保存すると、Bob アクターは、"I received Msg1" という独自のメッセージをアクター Alice に送信することで、メッセージの受信を確認します。アクターの Alice は、再試行の試みを停止できるようになりました。俳優のボブは、ボブの電話がサーバーにアクティブに接続されているかどうかを確認します。そのため、アクターであるボブは、このメッセージを TCP 経由でデバイスにストリーミングします。
ボブはこのメッセージを見て、「アリスのために、彼らと戦うために巨大なロボットを作ろう」と返信します。これは、ステップ 1 で概説したように、アクターのボブによって受信されます。次に、アクターのボブは、ステップ 2 と 3 を繰り返して、アリスが最終的に人類を救うアイデアを確実に受け取るようにします。
WhatsAppは実際には、上で概説した非常に優れたプロトコルではなく、XMPPプロトコルを使用していますが、要点はわかります.
私の知る限り、Ejabberd ( http://www.ejabberd.im/ ) が親であり、これはオープン ソースの非常に優れた機能を提供する XMPP サーバーです。Whatsapp はこれの修正バージョンを使用し、Facebook メッセージも修正バージョンを使用します。これ。Samsung の ChatOn や Nimbuzz メッセンジャーなどのチャット アプリケーションはすべて ejabberd ベースのアプリケーションを使用しており、Erlang ソリューションもこの ejabberd の修正版を使用しており、拡張性が高く、十分にテストされてパフォーマンスが向上し、MongooseIM に名前が変更されていると主張しています。
Ejabberd は、他のサーバーと比較して、ほとんどの機能が実装されているサーバーです。Erlang でビルドされているため、水平方向に高度にスケーラブルです。