昨年9月、リアルタイムメッセージング用のオープンソースサーバーであるCentrifugeに関する最後の記事が公開されました 。 現在、この投稿が公開されているハブのリストに、Goがあります。 そして、正当な理由で、タイトルからすでに理解できるように、CentrifugeはPythonからGoに移植されました-これがCentrifugoの登場です。 移行の理由、Goの長所と短所、および以前の出版以降プロジェクトがどのように進化したかについて-猫の下で読んでください。



ポスト（そして、明らかに、後の人生）で、サーバーを一般的にCentrifugeと呼びます。異なる言語での実装の違いを強調する必要がある場合は、英語版-PythonバージョンのCentrifuge、Centrifugo-Goバージョンを使用します。



遠心分離機について簡単に説明します。 これは、アプリケーションのバックエンドの隣で実行されるサーバーです。 アプリケーションユーザーは、WebsocketプロトコルまたはSockJS polyphileライブラリを使用してCentrifugeに接続します。 接続してログインすると、彼らは興味のあるチャンネルを購読します。 アプリケーションバックエンドが新しいイベントについて学習するとすぐに、（RedisのキューまたはHTTP APIを使用して）Centrifugeの目的のチャネルにイベントを送信し、接続されたすべての関心のあるユーザーにメッセージを送信します。







したがって、Centrifugeは、多くのWebアプリケーションのバックエンドが記述されている多くの最新の一般的なフレームワーク（Django、Ruby on Rails、Laravelなど）の問題を解決します。 バックエンドが非同期で動作できず、リクエストを処理するワーカーのプールが制限されている場合、クライアントからの永続的な接続の処理により、このプールがすぐに使い果たされます。 もちろん、開発に必要な作業量を減らすためだけに、Centrifugeを使用して非同期バックエンドとペアにすることを妨げるものは何もありません。



遠心分離機のような多くの解決策があり、以前の記事でそれらのいくつかを言及しました。 主な特徴は次のとおりです。

• アプリケーションバックエンドが記述されている言語の独立。
• SockJSの使用：何らかの理由でブラウザーがWebsocket接続を確立できず、フォールバックトランスポート（eventsource、xhr-streaming、xhr-pollingなど）を介して新しいメッセージを受信できないすべてのユーザーを許可します。
• 署名付きトークン（HMAC SHA-256）の使用に基づくユーザー認証。
• 大根に関連するいくつかのプロセスを実行する機能。
• チャネル内の現在のユーザーに関する情報、チャネル内のメッセージの履歴、ユーザーによるチャネルへのサブスクライブまたはチャネルからのサブスクライブ解除に関するメッセージ。 ほとんどのPUB / SUBソリューションは、新しいメッセージのみを送信できます。
• 展開のための完全な準備：rpm、Dockerfile、Nginx config; また、現在、すべてのプラットフォーム用のバイナリファイルの形式でリリースされています。

以前は、遠心分離機の主な目的はWebアプリケーションでのインスタントメッセージングであることを強調していました。 おそらく「web」という接頭辞は、プロジェクトの可能性を少し隠しています。Websocketプロトコルを使用して、モバイルアプリケーションからCentrifugeに接続できます。 これは、オープンソースコミュニティの一部のユーザーによって確認されています。 しかし、残念ながら、モバイルデバイス、つまりJavaまたはObjective-C / Swiftのクライアントはありません。 Goへの移行は、さまざまな環境からの使用にサーバーを適応させるためのもう1つの小さなステップです。 しかし、まず最初に。 なぜ行くの？ これにはいくつかの理由がありました。

Goへの移行の利点

性能

GoがCPythonよりも大幅に高速であることは秘密ではありません。 そして、Centrifuge on Goはずっと高速になりました。 例を挙げます。 遠心分離機を使用すると、1つのHTTPリクエストで多くのコマンドをAPIに送信できます。 チャンネルに公開する必要がある新しい投稿を1000件含むリクエストを送信しました。 結果を見てみましょう。

Centrifuge: 2.0    ,      Centrifuge: 17.2 ,    100  Centrifugo: 30 ,    (x15) Centrifugo: 350 ,    100  (x49)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それでも、1000メッセージは非標準的な状況です。ここでは、1つの新しいメッセージをチャネルに送信した結果を示しています。

 Centrifuge: 3 ,  0    Centrifuge: 160   1000    Centrifugo: 200 ,  0    (x15) Centrifugo: 2.0   1000    (x80)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

