フロントエンドはnginxである必要があるという意見がありますが、Goでバランサーを開発したと
述べました。
コメントで、人々は何でも空想できると感じています。 おそらく、誰かが私が違反だと考えており、Goにはバランサーが存在しません。 したがって、私はバランサーコードをすぐにレイアウトすることにしました。 このコードは、「特別な状況」で4時間で作成され、「全員」がギリシャにいたため、過負荷なしで2週間ほぼ同じ形式で動作しました。 コードは美しくなく、エラーも含まれていますが、機能し、バランスが取れているため、すでに価値がありました。
カットの下には、ほとんどオリジナルの筆記体バランサーがあります。 元の定数とCookieデコードコードを削除しました。
package main
このコードが書き直された後。 以前のパックのアイデアを実装しました。 サーバーへの接続数、統計、レポート、ルーティングテーブルを更新するためのAPIの制御のおかげで、常に機能する管理パネル用の別のポート（これによりユーザーは移行できます）。 そして現在、インスタンスの更新またはユーザーの移行のリクエストに遅延が発生しています。ベータ版には静的キャッシュ、リダイレクトキャッシュもあります。
ユーザー移行とは何ですか。 写真なしのメインユーザープロファイルは10 KB以下です。 サーバーAはユーザーをファイルにシリアル化し、ファイルは圧縮され、ファイルはサーバーBにコピーされます。バランサーは、このユーザーからの要求をサーバーBに送信するように指示されます。
Goとnginxを比較したいと思います。 明らかに、nginxは高速ですが、nginxが1つのコアで300 Mbpsまたは500 Mbpsのバランスをとり、50 Mbpsだけを移動する場合、同じDigitalOceanで5ドルのクラウドサーバー上の典型的な仮想ポートの速度を考慮すると、どのようにお金に変換されるのでしょうか？ Goが1 MBしかバランスできない場合はどうなりますか？ 比較して書く時間はありません。
誰かがベンチマークを作成することに決めた場合、応答サイズが異なるだけでなく、要求が遅延して処理される可能性があることも考慮することが重要です。 したがって、Goはインスタンスのシミュレーションに最適です。 http.NewRequestの代わりに、time.Sleepを配置します。 バランサーよりも1桁多いインスタンスが必要です。
PS Goに精通していない人向け。 Goは、この一見同期的なコードを非同期に変換し、非同期呼び出しを使用して単一のスレッドまたは複数のスレッドで実行できます。 nginxと同じように。 コンパイルにより、Goに依存しない実行ファイルが生成され、Goなしのマシンで実行できます。