PHP + MySQL は本当に大雑把で難しい組み合わせです

私は長い間休眠していて、いくつかの大きなプロジェクトで忙しかったです。

いくつかのプロジェクトの内容はそれぞれ大きく異なりますが、いずれも支払いと決済に高い精度が要求されます。そのうちの 1 つは大量のリアルタイム同期データを持っています。

金額はどれくらいですか？平均すると、1 秒あたり 30 個の更新データが取得されます。この 30 個のデータにより、実際には約 200 個のデータの比較と更新が行われます。昨年の 9 月と 10 月頃にこのプロジェクトの準備をしていたとき、PHP + MySQL ではこのタスクを実行するのは難しいと主観的に感じていました。一度、.net、Java、Scala、golang、および pgsql、sqlserver などのさまざまなデータベースを試しました。私たちは多くの調査とテストの準備を行い、最終的に Scala ソリューションを選択しました。しかし、実際に使い始めると、静的言語の特性に非常に不快に感じました。特にサーブレットコンテナは更新されるたびにリロードしなければならないので、この点で私は本当に動的言語に甘やかされているのかもしれません。言語。

最初の段階で、リファクタリングして改善したコードをいくつか書きました。そのため、プロジェクト全体を変革するために静的言語を選択する計画を断念することにしました。システム ビジネスのオンライン部分は大きすぎて、多くのビジネス ロジックがあるため、以前に開発された PHP バージョンは非常に堅牢かつ完全な方法でカプセル化されています。それを変換することに私が納得できる唯一の点は、パフォーマンスです。言語間の違い。いくつかの比較、特にサーブレットの実際のデプロイと更新と既存の PHP との比較を行った後、機能リストを比較し、各機能を実際にテストしてサーブレット モードと PHP モードを比較し、最終的には諦めることにしました。プロジェクト全体を変換するには、静的言語ソリューションを選択します。

Web システムの構築において、PHP の動的更新のサポートは、既存のすべての Web 開発言語の中で最大の利点となる可能性があります。 Ruby、node.js、golang、および Java は、せいぜいテンプレートを動的に更新することしかできません。リリース モードでは、クラス ライブラリ ファイルは呼び出されたときに所定の場所にロードされるか、リリースされないか、バイナリ ファイルにコンパイルされて事前にロードされます。

復興計画を断念した後は、考え方を変える必要があります。当初のアイデアは、Web をシステムの中核として使用することでした。変革の当初の目標の 1 つは、Web が一部の操作やタスクをより積極的に実行できるようにすることでした。しかし実際には、ビジネスロジックレベルでは問題ないため、最初の段階でPHPで開発したコードを破壊したり再構築したりしたくありません。開発された Web を WebService ポイントとして完全に考えることができます。残りは、複数のサービス ポイントをデプロイし、外部データ インターフェイスを WebService に接続し、WebService にこれらのサービスの管理と監視を開始させるだけです。

一般的な状況は次のトポロジ図のようなものです:

各外部サービスには、独自の操作を実装するための最小限のプログラム ロジックのみが含まれており、コアとなるビジネス ロジックは WebService に引き渡されます。さらに、サービスは相互に通信しません。お互いの存在を認識する必要はありません。必要に応じて追加、展開し、いつでも更新する必要があります。彼らはタコの触手に似ていますが、より具体的な機能とタスクを持っていますが、単にさまざまなタスクを正確に実行するだけです（特に時間の誤差はありません）。

このアイデアを決定したとき、私はその実現可能性を正確に知りませんでした。この環境のコアリンクは WebService の容量であり、これは私にとって最も不確実なことでもありました。しかし時間が経てば経つほど、もう選択肢はありません。外部サービス部分については、npm の豊富さと js の知識を考慮して、node.js を選択しました。

サービス開発は難しくなく、タスクスケジューラとWebSocketサーバーはすぐにカプセル化されます。長期にわたる集中的な監視の後、タスク スケジューラの遅延は許容範囲内に収まります。これは、以前にシングルコア条件で負荷の高い環境下でテストしたときにわかりました。 CPU が完全にロードされるまで利用可能な計算能力。

間もなく、新しいサービスのデプロイメントがオンラインになり、言うまでもなく、調整データ、WebService ビジネス ロジックの調整が行われます。私が心配していた、WebService で発生する可能性のある問題はまったく発生していませんか? 特にテスト サーバーでは、単に最も安価なサーバー (使い捨て、システムがクラッシュするとすぐに、イメージから直接再インストールします) ) を 1 台のマシンで実行しても、混乱はまったくありません。 PHP+MySQL の耐久性は本当に想像を超えています。もちろん、事前にストレージ容量と計算能力を心配していたので、ビジネス ロジックの特性に基づいて多層キャッシュ ソリューションも設計しました。 Memcache を追加する必要がある場合もあります。

しかし、node.js で書かれたこれらのサービスの堅牢性と安定性は非常に低く、サービスが理由もなく停止することが多く、スケジューリングとメモリの解放が満足のいくものではありません。もちろん、Service を開発する際に意図的に最適化したわけではありません (基本的にはラフと言えます)。結局のところ、実際には検証されていないことが多く、それほど時間をかける必要はありません。そして脳。私の予算では、この部分は遅かれ早かれリファクタリングする必要があるでしょう。ロジック自体は複雑ではないので、最終的な解決策はnode.jsではない可能性があります。

初期の調査とテストに基づいて、サービスの再構築は現在、jvm と golang に焦点を当てています。 JVM は長年にわたる試行錯誤を経て、そのメモリ管理は比較的完璧になっています。そのチューニング エクスペリエンスと共有については、Google でたくさん検索でき、参考となるリファレンスがたくさんあります (Google トレンドをチェックしてください)。世界中のすべての開発言語の中で、Java ははるかに先を行っています)、私はすでにいくつかの使用可能なコードを以前に開発しました。 Golang は間違いなくキラー言語であり、この言語は JVM よりもチューニング可能な実行パフォーマンスが高いと信じています。しかし、そのポインター シンボルを見ると、変数が汚染される可能性があるという不安が残ります。