支払いシステムの作成方法:パート1

2009年の夏、Mail.Ruは独自の開発者によって作成された新しい支払いシステムの開始を発表しました(これに先立ち、MoneyMoney支払いシステムがMoney.Ruプロジェクトに技術的およびサービスサポートを提供したことを思い出してください)。 この新しいプロジェクトは、とりわけ、エンターテインメントプロジェクト(ゲーム、マイワールドのアプリケーション)から電子商取引プロジェクト(グッズ、不動産、ニュースレター)まで、企業のさまざまなサービスのための統合された便利で安全な支払いメカニズムをポータルユーザーに提供することでした。



1年が経過しました。 Money Mail.Ruは成長を続け、ユーザーと店舗の両方の金融商品の数を増やしています。 ユーザーにとっては、これはシステム内での転送、さまざまなサービスや商品の支払い(多数のゲーム、モバイル通信、インターネット、公共料金の支払いから衣服やチケットの購入まで)、銀行カードから入力してVisa仮想カードに出力する可能性です。 支払いの受け入れまたはユーザーアカウントの補充を自動化するために、店舗用のツールが積極的に開発されています-支払いシステムの多くの機能はAPIを介して利用できます。



前述の明示的な機能に加えて、技術的な機能もありますが、これについてはあまり語られていませんが、会社全体にとって重要なことです。 たとえば、Dengami @ mail.ruに接続されているポータルサービスとストアには、他の支払いシステム(WebMoney、Yandex.Moneyなど)で電子資金を保有しているユーザーからの支払いを受け付ける機能があります。 システムの等しく重要な部分はSMS処理であり、これにより、多くの国からの訪問者が、決済システムで口座を開設することなく、さまざまなポータルサービスのサービスに対して支払うことができます。



この記事では、支払いシステムが内部からどのように配置されているか、信頼できる操作を確保するために使用するツール、多数の外部システムと連携する方法、遭遇した問題、解決方法、および結論について一連のストーリーを開きます。 。 技術記事に加えて、支払いシステムを使用して、ソーシャルストアのオンラインストアやアプリケーションの経済的に活発なオーディエンスを拡大する方法についてお話します。 Money.Mail.Ruに関する他のトピックに興味がある場合は、お問い合わせください。



鋼の焼き戻し方法



新しいプロジェクトの作業を開始するタスクは、2008年の終わりに部門の前に設定されました。 当時、支払いシステムは、Mail.Ruを使用して開発、起動、および正常に動作するプロジェクトの種類に属していませんでした。 ただし、すでにタスクを設定する段階で、開発プロセスでを考慮して実装する必要があるのが理解されていました。



これらの要件を最初の文字で「MMM」と呼びました(これはもちろん冗談です )。 ここにあります:

それらのそれぞれについてもう少し。



拡張性



プロジェクトを作成した人々がプロジェクトを予期せず「撮影」し、多数のユーザーを受け入れ、開発者が急激に増加するワークロードに迅速に対処する方法の問題に直面することは秘密ではありません。 memcachesを使用してプロジェクトを埋め込み、マスタースレーブレプリケーションを上げる-これらの概念は、プロジェクトが遅くならないように何かをしようとした多くの人々によく知られています。 残念ながら、これらの簡単な方法を使用しても、通常はすぐに解決できません。システムコンポーネントを学習してキャッシュに移動したり、1つのデータベースサーバーを書き込みに使用したり、多くを読み取りに使用したりする必要があります。 すぐに適切な水平スケールアウトを提供することは、簡単な作業ではありません 。 そして、この問題を解決するために、これまでは主なタスクである電子決済に対処できないプロジェクトを書き直さなければならないという事実で、発売後1週間から1年後には遭遇したくありませんでした。 したがって、すでにシステム設計の段階で、Money.ru.Ruを簡単にスケーリングするための基盤を築く必要がありました。



多通貨



繰り返しますが、りんごでうまく機能するコードが、それが提供する倉庫にバナナが現れたときに機能しないこともあります。 さて、異なるエンティティでの作業はコードでは提供されていません! 私が見た多くの場合、「apple」テーブルに似たオレンジの新しいテーブルセットをセットアップし、 $ iApples$ iBananasに置き換えて以前に記述したコードをコピーすることで、タスクを解決することがよくありました 。 その他の場合、問題の解決策はより適切でした-データベースに追加フィールドが表示され、クラスはいくつかの新しいメソッドとプロパティを追加して既製のものから継承されました(たとえば、リンゴの「皮」属性はバナナとはまったく異なる方法で処理されます) しかし、この解決策でさえ、コードの大幅な変更が必要になる場合がありました。 したがって、すぐにシステムにマルチ通貨を配置する必要がありました。



マルチバイタリティ



一見すると最も神秘的なプロパティですが、説明は非常に単純です。 ショーケースは、メインエントリポイントとは独立した設定で動作できるシステムエントリポイントと呼ばれます。これは、異なるドメインアドレスと独自の通貨から、そのユーザー認証方法とそのインターフェイスまでです。 このような新しいストアフロントの起動も非常に簡単である必要があります。システムの構成ファイルに数行を追加し、必要に応じて新しいユーザーインターフェイステンプレートを追加することはもう難しくありません。



もちろん、これらはすべて決済システムの要件ではありませんが、システムアーキテクチャに最も影響を与えたのはそれらです。 新しいプロジェクトは、非常に柔軟でフォールトトレラントであると想定されていました。



これをなんとかできましたか? はい、それは完全に可能でした。



現在、推定によると、新しいハードウェアの文字通り簡単なインストールと構成、およびプロジェクト構成でのノードに関する情報の入力により、システムを数百のノードに簡単に拡張できます。



システムがどのように動作するかを考えることなく、世界で利用可能なすべての通貨(国営銀行など)を処理できます。 根拠がないように-現在、システムはすでにいくつかの通貨を使用しています(ああ、これらの法的問題!)。



ショップウィンドウの例として、テスト通貨を使用するストアのデバッグ用のサイトのバージョンを引用できます。 独自の利用可能なアクションのセットと独自のテンプレートを持つサイトのモバイルバージョン 。 別の例は、APIストアを操作するためのストアフロントです。これは、Dengachi Mail.Ruでポータルユーザーを識別するために使用されるものとは異なる認証方法を使用します。 システム用のこれらのストアフロントの起動は、実際には、ストアフロントの説明とテンプレートのあるいくつかのフォルダーを持つブロックの構成ファイルの外観のように見えました。 まったく同じ方法で、たとえば、支払いシステムMoney@VKontakte.ruまたはそのような要望を表現する他のエンジンの作業を提供できます。



多くの人が、技術的な観点から、このすべてを実現する方法に興味を持っていると思います。 したがって、次の記事では、支払いシステムを現状のままにすることができ、プロジェクトの一般的なアーキテクチャについても説明できるツールとテクノロジーについて説明します。 私たちと一緒にいてください!



Money Mail.Ruのチーム



All Articles