uid.me-MongoDBおよびMojoliciousに基づく個人用ページサービス

こんにちは、Habr！



新しいプロジェクトのレビュー投稿をしたいです。 このレビューは、機能と技術的な部分の両方に影響を与えます。これにより、専門の開発者とテクノロジーに遅れないようにする目的でHabrを読む人の両方がこの記事を興味深いものにできることを願っています。



プロジェクトの技術面のみに関心がある場合は、 第2部に直接アクセスすることをお勧めします。



パート1.リリカル



私たちはuid.me個人ページサービスの開発チームです。

たとえば、個人ページは次のようになります。





http://uid.me/dikaya





http://uid.me/pavel_kudinov



私たちのサービスの西側の対応に慣れていない人は認めるべきです： uid.meプロジェクトは、 about.me英語サービスのクローンローカライズとして歴史を開始します



創造の歴史



そんな感じでした。 私たちが勤務する会社のウェブサイトビルダーuCozは、8年間存在し、ウェブマスターが作成した3500万を超えるプロファイルと、ウェブマスターサイト、フォーラム、ブログが作成した多数の訪問者がデータセンターの腸内に蓄積しています。



これらのすべての人々は、グローバルなuID認証システムによって結ばれています。







今日まで、uCozに登録されたすべての人はこの種類のプロファイルを持っていました。



http://3707164671.uid.me/







about.meプロジェクトは、各uCozユーザーの個々のページの既存の最良のプロトタイプとして選ばれました。これは、21世紀初頭のWeb住民の自己表現という現代のトレンドに合っていると考えています。



about.meの場合と同様に、ユーザーに次の情報を提供します。



1.名刺への印刷に使用できるuid.me/name_nameの形式のURLは、skypeのホームページとして使用でき、メディアで言及されている場合もあります。



2.個人の写真を単一の視覚画像、高解像度の背景画像、自分に関する基本情報（伝記や関心のある領域など）に結合する機能。



3.パーソナルページにユニークな外観と全体的な視覚的一貫性をすばやくエキサイティングに与えることができるデザイナー。









4.最後に、最も興味深いのは、今日、私たちの多くがソーシャルネットワークに積極的に参加していることです。 FacebookやVkontakteのフォーマットに近い人、TwitterやInstagramのマイクロブログに限定されている人、Youtubeで自分の人気チャンネルを持っている人。



そして、ここでルールは真実です-人がより多くの社会活動を示すほど、「ソーシャルネットワークのどれを「メイン」と見なすべきか」という質問がより深刻になります。



uid.meを一種の個人的なオンライン名刺として使用することをお勧めします。 Googleのサービスを使用すると、最も一般的なソーシャルネットワークを自分のプロファイルに添付できます。新しい貴重な知り合いを作成したり、プロファイルでskypeを指定したり、フォーラムで署名したりするときに、リンクを選択する必要はありません。



投稿、ツイート、写真がプロフィールに自動的に表示され、一般的なビューが表示に使用され、「ストリーム」機能がイベントの共通フィードを作成し、発生したすべてを時系列順に結合します。







ところで、 uid.meに個人用ページを作成する場合は、ソーシャルネットワークを介した自動登録を使用することをお勧めします。 「 ログイン 」ボタンのいずれかをクリックすると、登録情報を入力せずに個人ページがすぐに作成されます！







今後の展望として、近い将来ソーシャルネットワークと緊密に統合することで、プロジェクト開発計画が大きく変わると言いたいです。



すでに開発中のuid.meプロファイルの2番目のバージョンは、ソーシャルネットワークからの情報を、カスタマイズ可能なデータプレゼンテーションを備えた単一のストリームに結合する機能に主に焦点を当てます。



さらに、友人、旅行、音楽の好み、およびシステムがプロファイルから自動的に抽出して処理できるその他の興味深い面白い事実に関する情報を表す、カラフルなグラフとチャートの形式でいくつかの興味深いインフォグラフィックウィジェットを開発する予定です。



おそらく次のようになります。









パート2.技術



uCozウィングの下で​​uid.meを開発していると、かなり珍しい状況に陥りました。一方で、プロジェクトコード全体がゼロから書かれているはずでしたが、一方でリリース日には、2000万を超えるインポートが想定されていたため、プロジェクトは自動的に重負荷になりましたボット登録や絶対に古いプロファイルが競争に合格しなかったという事実を考慮に入れたプロファイル。



それにもかかわらず、私たちはファッショナブルなテクノロジーを使用してすべてを美しく行うことを決め、最終的に多くの経験と潜在的なレベルアップを得て、戦闘で偵察を実施しました。