数値はMacbook Air 2011で取得されたものです。クライアント接続は同じマシンから人為的に作成されたものであり、回答が完了しても、メッセージが既にクライアントに到着したわけではありません。 ところで、メッセージの投稿に使用するコードは次のとおりです。

 from cent.core import generate_api_sign import requests import json command = { "method": "publish", "params": {"channel": "test", "data": {"json": True}} } n = 1000 url = "http://localhost:8000/api/development" commands = [] for i in range(n): commands.append(command) encoded_data = json.dumps(commands) sign = generate_api_sign("secret", "development", encoded_data) r = requests.post(url, data={"sign": sign, "data": encoded_data})
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、すべてのサーバーコンポーネントでこのようなパフォーマンスの向上が見られるわけではありませんが、絶対にすべてが高速になっています。 Centrifugeリポジトリには、1つのチャネルにサブスクライブされた多数の接続を作成するベンチマークスクリプトもあります。 購読すると、メッセージがチャネルに送信され、すべての顧客がメッセージを受信するまで時間が計算されます。 この時間の上限を200ミリ秒でとると、サーバーがこのようなチャネル/クライアントの分散で正常に処理できる同時接続の数が約4倍になりました（私のラップトップでは4000から14000）。 繰り返しますが、すべてのクライアントは同じマシンから同じスクリプト内で作成されるため、この評価に偏りが生じる可能性があります。

マルチコア

Goでは、複数のコアを同時に使用する単一のプロセスを実行できます。 Tornadoの場合、いくつかのCentrifugeプロセスを実行し、それらの前でNginxをバランサーとして使用する必要がありました。 これは機能しますが、Goを使用するとはるかに簡単になります。マシンの利用可能な電力を活用するプログラムを作成します。 しかし、魔法はありません。プログラムコードは、Goランタイムがプロセッサコア間で作業を分散できるようにする必要があります（ https://golang.org/doc/faq#Why_GOMAXPROCS ）。

配布

Goのアプリケーションは、Goの出力によりプログラムに静的にリンクされた1つの実行可能ファイルを取得できるため、配布が簡単です。 ダウンロードして実行-動作します！ 依存関係がなく、Pythonのvirtualenvをwarマシンにドラッグします。 もちろん、Mail.Ru Groupでは、ファイルを戦闘にコピーするのではなく、アプリケーションごとにrpmを作成します。 しかし、rpmの作成もはるかに透過的で、シンプルで高速です。 上記に加えて、Goではさまざまなプラットフォームのコードをクロスコンパイルできます。これは驚くほど便利な機能です。 ほとんどの場合に必要なのは、バイナリファイルが必要なプラットフォームとアーキテクチャを示すことです。

言語に組み込まれた並行性モデル

デフォルトの組み込みGo並行性言語により、利用可能なすべてのライブラリと言語ツールを使用して非ブロッキングコードを記述できます。Tornadoesの場合のように、非ブロッキングライブラリを探す必要はありません。 たとえば、頭痛の種の1つは、大根の非同期クライアントでした。 公式のredis-pyをすぐに忘れることができます。 トルネードに多かれ少なかれ生きていて、トルネードリディスとトレディスの 2つが見つかりました。 当初、tornado-redisを使用する予定でしたが、 バグが存在するため、私には適していませんでした。 その結果、Pythonバージョンではtoredisが使用されます。 彼は非常に優れていますが、それへの道は厄介でした。



Goでは、ネットワークコールとシステムコールを使用した非同期動作が言語の基盤です。 ランタイムスケジューラは、呼び出しをブロックするゴルーチン間、またはゴルーチンが機能するために割り当てられた特定の最大時間後にコンテキストを切り替えます。 一般に、これはすべて、GeventとTornadoである程度機能するように見えますが、箱から出してすぐに使用できることは大きな幸福です。

静的型付け

現時点では、静的な型付けが動的な型付けよりも優れていると言っているわけではないことに注意してください。 しかし！ 静的型付けのおかげで、コードの変更がはるかに簡単になりました。 確かに、これはPythonの後の最も顕著な発見の1つでした。リファクタリングは大幅に簡素化されました。 コードが変更を加えた後にコンパイルされた場合、正しく動作するという追加の保証があります。



リストされた項目は、移行が合理的であることを確認するのに十分であるように思えます。 プロセスで見つかった他のプラスがありました。 Goコードのテストは簡単です。バージョン1.5は、JavaまたはObjective-Cから使用する共有ライブラリを作成する方法を提供します。組み込みユーティリティを使用すると、ゴルーチンリークを追跡できます。

Go移行の短所