以下が成功のコンポーネントとして選択されました。



0. Nginx。 彼なしで。



1.すぐに使用できるデータベースは、データを複数のサーバーに分散する問題と、何らかの理由でクラスターからサーバーが物理的に失われる場合のフォールトトレランスの問題を解決します。 この能力では、アクティブなホリバーにもかかわらず、MongoDBが選択されました。



2.機能的プロトタイピングの主要なフェーズと後続のフェーズを損失なく実行できる柔軟なデータスキーム。 MongoDBは再び役に立ちましたが、ここでは便宜上リソースを支払う必要があったため、 「BSONは贅沢品ですか、それとも現代の交通手段ですか？」という質問に対する主な回答を得る必要があります。



MongoDB形式に変換すると、元のユーザープロファイルのmysqlデータベースが5倍に増加したことに注意してください。 ただし、各プロファイルにはuid.me機能に関連する印象的な量の新しいデータが追加されているため、柔軟なBSONデータスキームの大食いだけではありません。



3.正直に言うと、動的JSインターフェースの積極的な使用に向かう現在の傾向（および、マシンコードへの動的コンパイルのために既存のすべてのスクリプト言語を桁違いにバイパスするV8 Javascriptの開発中にGoogleエンジニアによって行われた技術的ブレークスルーに対する多大な敬意を考えると） node.jsを使用してJavaScriptでWeb開発の輪を閉じると同時に、いくつかの太ったパンを手に入れるというクレイジーなアイデア...



しかし、彼らは「 1つのプロジェクトが1つの新しいテクノロジーであり、これまでにMongoDBが十分にある」と判断しました（c）Alexander Solovyov。 ちなみに、 彼のレポートを見なかった人はヒットです、私たちはチーム全体をお勧めします！



その結果、サーバーテクノロジーとして企業に馴染みのあるPerlを残すことにしましたが、2番目の宇宙速度を獲得し、 fast_cgi重力場を離れ、 Mojoliciousを適用しました-Mojolicious-ルート、ヘルパー、ブリッジ、ビルトインを備えたモダンでスタンドアロンで適切な（著者を除く）Webフレームワーク現代の開発者によって設定された非同期リクエストやその他のお菓子のサポート。



4.ソーシャルネットワークとやり取りするときの完全な非同期性とデータキャッシング。



プロジェクトのプロトタイプといえば、 about.meサービスが受信したソーシャルネットワークからのデータは更新されず、サービスの接続時に1回だけ読み込まれることがわかりました。 キャッシュ更新オプションはおそらくVIPユーザーが利用できますが、 about.meからabout.meの情報を取得できませんでした。 これにより、将来同様の問題のリスクを最小限に抑えるために、サーバー間通信とキャッシュシステムを可能な限り整理することが最善であるという考えに至りました。



ほぼ普遍的に実装されたOAuth2と、さまざまなソーシャルネットワークのAPIの組織の類似性により、相互作用を正常に一般化することができました。



もちろん、プロトタイプ段階では、APIを使用したすべての作業は同期的でしたが、高負荷プロジェクトでHypnotoadワーカーがAPI要求を実装するのをブロックすることは、間違いなく贅沢で無駄です。 幸いなことに、Mojoliciousはインターフェイスと実装の両方の点で非常にまともなイベントマシン上に構築されているため、プール内の各ワーカーは1つ（たとえばmod_perlなど）だけでなく、多数の並列リクエストを処理できますもちろん、大量の非同期コードが含まれている場合。



ちなみに、 node.jsの使用に対する主な「恐ろしい」引数の1つは完全な非同期性であるため、古典的な同期パラダイムのフレームワーク内で開発を開始し、少なくとも重要なことを終えると、Mojoliciousは優れたメンタルブリッジとして機能しますハイブリッドコードの一部（同期+非同期）。 率直に言って、今私たちはnode.jsをそれほど恐れず、それを後続のプロジェクトに適用したいと思っています。



一般に、 uid.meは「自転車禁止 」の原則に基づいて作成され、化石化された自家製製品の層全体がシヴァに厳sinceに犠牲にされました。これは、2005年以来、 DBIx :: Classを使用すると、困難な時期に超越的な恐怖を回避できます。 明るいメモリ。



それでも、 uid.meを開発すると 、面白いクラフトが生まれました-これはマクロです

take { … $take->('named_callback_slot_1') ... } process { my $taken = shift; … },
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Mojoに基づいて作成：:: IOLoop->遅延 、カスケード例外処理を含む名前付きカスケード非同期API相互作用の組織に関連する操作のサイクル全体を大幅に簡素化します（興味がある場合は、個人的なものを記述して共有します）。



MongoDBに戻る



私は、NoSQLが主流ではなかった頃からNoSQLに似たものを実践したかったのです。 その時に直面しなければならなかった高負荷タスクの一部として、次の理解が徐々に現れました。



1.古典的なLAMPプロジェクトは、古典的なSQLデータベースで始まります。

2.プロジェクトがポピュラーになった場合、「highload」のステータスになります。それ以外の場合はgoto 1になります。

3.「高負荷」のステータスは、キャッシュ、シャーディング、レプリケーション、および

SQLデータベースに保存されているもののバックアップ。

4.進行中のプロジェクトのデータスキームの進化は、より多くのデータが蓄積され、より多くのデータが蓄積され、需要が多いほど、プロジェクトの人気が高まります。

5.これらすべての結果として、ORMコードは、特に残酷な状況で、mutex、memcachedのデータのシリアル化/非シリアル化、プリミティブシャーディングの機能を実行し始めます-データスキームの下位互換性を確保するためのパッチ（実際の状況でデータの大規模なエンドツーエンドの更新を常に提供できるとは限らなかったため） 。



しかし、悲しいことに、庭には厳しい2000年代がありました。



2010年の初めは、成長する高負荷プロジェクトのほとんどの問題をすぐに解消することを約束するいくつかのNoSQLソリューションの出現に触発されました。 すぐに使用できるオープンなNoSQLソリューションの登場は多くの人によって予測されていましたが、それにもかかわらず、美しい未来を実際に獲得したことは嬉しい驚きでした。



技術革新に関して、より極端な同僚と相談した後、 MongoDBを試すことにしました。



私たち自身のために新しい技術を研究して、私たちはその能力を最大限に活用し、最善を期待して（したがって、箱から出した銀の弾丸）、しかし、過度のrog慢が私たちに興味深いことに直面する場所でより古典的な技術にロールバックすることを期待して論理的であると考えました落とし穴。



機会を最大化するとは、次のことを意味します。



1. JSONデータストレージ形式により、データスキーマ内の通常の親/子/ xリンクを気にせずに、または気にせず、常識に制限されます。 その結果、メインユーザーオブジェクトのネストされた構造は太字であることがわかりましたが、便利です。 一連のフラグ、表示設定、小さなリンクリスト、および以前は一連のニアユーザーSQLテーブルの作成につながった他のすべてを大胆に配置しました。



2.汎用コードがデータモデルに追加されました。これにより、インターフェイスのプロトタイプを作成する段階で、JS機能を向上させることが非常に快適になりました。たとえば、URL / profile / saveを介して、新しいデータでユーザーオブジェクトを拡張したJSONを送信できるようになりました：

 user.save({ 'style.profile.top': '20px', 'style.caption.tags.color': 'rgba(30, 29, 38, 1)', 'info.first_name': '' });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

許可されたユーザーのアクティビティに関連するすべての操作は、500ミリ秒の潜在コレクターを備えた共通の送信機能にパッケージ化され、さまざまなアトミック編集を共通のパッケージに結合しました。



その結果、クライアント側の開発者は、新しいフィールドの使用を開始するだけで、ユーザーオブジェクトの構造を簡単に拡張できました。



もちろん、プロトタイピングフェーズの後、 / profile / saveのサーバー側には、正確さのために不明なフィールドとフィルター処理された値を遮断するコンテキストデータフィルターが装備されていました。



問題は1つだけでした。ユーザーがデータベースに保存できるのは、フィールドが表示される前にプロファイルを最後に編集してから、一部のフィールドがまったく存在しなかったためです。 理想的には、データベースから取得したオブジェクトに魔法のように表示される各フィールドのデフォルト値が必要です。



ORMレベルでは、取得されたすべてのデータの強制拡張が、存在しないすべてのフィールドのデフォルト値とともに追加されました。



円は閉じています。



データベースのエンドツーエンドの更新に頼らずにオブジェクトの構造を動的に拡張し、サーバー側だけでなくクライアント側でも透過的に動作することができましたが、新しいものを追加するプロセスは非常に快適で、プロトタイプからリリースへの移行にはちょうど2つが伴いましたアクション：



1.新しいフィールドデータのルールをextend_rulesフィルターに追加します。

2.このフィールドの予想されるデフォルト値をdefault_userに追加します。



おそらくそれだけです。 ご清聴ありがとうございました、私たちはあなたが訪れるのを待っています！



デザートのPS、ヌード愛好家：