もちろん、このような移行の欠点を評価する必要がありました。 たとえば、Pythonバージョンで何をするか：完全に互換性のあるGoバージョンを作成し、リポジトリ内のコードを置き換えるか、別のプロジェクトにしますか？ プロジェクトへのインターネットリンクをすべて同じように置き換えるのは魅力的でしたが、その名前には大きな意味がありました。 常識から、何を別に行う必要があるかが示唆されました。 最後に、CentrifugeとCentrifugoがあります。 そして、私はそれが非常に良いとは言いません、それは紛らわしいです。



2番目のポイント：オープンソースソリューションを使用する開発者が、このオープンソースアプリケーションが記述されているプログラミング言語と同じ言語を使用している場合、それを見つけるのははるかに簡単です。 それでも、誰が言っても、PythonコミュニティはGoコミュニティよりも大きいです。 これを犠牲にしなければなりませんでした。



さらに、この言語は私にとって新しいものなので、古いレーキに再び足を踏み入れるか、新しいレーキを見つける機会がありました（今でもそうです）。 しかし、プログラマーを止めることはありましたか？ それどころか！



Go言語自体には欠点があります。 通常不満を言う主なものを見てみましょう：

• ジェネリック医薬品の不足。 はい、そうではありません。 その結果、リポジトリに2つのデータ構造があります。理論的には、Goがジェネリックをサポートしている場合、他のプロジェクトで再利用できます（別のリポジトリから既製のものを取得することもできます）。 これは、文字列でのみ機能するメモリ内fifoキューおよび優先度ヒープキューです。 おそらくジェネリックがあるでしょう-それは良いでしょう。 しかし同時に、それが本当に私を悩ますとは言いません。 私が理解しているように、Go言語の著者はこの質問を未解決だと考えています。 おそらく将来的には、ジェネリックを言語に追加する正しい方法を見つけることができるでしょう。
• エラー処理。 Goには例外はありません。関数/メソッドから明示的にエラーを返すのが習慣です。 私の意見では、これは非常に主観的なマイナスです。 たとえば、私はそれが好きです。 何らかの個人的な理由で、例外を引き起こす代わりにコルーチンの実行の結果として、竜巻でそうしました。 私にとって便利です！ しかし、Pythonで言語の実践に関して不自然に思える場合、ここではできません。

移行

Python遠心分離機は、 Tornado 、 Toredis 、 Sockjs-Tornadoなどのいくつかの主要なライブラリに基づいて構築されています。 したがって、Goで類似体を見つける必要がありました。 Tornadoの代わりに、言語自体が直接作用し、Redisと連携するためにRedigoが使用され、SockJSサーバーの素晴らしい実装も見つかりました。 一般に、PythonからGoに移行するという決定が下され、メインコードベースの書き直しは仕事の後の夕方に約3か月かかりました。 移行プロセスが、プロジェクトの設定と名前空間を保存するためのバックエンドを削除したいという私の希望と一致したことがたまたま起こりました。 プロジェクトに関する以前の記事を読んだ場合、おそらく知っているでしょう：以前は、これらの設定は、バックエンドを記述して使用する機能を備えたJSONファイル、SQLite、MongoDB、またはPostgreSQLから選択するために保存されていました。 SQLiteがデフォルトの選択でした。 これはおそらく間違いでした。 設定が変更されることはめったにないので、データベースを保持することはまったく意味がありません。 その結果、構成ファイルのみを使用するようにすべてを作り直し、あらゆる種類のバックエンドを取り除きました。



構成ファイルをJSON、YAML、またはTOML形式で作成できるようになりました-すばらしいViper Goライブラリのおかげです。 一般に、Viperは複数の形式をサポートするのが得意であるだけでなく、その主なタスクはさまざまな場所から適切な優先度で構成オプションを収集することです。

• デフォルト値
• 構成ファイルの値。
• 環境変数から。
• リモート構成ソース（Etcd、Consul）から。
• コマンドライン引数から。
• アプリケーション自体の操作中に明示的に指定されます。

したがって、ライブラリにより、アプリケーションの非常に柔軟な構成が可能になります。



発生した移行の難しさのうち、次の点に注意してください。

1. インターフェイス{}およびマップ[string]インターフェイス{}を頻繁に使用します。 すぐではありませんが、代わりに厳密に型指定された構造を使用して、徐々に取り除くことができました。 ところで、これはノード間の通信の内部プロトコルとクライアントとの通信プロトコルを順番にもたらすのに役立ちました。 何がどのタイプで送信されるか、または送信されるべきかは明確です。
2. 異なるゴルーチンからデータにアクセスするときに起こりうる競合状態。 それらのほとんどは、Goレースディテクタを使用して検出されました。Goレースディテクタは、同期の手段によってさまざまなゴルーチンからのデータへの保護されていないアクセスのすべてのケースをコンソールに出力します。 Goの同期ツールから、チャネルと、同期およびアトミックパッケージのプリミティブを使用できます。

Klaus Post氏から大きな助けがありました。彼はいくつかの競合状態を発見し、コードのスタイルの欠陥を指摘し、非常に有用なプルリクエストを行いました。



書き換え中に既に開いている別の興味深いGo機能があります。 これは、JavaおよびObjective-CのパブリックライブラリAPIで動作するようにGo 1.5で導入された共有ライブラリを作成するためのサポートです。 おそらくこれがiOSとAndroidのクライアントを作成する道ですか？ 移行中に、 ドキュメントは完全に書き直されました。 現在、すべてのCentrifugo関連プロジェクトを包含およびリンクしています。 これは、サーバー自体、javascriptクライアント、HTTP APIクライアント、Webインターフェイスです。 ちなみに、以前はTornadoで記述され、サーバーコードとともにリポジトリに直接配置されていたWebインターフェイスは、現在は独立しており、ReactJS（ https://github.com/centrifugal/web ）の1ページアプリケーションです。 注意GIF：







CentrifugeのPythonバージョンは、現在Goバージョンとほぼ完全に互換性があります。 違いはごくわずかですが、今後は不一致がさらに強くなり、Centrifugeに新しい機能を追加する予定はなく、見つかったバグを修正するだけです。



ほぼ2か月間、私たちはMail.Ru GroupイントラネットでCentrifugoを使用してきましたが、これまでのところ問題はありません。 負荷はわずかです。1日平均550人の同時接続ユーザー、平均約50のアクティブチャネル、1分あたり約30のメッセージです。 Centrifugoを起動して試す​​には、システムのバイナリリリース（ https://github.com/centrifugal/centrifugo/releases ）をダウンロードできます。RPMおよびDockerイメージをビルドするための仕様があります。



私はよく2つの質問をされます。 1つ目は、大根がある場合に遠心分離機を使用する必要がある理由です。 第二に、何人のユーザーが単一の遠心分離機インスタンスを立てることができますか？ 最初の質問は奇妙であり、答えは次のとおりです。もちろん、Centrifugeを使用することはできませんが、最初からプロジェクトで利用できる多くのことを実現する必要があります。 一見、これは単純に思えるかもしれませんが、悪魔は細部に宿っています。 そして、これらのささいなことはまともで、ブラウザクライアントのコードから始まり、展開で終わります。 遠心分離機では、実際に使用される多くの問題がすでに解決されています。 彼女はすでに戦闘でのテストに成功しています。 たとえば、彼女はMail.Ru Groupで従業員向けのインタラクティブゲームを実施することを許可しました。約50人の参加者がモバイルデバイス（ラップトップ、タブレット、携帯電話）を持って来ました。 誰もがゲームに接続し、リアルタイムで画面上の質問、ラウンド結果、ゲーム統計を受け取ることができました。 同時に、ホストは実際に誰がオンラインであるかを確認し、ゲームの開始時に人々を整理するのに役立ちました。 2番目の質問への答え：わかりません。 知りません。何万もの同時接続を接続でき、すべてがうまく機能するからです。 ただし、同時に、ハードウェア、接続数、チャネル数、チャネル内のメッセージ数など、多くの要因が全体的なパフォーマンスとスループットに影響します。 この質問に対する答えは、適切な評価と監視を提供することのみです。



さらなる目標は次のとおりです。

1. 私はObjective-C / SwiftまたはJavaのどちらも知らないので、AndroidとiOSで使用するクライアントは、概して、オープンソースコミュニティまたはGoの共有ライブラリに希望を持っています。
2. 指標。
3. シャーディング？ Redisクラスター タランツール？

そして、結論のいくつかのリンク：

• Heroku Webベースのデモ（デモパスワード） centrifugo.herokuapp.com
• 例のあるリポジトリgithub.com/centrifugal/examples
• fzambia.gitbooks.io/centrifugal/content documentation

Githubのリポジトリの記事にあるgopherを含む PSイメージ： github.com/hackraft/gophericons



PSS私はまた、ハブユーザーのmercとsl4mmerに感謝します。 彼らはプロジェクトの開発に多大な貢献をしてくれました。